From bdrs@compuserve.com Thu Mar 6 10:29:13 2003 From: bdrs@compuserve.com (Bas Driessen) Date: Thu, 6 Mar 2003 20:29:13 +1000 Subject: [Glade-devel] gtk_dialog_run. Message-ID: <000301c2e3cb$3d0f8a10$9701a8c0@REDBACK> This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C2E41F.0EBB9A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit G'day, Question regarding gtk_dialog_run. I understand from the doco that it is a very bad idea to use a gtk_widget_destroy when in this "dialog_run" block. You should first emit a response signal and then destroy. This all works ok. However, I have a setup, where I need to destroy a dialog in this "dialog_run" mode. If I emit a signal then code will be excuted which should not. If I destroy the dialog, I get the following output: (Main:8227): GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no handler with id `449' (Main:8227): GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no handler with id `450' (Main:8227): GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no handler with id `451' (Main:8227): GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no handler with id `452' The program works fine after this. My question is, if these warnings can "hurt". Is it just these output messages, or will it leave some traces in memory? Thanks, Bas. ------=_NextPart_000_0004_01C2E41F.0EBB9A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
G'day,
 
Question regarding=20 gtk_dialog_run. I understand from the doco that it is a very bad idea to = use a=20 gtk_widget_destroy when in this "dialog_run" block. You should first = emit a=20 response signal and then destroy. This all works ok. However,  I = have a=20 setup, where I need to destroy a dialog in this "dialog_run" mode. If I = emit a=20 signal then code will be excuted which should not.  If I = destroy the=20 dialog, I get the following output:
 
(Main:8227):=20 GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no = handler=20 with id `449'
 
(Main:8227):=20 GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no = handler=20 with id `450'
 
(Main:8227):=20 GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no = handler=20 with id `451'
 
(Main:8227):=20 GLib-GObject-WARNING **: gsignal.c:1705: instance `0x8288318' has no = handler=20 with id `452'
 
The = program works=20 fine after this. My question is, if these warnings can "hurt". Is it = just these=20 output messages, or will it leave some traces in memory? =
 
Thanks,
 
Bas.

 ------=_NextPart_000_0004_01C2E41F.0EBB9A10-- From e98cuenc@free.fr Thu Mar 6 23:34:30 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 07 Mar 2003 00:34:30 +0100 Subject: [Glade-devel] Re: [LONG] Glade and Anjuta Message-ID: <1046993670.4241.49.camel@localhost.localdomain> Hi! Please sorry the long time to reply. Comments follow Biswapesh wrote: > Hi all > > First, let me apologize for the long mail. > [snip] > some ideas. Maybe at least some of the things I want to do are done > already; in that case I'd like to know how to use those features. Ok, so first, let's do a quick presentation of glade. Damon Chaplin did glade (let's call it glade-1), and has maintained it with much energy over the years. Chema Celorio was given the task to implement undo/redo on glade-1, but he decided to rewrite it instead to make easier the task. Let's call this rewrite glade-3. glade-3 was using gtk+-2, but it was taking too much time to complete, and Damon then ported glade-1 to gtk+-2 (let's call it glade-2). Damon make it a11y savy and finished the port. Chema stopped working on glade-3 (when you see his list of projects, you can do nothing but understand... :) Carlos then took the torch on glade-3. The latests patches to glade-3 were from Archit Baweja (to implement cut & paste) and from myself (to implement undo/redo and fix several segfaults). That was almost 1 year ago. Nothing has changed since then. If you know of a Damon clon or something... :) Easy, eh? ;) > What I'd like to do is: > > 1) GUI Integration: I'd like to have the three main windows of Glade > (Palette, Properties, Widget Tree) to be dockable windows, either as > Bonobo components (preferably as shared lib - out-of-proc is a pain), > or as ScrolledWindow-derived widgets, which we can put in our left > /bottom panes. Ok, I've changed palette and properties to stand-alone widgets. Widget Tree will follow soon. For know, I will prefer to remain out of bonobo. Let's take the time to learn what do we need, and once we have everything working as simple widgets we can put it in a bonobo component. However, I don't understand why do you need ScrolledWindow-derived widgets. It seems more logical to me to just make these normal widgets and let the code that creates it to put it wherever he wants (a GtkViewport in your case, a GtkWindow in the standalone glade application). Am I missing something? > 2) Glade Signals: We already have a decent symbol manager which keeps > track of all code components (structs/functions/prototypes, etc.) and > their locations (file name, start/end line/pos, etc.). We need to > integrate the editor, the symbol manager and the widget > tree/properties window. There are two ways of doing it: > a) If the properties window is a docked widget, it can emit the > "signal_added" signal. The signal handler should be passed the widget > and signal details. We need the node and the node of > the glade file. We can then check in the symbol database if the > function exists (creating it if necessary my popping up a dialog and > taking the extra paramaters from the user). Once done, we can jump to > that function to allow the user to add/edit code. Ok, no problem. I'll add that to the TODO list and code it asap. I will read your second way later, as it's too late now :-) > (i). We need a database which tells us the parameters (along with > their types) and the return values of each type of function. I'm > guessing you guys already have such a database (since you generate the > C code), but nope, we don't generate anymore C code. > (i) We'd like to be able to call a Glade function with the widget and > signal name and get the function name, parameters types and return value > (a simple string containing the prototype will do). I don't think it belongs to glade to do that. We're a "build a GUI" tool, not a gtk+ instrospector. What's the problem implementing that on anjuta itself? > (ii) We'd like to be able to pass a widget ID and get (as a > string) the code to build the GUI in the passed language of choice That would only be useful if the user is not going to use libglade, and if we give this possibility, then we'll run in troubles. Thank you for your comments. Cheers, From biswapesh_chatterjee@tcscal.co.in Fri Mar 7 04:57:00 2003 From: biswapesh_chatterjee@tcscal.co.in (Biswapesh Chattopadhyay) Date: 07 Mar 2003 10:27:00 +0530 Subject: [Glade-devel] Re: [LONG] Glade and Anjuta In-Reply-To: <1046993670.4241.49.camel@localhost.localdomain> References: <1046993670.4241.49.camel@localhost.localdomain> Message-ID: <1047013020.1093.12.camel@A5-1877> [snip] > Ok, so first, let's do a quick presentation of glade. Damon Chaplin did [snip] So, glade-3 si not likely to be complte anytime soon - is that it ? Looks like the anjuta1/anjuta2 situation all over again. Boy I hate code rewrites ! :-( > [snip] > Ok, I've changed palette and properties to stand-alone widgets. Widget > Tree will follow soon. For know, I will prefer to remain out of > bonobo. Let's take the time to learn what do we need, and once we have > everything working as simple widgets we can put it in a bonobo > component. I'm not too keen on Bonobo myself and anyway, anjuta does not have the capability (currently) to act as a bonobo container. Widget is fine. I'll have a look at the code and let the list know how it progresses. > > However, I don't understand why do you need ScrolledWindow-derived > widgets. It seems more logical to me to just make these normal widgets > and let the code that creates it to put it wherever he wants (a > GtkViewport in your case, a GtkWindow in the standalone glade > application). Ignore this - a simple widget is O.K - we'll put it in a scrollable container - in fact, that's actually a better solution. BTW, I hope your widgets emit the necessary signals. > > Am I missing something? > > > 2) Glade Signals: We already have a decent symbol manager which keeps > > track of all code components (structs/functions/prototypes, etc.) and > > their locations (file name, start/end line/pos, etc.). We need to > > integrate the editor, the symbol manager and the widget > > tree/properties window. There are two ways of doing it: > > a) If the properties window is a docked widget, it can emit the > > "signal_added" signal. The signal handler should be passed the widget > > and signal details. We need the node and the node of > > the glade file. We can then check in the symbol database if the > > function exists (creating it if necessary my popping up a dialog and > > taking the extra paramaters from the user). Once done, we can jump to > > that function to allow the user to add/edit code. > > Ok, no problem. I'll add that to the TODO list and code it asap. > Great ! Since you've already 'widget'-ified the windows, this should be too much of a deal I guess. > I will read your second way later, as it's too late now :-) If you implement this, I guess there's no need for the 2nd method. > > > (i). We need a database which tells us the parameters (along with > > their types) and the return values of each type of function. I'm > > guessing you guys already have such a database (since you generate the > > C code), but > > nope, we don't generate anymore C code. > > (i) We'd like to be able to call a Glade function with the widget and > > signal name and get the function name, parameters types and return > value > > (a simple string containing the prototype will do). > > I don't think it belongs to glade to do that. We're a "build a GUI" > tool, not a gtk+ instrospector. What's the problem implementing that on > anjuta itself? Can you tell me how then to get the prototype for the function ? How did glade-1 do it ? Was it all hardcoded ? I want the ability to define custom widgets. Is there any way to introspect in GTK (maybe some marshaller call ?) > > > > (ii) We'd like to be able to pass a widget ID and get (as a > > string) the code to build the GUI in the passed language of choice > > That would only be useful if the user is not going to use libglade, and > if we give this possibility, then we'll run in troubles. No, even if the user uses libglade, he/shell would still have to write the callbacks, and I'd like to make that task easier. The idea is that when the user adds a signal, the prototype gets generated (if it does not exist) and the editor window jumps there. > > Thank you for your comments. Thanks for getting back. You can join us at #anjuta (irc.gimp.org) occassionally for discussions ? I'll keep the list posted on progress. It would be nice to have the widgetified widget tree though, with added nodes for signals at widget level, so that when the user browses the widget tree and clicks on the signal, we can take him to the code. Rgds, Biswa. > > Cheers, > > > _______________________________________________ > Glade-devel maillist - Glade-devel@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/glade-devel -- Biswapesh Chattopadhyay TCS From e98cuenc@free.fr Fri Mar 7 06:28:39 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: Fri, 7 Mar 2003 07:28:39 +0100 Subject: [Glade-devel] Re: [LONG] Glade and Anjuta In-Reply-To: Message-ID: <000e01c2e472$cdf0f300$7fe03851@lou> Shane wrote: > > What happened to the glade-3 menu editor with in place menu > item editing... was it finished & committed? Nope. After two weeks of much hair lose, I lose faith :-) In fact, I still think that it's doable, but was too much of a pain in the neck. Right now, I'm highly tempted to just copy the code of the glade-2 one. Cheers, From christof@petig-baender.de Thu Mar 6 22:02:14 2003 From: christof@petig-baender.de (Christof Petig) Date: Thu, 06 Mar 2003 23:02:14 +0100 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <1046306197.1655.40.camel@localhost.localdomain> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> Message-ID: <3E67C566.1000107@petig-baender.de> Hi, (Sorry, if this looks like crossposting, but all CCs look sensible) I'm speaking up on behalf of glademm, the (separate) C++ code/project generator for glade. And I like the _choice_ to use generated code. Owen Taylor wrote: > If you generate C code with glade: > > - You get C code which isn't related to how you write code by > hand. But if you don't know better, you'll copy anyways. > (Why is this code calling gtk_widget_set_name() and ref'ing > every widget?) > > - You get the typical code generation problem that once you > edit it, you risk problems if you generate code again. > > - You get something you can't check into source control reliably. > > - You go to experienced GTK+ programmers for help, and they > look at you blankly. I can't speak in favor of the generated C code (I always found the above problems very valid), but for C++ and glademm I found these problems solved. (Except for the fourth point, you need some glademm knowledge to solve glademm problems/bugs, gtkmm only knowledge might help you but is not always sufficient). The only reason I was ever tempted to use libglade _internally_ as an optional drop in replacement (_transparently_ to any program code!) was it's good gnome widget support. With C++ it should not make any difference to your program code whether the actual widgets are created by libglade(mm) or by gtkmm (generated code). To support these claims I promise to finish the libglade option in glademm this week: generate your program's skeleton by glademm and use libglade or generated code by choice. > Libglade is a development methology we can support, because it > gets used extensively for real apps. There may be full scale > apps using generated glade code, but certainly not many of them. I can name a lot of apps using glademm generated code. There _are_ reasons for generated code: - a single binary is enough, no need to ship .glade and image files seperately, install them to a known location and find them at runtime. - no user can mess up your program's user interface by editing/deleting the .glade/image files (this is clearly a pro and a con!) >>>Makes sense to me; we had >> >>> Don't use glade to generate code, use libglade! for C I can't disagree, but I would love to have the option to switch between libglade and generated code (statically linked in widgets) without having to change a single line of the program. Since this is feasible with C++, it should be possible for C, too. Perhaps a nice project for a volunteer? (I don't care about C code) A separation of GUI designer and code generator would benefit glade-[123] IMHO. (IIRC glade-3 does take this road) > The comment about IDE integration is basically that if the source > code editing is integrated with the widget editing, then things > can work better: > > - You can click on a widget, and edit its callbacks > - Source code editing is relatively constrained, because the > tool you are using to do it knows about the GUI. I'm all in favor of IDE integration, but personally I don't need it at all. GUI and program code (callbacks) are well separated by glademm (IMHO of course). Christof (glademm maintainer) From e98cuenc@free.fr Fri Mar 7 22:28:14 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 07 Mar 2003 23:28:14 +0100 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <3E67C566.1000107@petig-baender.de> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> <3E67C566.1000107@petig-baender.de> Message-ID: <1047076096.1225.36.camel@localhost.localdomain> Hi, On Thu, 2003-03-06 at 23:02, Christof Petig wrote: > Hi, > > (Sorry, if this looks like crossposting, but all CCs look sensible) > > I'm speaking up on behalf of glademm, the (separate) C++ code/project > generator for glade. And I like the _choice_ to use generated code. > > Owen Taylor wrote: > > If you generate C code with glade: > > > > - You get C code which isn't related to how you write code by > > hand. But if you don't know better, you'll copy anyways. > > (Why is this code calling gtk_widget_set_name() and ref'ing > > every widget?) > > > > - You get the typical code generation problem that once you > > edit it, you risk problems if you generate code again. > > > > - You get something you can't check into source control reliably. > > > > - You go to experienced GTK+ programmers for help, and they > > look at you blankly. > > I can't speak in favor of the generated C code (I always found the above > problems very valid), but for C++ and glademm I found these problems solved. How do you solve the second problem with glademm? You generate a file, say foo.cpp, with glademm. I edit it, change the glade file, and regenerate the file. Do you conserve the changes done to foo.cpp by hand? Honestly, I don't think that the exact language in which the code is generated has any impact. > (Except for the fourth point, you need some glademm knowledge to solve > glademm problems/bugs, gtkmm only knowledge might help you but is not > always sufficient). > > The only reason I was ever tempted to use libglade _internally_ as an > optional drop in replacement (_transparently_ to any program code!) was > it's good gnome widget support. With C++ it should not make any > difference to your program code whether the actual widgets are created > by libglade(mm) or by gtkmm (generated code). exactly like with C. Please understand that I'm not bashing C++ (as it's also usually my language of choice), but I don't see any substantial difference, here. > > Libglade is a development methology we can support, because it > > gets used extensively for real apps. There may be full scale > > apps using generated glade code, but certainly not many of them. > > I can name a lot of apps using glademm generated code. There _are_ > reasons for generated code: > > - a single binary is enough, no need to ship .glade and image files > seperately, install them to a known location and find them at runtime. > - no user can mess up your program's user interface by editing/deleting > the .glade/image files (this is clearly a pro and a con!) I agree that there may be reasons to use generated code (mostly of the kind of "we don't want a dependency on libxml-2"), but I don't agree with your reasons. It's quite rare to find a program that can be installed with just an executable. In fact except for trivial programs (and mono executables when you put everything in the same .exe), you always have a lot of things to install. Some .glade files don't make really a difference. > >>>Makes sense to me; we had > >> > >>> Don't use glade to generate code, use libglade! > > for C I can't disagree, but I would love to have the option to switch > between libglade and generated code (statically linked in widgets) > without having to change a single line of the program. Since this is > feasible with C++, it should be possible for C, too. Perhaps a nice > project for a volunteer? (I don't care about C code) That feasible in any language. But that's not the problem. The problem is: How do you deal with changes done by hand in the generated code? MS deals with this problem adding "please, don't change this code" comments (and of course, hell opens when you don't follow the advice). I guess that I don't have to discuss the problems of that approach... but in fact, you can't do much better if you generate code. > A separation of GUI designer and code generator would benefit > glade-[123] IMHO. (IIRC glade-3 does take this road) glade-3 ignores completely the code generator stage. Cheers, From e98cuenc@free.fr Sat Mar 8 09:46:21 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: Sat, 8 Mar 2003 10:46:21 +0100 Subject: TR : [Glade-devel] Re: [LONG] Glade and Anjuta Message-ID: <000d01c2e557$9635f830$7fe03851@lou> I forgot to CC the list: -----Message d'origine----- De : Joaquin Cuenca Abela [mailto:e98cuenc@free.fr]=20 Envoy=E9 : vendredi 7 mars 2003 08:05 =C0 : 'Biswapesh Chattopadhyay' Objet : RE : [Glade-devel] Re: [LONG] Glade and Anjuta Biswapesh wrote: >=20 > [snip] > > Ok, so first, let's do a quick presentation of glade. > Damon Chaplin > > did > [snip] >=20 > So, glade-3 si not likely to be complte anytime soon - is The things lacking in glade-3 when compared with glade-2 are: 1) Stability 2) Menu Editor 3) Being able to add new catalogs Point 1 is not really *sooo* bad. Point 2 is the most important IMHO. > that it ? Looks like the anjuta1/anjuta2 situation all over again. Boy > I hate code rewrites ! :-( Hey, it's not my fault ;-) > Ignore this - a simple widget is O.K - we'll put it in a scrollable=20 > container - in fact, that's actually a better solution. BTW, I hope=20 > your widgets emit the necessary signals. Bad news. I've just changed them from a window widget to a non window one. All the communication between widgets is not yet done with signals, but I will start adding them asap. > > I don't think it belongs to glade to do that. We're a > "build a GUI" > > tool, not a gtk+ instrospector. What's the problem > implementing that > > on anjuta itself? >=20 > Can you tell me how then to get the prototype for the function ? How=20 > did glade-1 do it ? Was it all hardcoded ? I want the ability to=20 > define custom widgets. Is there any way to introspect in GTK (maybe=20 > some marshaller call ?) You should have the Gtype of the widget. Then you call g_signal_list_ids & g_signal_query. That should give you everything you need to build the prototype of the callback. Cheers, From e98cuenc@free.fr Sat Mar 8 14:26:50 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: Sat, 8 Mar 2003 15:26:50 +0100 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <1047123218.1270.10.camel@localhost.localdomain> Message-ID: <000001c2e57e$c64277c0$7fe03851@lou> Murray wrote: > > > but in fact, you can't do much better if you generate code. > > C++ has the concept of inheritance. glademm generates only > base classes. > User-written code is in user-written derived classes. That's irrelevant. The question is: what happens when the user edits code that he shouldn't edit and later it regenerates this code? Two different places to put the same info is one too much, and as the task of extract the information from a .glade file is several orders of magnitude easier than extracting it from the code, .glade files should be used. I still see useful (for those who don't like an extra dependency) a utility that converts a .glade file to [pick you language] code, hopefully one that, with enough makefile's magic can do the conversion automatically at compilation time (kind of like the RC compiler on windows). But that's out of glade's scope. Cheers, From johnp@martianrock.com Sat Mar 8 15:55:19 2003 From: johnp@martianrock.com (John Palmieri) Date: 08 Mar 2003 10:55:19 -0500 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <000001c2e57e$c64277c0$7fe03851@lou> References: <000001c2e57e$c64277c0$7fe03851@lou> Message-ID: <1047138950.27949.99.camel@jade> Hello all, I am the author of gobject-factory a gobject code generator. It has been mentioned to me by Biswapesh of Anjuta fame that a new project I am going to embark on has the potential to help out in the code generation glade area. Basicly gobject-factory has become useless to me for the same reasons that code generation in Glade is bad. Basicly I have to think of everything I want up front or trash my hand written code later because I needed to generate the code again. Basicly I am going to integrate what I learned from gobject-factory into an Anjuta 2 plugin that allows a person to add and remove methods, properties, and signals on the fly instead of all at once. Since GObjects have the same patterns as GtkObjects, using it to keep track of callbacks and essentialy glue Glade and Anjuta would be trivial. I am not starting the project right away since gobject-factory is a utility to help with another project that I want to get a little further in before I start and I am also waiting for SourceBase (source code tagging) to get into Anjuta. It is something to look out for as a potential way to solve the code generation problems. Some comments on the issues inline bellow. On Sat, 2003-03-08 at 09:26, Joaquin Cuenca Abela wrote: > Murray wrote: > > > > > but in fact, you can't do much better if you generate code. > > > > C++ has the concept of inheritance. glademm generates only > > base classes. > > User-written code is in user-written derived classes. > > That's irrelevant. The question is: what happens when the user edits > code that he shouldn't edit and later it regenerates this code? An incremental code generator would only generate new code as needed. When a user edits code the generator will learn the changes. The generator will only edit existing code if the user then goes and asks for the generator to edit it. For instance my gobject generator will be generating signals which need to be entered in three places in the code - the Gobject's class structure, the signals enumeration and registered somewhere in the implementation file, usualy in the init method. When a user generates a signal code is placed in these three locations and the generator has some way of displaying that the signal exists and can be edited by the generator. Say the user goes and edits the signal all that is realy significant to the generator is the signals name so the edited code will not affect the generator unless the name is changed. Say the name is changed in one place, the generator will display that the signal is now broken because some of the elements that make up the signal pattern are missing (which would be an error in the code anyway). When the user goes and changes the name in all three locations the pattern is again complete and the code generator registers the new signal name. The same would happen if the user created a whole new signal by hand. The user would only be allowed to use the code generator on signals whoes patterns are not broken. Now what happens if the user slightly edits the signals registration code and then uses the generator to edit the signal? Two things could happen, the generator could be dumb and just warn the user that the code seems to have been edited by hand and if they continue it might clobber their changes. Or the generator could be smart enough to understand what changes effect what and only do changes if they will not effect the code (such as changing the name of the signal which can be done safely even if the user has changed some of the parameters when regestering the signal with the GObject). Of corse at some point a programmer has to resposible for their own code. > Two different places to put the same info is one too much, and as the > task of extract the information from a .glade file is several orders of > magnitude easier than extracting it from the code, .glade files should > be used. Nothing extranious should go in .glade files. They should be lean and mean. > I still see useful (for those who don't like an extra dependency) a > utility that converts a .glade file to [pick you language] code, > hopefully one that, with enough makefile's magic can do the conversion > automatically at compilation time (kind of like the RC compiler on > windows). Code generators dumping out code at compile time is bad. A user should be able to inspect the code and make changes by hand. At that point you have to ask yourself why not use libglade. > But that's out of glade's scope. But not out of Anjuta's as was pointed out to me. As I devlop my project I will keep in mind these other concerns and try to program around a more flexable design. -- J5 From e98cuenc@free.fr Sat Mar 8 16:24:16 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 08 Mar 2003 17:24:16 +0100 Subject: [Glade-devel] commit -- add_signal signal Message-ID: <1047140657.1114.33.camel@localhost.localdomain> I've added a "add_signal" to the GladeEditor widget (the properties window). To generate a prototype of the signal, you can do: static void glade_editor_add_signal_cb (GladeEditor *editor, const char *widget_id, GType widget_type, guint signal_id, const char *callback_name) { GSignalQuery query; unsigned int i; g_signal_query (signal_id, &query); printf ("%s %s(%s widget, ", g_type_name (query.return_type), callback_name, g_type_name (query.itype)); for (i = 0; i < query.n_params; i++) printf ("%s arg%d, ", g_type_name (query.param_types[i]), i); printf ("gpointer data);\n"); } and hook the glade_editor_add_signal_cb to the "add_signal" of the GladeEditor widget. Biswapesh, please take a look at the arguments, and say me if you need anything else. Cheers, From e98cuenc@free.fr Sat Mar 8 16:28:11 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 08 Mar 2003 17:28:11 +0100 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <1047132068.1272.28.camel@localhost.localdomain> References: <000001c2e57e$c64277c0$7fe03851@lou> <1047132068.1272.28.camel@localhost.localdomain> Message-ID: <1047140892.1114.39.camel@localhost.localdomain> On Sat, 2003-03-08 at 15:01, Murray Cumming wrote: > On Sat, 2003-03-08 at 15:26, Joaquin Cuenca Abela wrote: > > Murray wrote: > > > > > > > but in fact, you can't do much better if you generate code. > > > > > > C++ has the concept of inheritance. glademm generates only > > > base classes. > > > User-written code is in user-written derived classes. > > > > That's irrelevant. The question is: what happens when the user edits > > code that he shouldn't edit and later it regenerates this code? > > He shouldn't. He doesn't have any need to. In the same sense that when you do a singleton the user should use a ::getInstance method, but you still make the constructors private. Just to be sure. There is an important difference between "he shouldn't" and "he can't". Cheers, From jcast@ou.edu Sun Mar 9 02:44:45 2003 From: jcast@ou.edu (Jon Cast) Date: Sat, 08 Mar 2003 20:44:45 -0600 Subject: [Glade-devel] Re: glade code generation In-Reply-To: Message from Bill Haneman of "Sat, 08 Mar 2003 15:50:16 GMT." <1047138616.4616.2.camel@taistealai.ireland.sun.com> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> <3E67C566.1000107@petig-baender.de> <1047076096.1225.36.camel@localhost.localdomain> <1047123218.1270.10.camel@localhost.localdomain> <1047138616.4616.2.camel@taistealai.ireland.sun.com> Message-ID: <20030309024446.3C3F04A5ED@jcomain> Bill Haneman wrote: > The only glade-generated code that an end-user should/would want to > modify IFAICS are the stubs (end-users might want to insert > implementations there). But the generation of callback stub code is a > convenience feature. Right. In fact, there's no reason I can see to even generate them; the only code I'd want to keep is code I can copy from the header file anyway, and I don't think there's any reason to modify that. So the argument is against auto-generating the handler stubs, not against auto-generating the UI creation code. Jon Cast From jcast@ou.edu Sun Mar 9 02:59:39 2003 From: jcast@ou.edu (Jon Cast) Date: Sat, 08 Mar 2003 20:59:39 -0600 Subject: [Glade-devel] Re: glade code generation In-Reply-To: Message from Joaquin Cuenca Abela of "Sat, 08 Mar 2003 17:28:11 +0100." <1047140892.1114.39.camel@localhost.localdomain> References: <000001c2e57e$c64277c0$7fe03851@lou> <1047132068.1272.28.camel@localhost.localdomain> <1047140892.1114.39.camel@localhost.localdomain> Message-ID: <20030309025939.860EE4A5ED@jcomain> Joaquin Cuenca Abela wrote: > In the same sense that when you do a singleton the user should use a > ::getInstance method, but you still make the constructors private. > Just to be sure. I'm not sure what you mean. `::getInstance'' does the same job as a constructor, no? In any case, this is a UI change. Obviously, we don't want to have a button that says ``click here to load the user-generated code into $EDITOR''. But, modifying the generated code is physically possible, just like it's physically possible to write a bit of assembler to call the (private) constructor. > There is an important difference between "he shouldn't" and "he > can't". Right. Which is why ``he can't'' has been banished from the Un*x vocabulary. I don't see the reason for your urge to destroy features to enforce any notion of right & wrong, though. > Cheers, Jon Cast From christof@petig-baender.de Sun Mar 9 00:46:48 2003 From: christof@petig-baender.de (Christof Petig) Date: Sun, 09 Mar 2003 01:46:48 +0100 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <1047076096.1225.36.camel@localhost.localdomain> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> <3E67C566.1000107@petig-baender.de> <1047076096.1225.36.camel@localhost.localdomain> Message-ID: <3E6A8EF8.9090300@petig-baender.de> [cc list trimmed somewhat, will remove gnome-hackers at next reply] Joaquin Cuenca Abela wrote: > How do you solve the second problem with glademm? [second problem is: avoid user overwriting generated code, avoid to overwrite user written code] there are two separate classes, and four (or six) files for each widget tree (toplevel window): - foo_glade.hh: UI class declaration, never edit, overwritten [contains the declaration of user visible widget pointers and the pure virtual callbacks]. Informative to look into when you write the actual program. - foo_glade.cc: UI class methods, never edit, overwritten [construction and customization of the widgets, callback connection] Usually nobody ever looks into this file (unless out of curiosity). - foo.hh: User class, derived from UI class, needs to override every connected signal handler to be instantiable, glademm outputs a first empty skeleton but never touches this file again (it emits a foo.hh_new which you can copy new callback declarations from). If there are no callbacks, this class can be empty (or even missing) - foo.cc: normally contains the flesh (definition) of the callbacks, the c(onstruct)tor and the d(estruc)tor. Of course the physical location (which file the definitions are in) is not relevant, arrange them according to your taste. My ctors usually fill the window with content (from a database) and (typically) take a number of parameters to control their behaviour. > You generate a file, say foo.cpp, with glademm. I edit it, change the > glade file, and regenerate the file. Do you conserve the changes done > to foo.cpp by hand? see above. The code is well separated. > Honestly, I don't think that the exact language in which the code is > generated has any impact. It does not have to have impact. But since C++ programs tend to organize differently (class inheritance) from C (collection of functions) the generated code looks totally different for glade and glademm. >>The only reason I was ever tempted to use libglade _internally_ as an >>optional drop in replacement (_transparently_ to any program code!) was >>it's good gnome widget support. With C++ it should not make any >>difference to your program code whether the actual widgets are created >>by libglade(mm) or by gtkmm (generated code). > > > exactly like with C. Please understand that I'm not bashing C++ (as > it's also usually my language of choice), but I don't see any > substantial difference, here. Due to my effort yesterday, glademm now offers the option (pupal state) to use generated code and libglade as a drop in replacement (no code change). I don't know of any effort to make glade generated code and libglade API compatible, but it would benefit. [Stop, I'd enjoy such a project. I'm not saying C++ is better, I'm saying: I did it for C++, who want's to do it for C?] > I agree that there may be reasons to use generated code (mostly of the > kind of "we don't want a dependency on libxml-2"), but I don't agree > with your reasons. > > It's quite rare to find a program that can be installed with just an > executable. In fact except for trivial programs (and mono executables > when you put everything in the same .exe), you always have a lot of > things to install. Some .glade files don't make really a difference. Agreed. But there are such programs (single binaries), it gets more likely if you depend on external things (like a database infrastructure, available binaries etc.). Personally I dislike to depend on external files (and how to find them at run time) unless necessary (you know: make sure to install them to a _proper_ place, binary will not work until support files are installed to target location, yuck). A binary is easy to copy around once it's self containing. [I have no problem to depend on shared libraries!] > That feasible in any language. But that's not the problem. The problem > is: How do you deal with changes done by hand in the generated code? > > MS deals with this problem adding "please, don't change this code" > comments (and of course, hell opens when you don't follow the advice). > I guess that I don't have to discuss the problems of that approach... > but in fact, you can't do much better if you generate code. Well, I don't open the gates of hell - glademm simply overwrites the changes in the "changes will be lost" marked files. Usually nobody needs to change them (glademm bugs put aside). Yours Christof PS: Am I correct to assume you are involved with glade-3? From jcast@ou.edu Sun Mar 9 17:21:29 2003 From: jcast@ou.edu (Jon Cast) Date: Sun, 09 Mar 2003 11:21:29 -0600 Subject: [Glade-devel] Re: glade code generation In-Reply-To: Message from Bill Haneman of "Sun, 09 Mar 2003 13:02:46 GMT." <1047214965.4611.20.camel@taistealai.ireland.sun.com> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> <3E67C566.1000107@petig-baender.de> <1047076096.1225.36.camel@localhost.localdomain> <1047123218.1270.10.camel@localhost.localdomain> <1047138616.4616.2.camel@taistealai.ireland.sun.com> <20030309024446.3C3F04A5ED@jcomain> <1047214965.4611.20.camel@taistealai.ireland.sun.com> Message-ID: <20030309172129.867E64A5ED@jcomain> Bill Haneman wrote: > I do believe that handler stub generation is useful. I advocate > improving it, not removing it. > Dissatisfactor with the UI generation code is what started the > discussion. Right. But AFAIR, no effective argument has been advanced against the UI generation code. Somewhat valid arguments have been advanced against generating stubs, though---and these have been used in the overall conversation. So, lest anyone lose sight of the fact that they apply /only/ to stub generation, I thought I'd throw that out. In any case, I'm curious what value you see in stub generation (over and above prototype generation, which can go into a non-modifiable file in C)? Jon Cast From biswapesh_chatterjee@tcscal.co.in Mon Mar 10 04:15:14 2003 From: biswapesh_chatterjee@tcscal.co.in (Biswapesh Chattopadhyay) Date: 10 Mar 2003 09:45:14 +0530 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <20030309172129.867E64A5ED@jcomain> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> <3E67C566.1000107@petig-baender.de> <1047076096.1225.36.camel@localhost.localdomain> <1047123218.1270.10.camel@localhost.localdomain> <1047138616.4616.2.camel@taistealai.ireland.sun.com> <20030309024446.3C3F04A5ED@jcomain> <1047214965.4611.20.camel@taistealai.ireland.sun.com> <20030309172129.867E64A5ED@jcomain> Message-ID: <1047269714.13896.8.camel@A5-1877> One small thing: once we integrate Glade into Anjuta, the IDE will take care of generating prototypes and stubs, and keeping track of modified ones, etc. through sourcebase parsers. I'm hoping enough people will be using Glade as part of the IDE (as opposed to a standalone app) to make this point somwwhat moot. We are planning to generate: 1) Prototypes in header files (one file per top level widget) 2) Stubs for the callbacks (One C file per top-level widget) 3) One function (proto + actual code) to load and show the GUI using libglade. OR 3a) One function to generate the code to create the GUI (probably won't be in the first implementation) We will use sourcebase to keep track of which functions have been generated and thus will avoid: 1. Generation of duplicate code 2. Overwriting user-changed code. (The user is expected to change (2) and (3) but not (1) or (3a). Of course, he can add more functions to the header/source files and we will use sourcebase to keep these intact). Does anyone see anything wrong with the above approach ? Rgds, Biswa. > Bill Haneman wrote: > > > > I do believe that handler stub generation is useful. I advocate > > improving it, not removing it. > > > Dissatisfactor with the UI generation code is what started the > > discussion. > > Right. But AFAIR, no effective argument has been advanced against the > UI generation code. Somewhat valid arguments have been advanced against > generating stubs, though---and these have been used in the overall > conversation. So, lest anyone lose sight of the fact that they apply > /only/ to stub generation, I thought I'd throw that out. > > In any case, I'm curious what value you see in stub generation (over and > above prototype generation, which can go into a non-modifiable file in > C)? > > Jon Cast > _______________________________________________ > Glade-devel maillist - Glade-devel@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/glade-devel -- Rgds, Biswa. From mleduc@savoirfairelinux.net Mon Mar 10 16:27:41 2003 From: mleduc@savoirfairelinux.net (Mathieu Leduc-Hamel) Date: Mon, 10 Mar 2003 11:27:41 -0500 Subject: [Glade-devel] help for libglade-convert Message-ID: <1047313661.3e6cbcfdd4255@webmail.savoirfairelinux.net> Hi, I don't know if anybody here can help me but I cannot find any mailing-list about libglade and libglade-convert on the net. I used glade at work, we started a big management project with glade1, now my boss want to transfert the project to gtk2, then I try the libglade-convert script. But I had a problem. The position, lenght and the width of the widgets were not keeped. I found that it was because the function used in glade were depracated in gtk2. But it seem that in this condition they were not transfered, with libglade-convert in their format in glade2. Can anybody help? what can I do? I have too many widget in my program to resize all of them and to place all of them at the right place... -- Mathieu Leduc-Hamel Linux dev - Savoir-faire linux inc. From pborelli@katamail.com Tue Mar 11 18:00:20 2003 From: pborelli@katamail.com (paolo borelli) Date: 11 Mar 2003 19:00:20 +0100 Subject: [Glade-devel] [patch, glade3] glade_util_path_is_writable Message-ID: <1047405536.31925.10.camel@localhost.localdomain> --=-bd5iyUCfUQkEor449OBw Content-Type: text/plain Content-Transfer-Encoding: 7bit I noticed that this function is marked with glade_implement_me()... What about the attached patch? I'm probably missing something, since it can't be so trivial ;) Maybe should it also take care of displaying an error dialog or are the callers supposed to check the return value and display the error message? ciao paolo --=-bd5iyUCfUQkEor449OBw Content-Disposition: attachment; filename=glade-path-writable.patch Content-Type: text/plain; name=glade-path-writable.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- gnome2/glade3/src/glade-utils.c 2002-05-02 11:11:09.000000000 +0200 +++ glade3/src/glade-utils.c 2003-03-11 18:31:34.000000000 +0100 @@ -25,14 +25,15 @@ #include "glade.h" #include #include "glade-project-window.h" - +#include gboolean glade_util_path_is_writable (const gchar *full_path) { - glade_implement_me (); - - return TRUE; + if (access (full_path, W_OK) == 0) + return TRUE; + else + return FALSE; } void --=-bd5iyUCfUQkEor449OBw-- From e98cuenc@free.fr Tue Mar 11 20:17:13 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 11 Mar 2003 21:17:13 +0100 Subject: [Glade-devel] [patch, glade3] glade_util_path_is_writable In-Reply-To: <1047405536.31925.10.camel@localhost.localdomain> References: <1047405536.31925.10.camel@localhost.localdomain> Message-ID: <1047413834.1115.17.camel@localhost.localdomain> Hi Paolo! On Tue, 2003-03-11 at 19:00, paolo borelli wrote: > I noticed that this function is marked with glade_implement_me()... > > What about the attached patch? I'm probably missing something, since it > can't be so trivial ;) You're right :-) First, access is not portable enough. Second, a function like glade_util_path_is_writable can't be useful, because we can have a race condition if we suppose that the writability of a file will not change between the glade_util_path_is_writable call and the time when we really write. I've thus removed the function, and removed its only use, which was redundant anyway, as we were checking if we actually wrote anything. The only need for this function will be to optimize the save stage, cutting the processus at the very beginning if we detect that the file is not writable, that it's not worth the effort, and it can be misused too easily. Thank you anyway for spotting the problem, and keep up the good work! Cheers, From e98cuenc@free.fr Tue Mar 11 20:36:03 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 11 Mar 2003 21:36:03 +0100 Subject: [Glade-devel] Re: help for libglade-convert Message-ID: <1047414964.1536.29.camel@localhost.localdomain> Hi Mathieu! > But I had a problem. The position, lenght and the width of the widgets > were not keeped. I found that it was because the function used in > glade were depracated in gtk2. But it seem that in this condition they > were not transfered, with libglade-convert in their format in glade2. James is the maintainer of libglade & libglade-convert. You can submit a bug report on bugzilla.gnome.org (module libglade, component libglade-convert). libglade-convert is itself a little python script, and without having about I find it quite understandable. If you receive no reply, you try sending me one of the glade files that is not translated correctly (the simplest, the better), and I will take a look. But you will be in better hands if James takes a look at the problem ;-) Cheers, From christof@petig-baender.de Mon Mar 10 21:58:04 2003 From: christof@petig-baender.de (Christof Petig) Date: Mon, 10 Mar 2003 22:58:04 +0100 Subject: [Glade-devel] Re: glade code generation In-Reply-To: <20030309172129.867E64A5ED@jcomain> References: <1046299405.10038.23.camel@localhost.localdomain> <1046302078.1655.26.camel@localhost.localdomain> <20030227002158.7D8B84A5F8@jcomain> <1046306197.1655.40.camel@localhost.localdomain> <3E67C566.1000107@petig-baender.de> <1047076096.1225.36.camel@localhost.localdomain> <1047123218.1270.10.camel@localhost.localdomain> <1047138616.4616.2.camel@taistealai.ireland.sun.com> <20030309024446.3C3F04A5ED@jcomain> <1047214965.4611.20.camel@taistealai.ireland.sun.com> <20030309172129.867E64A5ED@jcomain> Message-ID: <3E6D0A6C.1030901@petig-baender.de> Jon Cast wrote: > Bill Haneman wrote: > > >>I do believe that handler stub generation is useful. I advocate >>improving it, not removing it. > > >>Dissatisfactor with the UI generation code is what started the >>discussion. > > > Right. But AFAIR, no effective argument has been advanced against the > UI generation code. Somewhat valid arguments have been advanced against > generating stubs, though---and these have been used in the overall > conversation. So, lest anyone lose sight of the fact that they apply > /only/ to stub generation, I thought I'd throw that out. > > In any case, I'm curious what value you see in stub generation (over and > above prototype generation, which can go into a non-modifiable file in > C)? stub generation enables the programmer to test the program before everything is implemented. It gives an easy start, and enables you to test your build environment before you do any error-prone modifications to the project. Christof From damon@karuna.uklinux.net Thu Mar 13 20:54:43 2003 From: damon@karuna.uklinux.net (Damon Chaplin) Date: Thu, 13 Mar 2003 20:54:43 +0000 Subject: [Glade-devel] commit -- add_signal signal Message-ID: <3E70F013.4060104@karuna.uklinux.net> On Sat, 2003-03-08 at 16:24, Joaquin Cuenca Abela wrote: > I've added a "add_signal" to the GladeEditor widget (the properties > window). > > To generate a prototype of the signal, you can do: > > static void > glade_editor_add_signal_cb (GladeEditor *editor, const char *widget_id, > GType widget_type, guint signal_id, > const char *callback_name) > { > GSignalQuery query; > unsigned int i; > > g_signal_query (signal_id, &query); > printf ("%s %s(%s widget, ", g_type_name (query.return_type), > callback_name, g_type_name (query.itype)); > > for (i = 0; i < query.n_params; i++) > printf ("%s arg%d, ", g_type_name (query.param_types[i]), i); > > printf ("gpointer data);\n"); > } > > and hook the glade_editor_add_signal_cb to the "add_signal" of the > GladeEditor widget. You might want to pinch glade-2 code here, as it provides nice argument names instead of "argXX" (at least for standard GTK+/GNOME signals). It uses a hard-coded table, that I had to create manually. That isn't ideal, but is the best we can do at present. (Or maybe you could put this stuff into the widget description XML files.) The code is in gb_widget_write_signal_handler_source() and lookup_signal_arg_names() in glade/gbsource.c. Damon From pborelli@katamail.com Thu Mar 13 22:49:07 2003 From: pborelli@katamail.com (paolo borelli) Date: 13 Mar 2003 23:49:07 +0100 Subject: [Glade-devel] [patch, glade3] turn "how Clipboard" into a toggle item Message-ID: <1047595655.6246.14.camel@localhost.localdomain> --=-54TRvhHndnhEwMXAuzxY Content-Type: text/plain Content-Transfer-Encoding: 7bit This is the second part of the patch that went in some days ago. It turn also "Show Clipboard" into a toggle button. PS Joaquin: the two trivial patches deleting gpw_widget_tree_keypress_cb and changing the "save as" stock item simply got lost or you didn't merge them because they were broken? --=-54TRvhHndnhEwMXAuzxY Content-Disposition: attachment; filename=toggle-clipboard.patch Content-Type: text/x-patch; name=toggle-clipboard.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -pur gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-13 23:21:06.000000000 +0100 +++ glade3/ChangeLog 2003-03-13 23:26:44.000000000 +0100 @@ -1,3 +1,11 @@ +2003-03-13 Paolo Borelli + + * src/glade-project-window.c: turn also the "Show Clipboard" menu item + into a toggle item. + * src/glade-clipboard.[ch]: removed glade_clipboard_create() and + glade_clipboard_show_view(), replaced by equivalent static functions + in glade-project-window.c where they belong. + 2003-03-12 Joaquin Cuenca Abela * src/glade-property-class.c: fix a memory leak, and remove yet another diff -pur gnome2/glade3/src/glade-clipboard.c glade3/src/glade-clipboard.c --- gnome2/glade3/src/glade-clipboard.c 2002-05-02 11:11:09.000000000 +0200 +++ glade3/src/glade-clipboard.c 2003-03-13 23:17:09.000000000 +0100 @@ -253,36 +253,3 @@ glade_clipboard_paste (GladeClipboard * glade_clipboard_remove (clipboard, widget); } -void -glade_clipboard_create (GladeProjectWindow * gpw) -{ - g_return_if_fail (gpw != NULL); - - if (gpw->clipboard == NULL) { - GladeClipboard *clipboard; - - clipboard = glade_clipboard_new (); - gpw->clipboard = clipboard; - } -} - -void -glade_clipboard_show_view (GladeProjectWindow * gpw) -{ - g_return_if_fail (gpw != NULL); - - if (gpw->clipboard->view == NULL) { - GtkWidget *view; - - view = glade_clipboard_view_new (gpw->clipboard); - gtk_window_set_title (GTK_WINDOW (view), _("Clipboard")); - g_signal_connect_data (G_OBJECT (view), "delete_event", - G_CALLBACK (gtk_widget_hide), - view, NULL, 0); - - gpw->clipboard->view = view; - } - - if (!GTK_WIDGET_VISIBLE (gpw->clipboard->view)) - gtk_widget_show (GTK_WIDGET (gpw->clipboard->view)); -} diff -pur gnome2/glade3/src/glade-clipboard.h glade3/src/glade-clipboard.h --- gnome2/glade3/src/glade-clipboard.h 2002-03-18 09:39:43.000000000 +0100 +++ glade3/src/glade-clipboard.h 2003-03-13 19:53:48.000000000 +0100 @@ -32,8 +32,5 @@ void glade_clipboard_copy (GladeClipboar void glade_clipboard_paste (GladeClipboard * clipboard, GladePlaceholder * placeholder); -void glade_clipboard_create (GladeProjectWindow * gpw); -void glade_clipboard_show_view (GladeProjectWindow * gpw); - G_END_DECLS #endif /* __GLADE_CLIPBOARD_H__ */ diff -pur gnome2/glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- gnome2/glade3/src/glade-project-window.c 2003-03-11 15:22:01.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-13 20:14:49.000000000 +0100 @@ -28,6 +28,7 @@ #include "glade-palette.h" #include "glade-editor.h" #include "glade-clipboard.h" +#include "glade-clipboard-view.h" #include "glade-widget.h" #include "glade-widget-class.h" #include "glade-parameter.h" @@ -50,7 +51,7 @@ static void gpw_quit_cb (void); static void gpw_toggle_palette_cb (void); static void gpw_toggle_editor_cb (void); static void gpw_toggle_widget_tree_cb (void); -static void gpw_show_clipboard_cb (void); +static void gpw_toggle_clipboard_cb (void); static void gpw_undo_cb (void); static void gpw_redo_cb (void); @@ -219,8 +220,7 @@ static GtkItemFactoryEntry menu_items[] { "/View/_Palette", NULL, gpw_toggle_palette_cb, 0, "" }, { "/View/Property _Editor", NULL, gpw_toggle_editor_cb, 0, "" }, { "/View/_Widget Tree", NULL, gpw_toggle_widget_tree_cb, 0, "" }, - { "/View/sep1", NULL, NULL, 0, "" }, - { "/View/Show _Clipboard", NULL, gpw_show_clipboard_cb, 0, "" }, + { "/View/_Clipboard", NULL, gpw_toggle_clipboard_cb, 0, "" }, /* ============ PROJECT=================== */ { "/Project", NULL, 0, 0, "" }, @@ -530,6 +509,90 @@ gpw_hide_widget_tree (GladeProjectWindow } +static void +gpw_create_clipboard (GladeProjectWindow *gpw) +{ + g_return_if_fail (gpw != NULL); + + if (gpw->clipboard == NULL) { + GladeClipboard *clipboard; + + clipboard = glade_clipboard_new (); + gpw->clipboard = clipboard; + } +} + +static gboolean +gpw_hide_clipboard_view_on_delete (GtkWidget *clipboard_view, gpointer not_used, + GtkItemFactory *item_factory) +{ + GtkWidget *clipboard_item; + + gtk_widget_hide (clipboard_view); + + clipboard_item = gtk_item_factory_get_item (item_factory, + "
/View/Clipboard"); + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (clipboard_item), FALSE); + + /* return true so that the clipboard view is not destroyed */ + return TRUE; +} + +static void +gpw_create_clipboard_view (GladeProjectWindow *gpw) +{ + GtkWidget *view; + GtkWidget *clipboard_item; + + gpw_create_clipboard (gpw); + + view = glade_clipboard_view_new (gpw->clipboard); + gtk_window_set_title (GTK_WINDOW (view), _("Clipboard")); + g_signal_connect (G_OBJECT (view), "delete_event", + G_CALLBACK (gpw_hide_clipboard_view_on_delete), + gpw->item_factory); + gpw->clipboard->view = view; + + clipboard_item = gtk_item_factory_get_item (gpw->item_factory, + "
/View/Clipboard"); + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (clipboard_item), TRUE); +} + +static void +gpw_show_clipboard_view (GladeProjectWindow *gpw) +{ + GtkWidget *clipboard_item; + + g_return_if_fail (gpw != NULL); + + if (gpw->clipboard == NULL) + gpw_create_clipboard (gpw); + + if (gpw->clipboard->view == NULL) + gpw_create_clipboard_view (gpw); + + gtk_widget_show_all (GTK_WIDGET (gpw->clipboard->view)); + + clipboard_item = gtk_item_factory_get_item (gpw->item_factory, + "
/View/Clipboard"); + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (clipboard_item), TRUE); +} + +static void +gpw_hide_clipboard_view (GladeProjectWindow *gpw) +{ + GtkWidget *clipboard_item; + + g_return_if_fail (gpw != NULL); + + gtk_widget_hide (GTK_WIDGET (gpw->clipboard->view)); + + clipboard_item = gtk_item_factory_get_item (gpw->item_factory, + "
/View/Clipboard"); + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (clipboard_item), FALSE); + +} + static void gpw_toggle_palette_cb (void) { @@ -579,11 +642,19 @@ gpw_toggle_widget_tree_cb (void) } static void -gpw_show_clipboard_cb (void) +gpw_toggle_clipboard_cb (void) { + GtkWidget *clipboard_item; + GladeProjectWindow *gpw = glade_project_window_get (); - glade_clipboard_show_view (gpw); + clipboard_item = gtk_item_factory_get_item (gpw->item_factory, + "
/View/Clipboard"); + + if (gtk_check_menu_item_get_active (GTK_CHECK_MENU_ITEM (clipboard_item))) + gpw_show_clipboard_view (gpw); + else + gpw_hide_clipboard_view (gpw); } static GtkWidget * @@ -651,7 +722,7 @@ glade_project_window_new (GList *catalog glade_project_window = gpw; gpw_create_palette (gpw); gpw_create_editor (gpw); - glade_clipboard_create (gpw); + gpw_create_clipboard (gpw); return gpw; } --=-54TRvhHndnhEwMXAuzxY-- From e98cuenc@free.fr Thu Mar 13 23:09:15 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 14 Mar 2003 00:09:15 +0100 Subject: [Glade-devel] [patch, glade3] turn "how Clipboard" into a toggle item In-Reply-To: <1047595655.6246.14.camel@localhost.localdomain> References: <1047595655.6246.14.camel@localhost.localdomain> Message-ID: <1047596956.1113.3.camel@localhost.localdomain> On Thu, 2003-03-13 at 23:49, paolo borelli wrote: > This is the second part of the patch that went in some days ago. It turn also "Show Clipboard" into a toggle button. > > PS > Joaquin: the two trivial patches deleting gpw_widget_tree_keypress_cb and changing the "save as" stock item simply got lost or you didn't merge them because they were broken? They got lost. Can you please resend them to me? Thank you! Cheers, From biswapesh_chatterjee@tcscal.co.in Fri Mar 14 04:48:23 2003 From: biswapesh_chatterjee@tcscal.co.in (Biswapesh Chattopadhyay) Date: 14 Mar 2003 10:18:23 +0530 Subject: [Glade-devel] commit -- add_signal signal In-Reply-To: <3E70F013.4060104@karuna.uklinux.net> References: <3E70F013.4060104@karuna.uklinux.net> Message-ID: <1047617302.1156.7.camel@A5-1877> How about pinching the glade-2 menu editing code for glade-3. That seems to be the only major thing missing before we go for anjuta integration. Also, it would be nice to enhance the build so that external apps can use the header files and libs for the widgets. i.e. put teh headers in $prefix/include/glade-3, create a shared lib libglade-3.so and a .pc file for pkg-config so that apps can test for availability of the package. On Fri, 2003-03-14 at 02:24, glade-devel-admin@lists.ximian.com wrote: > On Sat, 2003-03-08 at 16:24, Joaquin Cuenca Abela wrote: > > I've added a "add_signal" to the GladeEditor widget (the properties > > window). > > > > To generate a prototype of the signal, you can do: > > > > static void > > glade_editor_add_signal_cb (GladeEditor *editor, const char *widget_id, > > GType widget_type, guint signal_id, > > const char *callback_name) > > { > > GSignalQuery query; > > unsigned int i; > > > > g_signal_query (signal_id, &query); > > printf ("%s %s(%s widget, ", g_type_name (query.return_type), > > callback_name, g_type_name (query.itype)); > > > > for (i = 0; i < query.n_params; i++) > > printf ("%s arg%d, ", g_type_name > (query.param_types[i]), i); > > > > printf ("gpointer data);\n"); > > } > > > > and hook the glade_editor_add_signal_cb to the "add_signal" of the > > GladeEditor widget. > > You might want to pinch glade-2 code here, as it provides nice argument > names instead of "argXX" (at least for standard GTK+/GNOME signals). > It uses a hard-coded table, that I had to create manually. That isn't > ideal, but is the best we can do at present. (Or maybe you could put > this stuff into the widget description XML files.) > > The code is in gb_widget_write_signal_handler_source() and > lookup_signal_arg_names() in glade/gbsource.c. > > Damon > > _______________________________________________ > Glade-devel maillist - Glade-devel@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/glade-devel -- Rgds, Biswa. From e98cuenc@free.fr Fri Mar 14 07:16:38 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 14 Mar 2003 08:16:38 +0100 Subject: [Glade-devel] commit -- add_signal signal In-Reply-To: <1047617302.1156.7.camel@A5-1877> References: <3E70F013.4060104@karuna.uklinux.net> <1047617302.1156.7.camel@A5-1877> Message-ID: <1047626200.1184.2.camel@localhost.localdomain> On Fri, 2003-03-14 at 05:48, Biswapesh Chattopadhyay wrote: > How about pinching the glade-2 menu editing code for glade-3. That seems > to be the only major thing missing before we go for anjuta integration. I've already started doing it :-) It seems that we're in sync... > Also, it would be nice to enhance the build so that external apps can > use the header files and libs for the widgets. i.e. put teh headers in > $prefix/include/glade-3, create a shared lib libglade-3.so and a .pc > file for pkg-config so that apps can test for availability of the > package. Here we have a problem, as I'm auto{conf,make} impaired. If you can modify yourself the build, or give me some hints, I will be very grateful. Cheers, From biswapesh_chatterjee@tcscal.co.in Fri Mar 14 07:30:34 2003 From: biswapesh_chatterjee@tcscal.co.in (Biswapesh Chattopadhyay) Date: 14 Mar 2003 13:00:34 +0530 Subject: [Glade-devel] commit -- add_signal signal In-Reply-To: <1047626200.1184.2.camel@localhost.localdomain> References: <3E70F013.4060104@karuna.uklinux.net> <1047617302.1156.7.camel@A5-1877> <1047626200.1184.2.camel@localhost.localdomain> Message-ID: <1047627034.1152.19.camel@A5-1877> On Fri, 2003-03-14 at 12:46, Joaquin Cuenca Abela wrote: > On Fri, 2003-03-14 at 05:48, Biswapesh Chattopadhyay wrote: > > How about pinching the glade-2 menu editing code for glade-3. That seems > > to be the only major thing missing before we go for anjuta integration. > > I've already started doing it :-) > It seems that we're in sync... Great stuff ! Removing some of the warnings would be nice too. > > > Also, it would be nice to enhance the build so that external apps can > > use the header files and libs for the widgets. i.e. put teh headers in > > $prefix/include/glade-3, create a shared lib libglade-3.so and a .pc > > file for pkg-config so that apps can test for availability of the > > package. > > Here we have a problem, as I'm auto{conf,make} impaired. > If you can modify yourself the build, or give me some hints, I will be > very grateful. I'll try and patch something up tommorrow (I'm severely time-impaired today :-() > > Cheers, > -- Rgds, Biswa. From pborelli@katamail.com Fri Mar 14 17:33:48 2003 From: pborelli@katamail.com (paolo borelli) Date: 14 Mar 2003 18:33:48 +0100 Subject: [Glade-devel] [patch, glade3] resend of trivial patch lost Message-ID: <1047651756.2156.2.camel@localhost.localdomain> --=-6MqjhocF8Zod5ybG/7VR Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! Here are the 2 trivial patches that got lost. I've merged them in one diff, hope tht's ok. ciao. --=-6MqjhocF8Zod5ybG/7VR Content-Disposition: attachment; filename=rm-gpw-widget-tree-keypress-cb.patch Content-Type: text/x-patch; name=rm-gpw-widget-tree-keypress-cb.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -pur gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-14 14:32:52.000000000 +0100 +++ glade3/ChangeLog 2003-03-14 15:15:28.000000000 +0100 @@ -1,3 +1,8 @@ +2003-03-14 Paolo Borelli + + * src/glade-project-window.c: remove gpw_keypress_widget_tree_cb + * src/glade-project-window.c: use proper stock icon for "save as" + 2003-03-13 Paolo Borelli * src/glade-project-window.c: turn also the "Show Clipboard" menu item diff -pur gnome2/glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- gnome2/glade3/src/glade-project-window.c 2003-03-14 14:32:53.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-14 15:16:52.000000000 +0100 @@ -198,12 +198,13 @@ static GtkItemFactoryEntry menu_items[] { /* ============ FILE ===================== */ { "/_File", NULL, 0, 0, "" }, - { "/File/_New", "N", gpw_new_cb, 0, "", GTK_STOCK_NEW }, - { "/File/_Open", "O", gpw_open_cb, 0, "", GTK_STOCK_OPEN }, - { "/File/_Save", "S", gpw_save_cb, 0, "", GTK_STOCK_SAVE }, - { "/File/Save _As...", NULL, gpw_save_as_cb, 0, "", GTK_STOCK_SAVE }, - { "/File/sep1", NULL, NULL, 0, "" }, - { "/File/_Quit", "Q", gpw_quit_cb, 0, "", GTK_STOCK_QUIT }, + { "/File/_New", "N", gpw_new_cb, 0, "", GTK_STOCK_NEW }, + { "/File/_Open", "O", gpw_open_cb, 0, "", GTK_STOCK_OPEN }, + { "/File/_Save", "S", gpw_save_cb, 0, "", GTK_STOCK_SAVE }, + { "/File/Save _As...", "S", gpw_save_as_cb, 0, "", GTK_STOCK_SAVE_AS }, + { "/File/sep1", NULL, NULL, 0, "" }, + { "/File/_Quit", "Q", gpw_quit_cb, 0, "", GTK_STOCK_QUIT }, + /* ============ EDIT ===================== */ { "/Edit", NULL, 0, 0, "" }, @@ -437,25 +438,6 @@ gpw_hide_editor (GladeProjectWindow *gpw gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (editor_item), FALSE); } -static gboolean -gpw_key_press_widget_tree_cb (GtkWidget *widget_tree, GdkEventKey *event, - GtkItemFactory *item_factory) -{ - - GtkWidget *widget_tree_item; - - if (event->keyval == GDK_Escape) { - gtk_widget_hide (widget_tree); - widget_tree_item = gtk_item_factory_get_item (item_factory, - "
/View/Widget Tree"); - gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (widget_tree_item), - FALSE); - - return TRUE; - } - return FALSE; -} - static gboolean gpw_hide_widget_tree_on_delete (GtkWidget *widget_tree, gpointer not_used, GtkItemFactory *item_factory) @@ -488,8 +470,6 @@ gpw_create_widget_tree (GladeProjectWind glade_project_view_set_project (view, gpw->project); g_signal_connect (G_OBJECT (widget_tree), "delete_event", G_CALLBACK (gpw_hide_widget_tree_on_delete), gpw->item_factory); - g_signal_connect (G_OBJECT (widget_tree), "key_press_event", - G_CALLBACK (gpw_key_press_widget_tree_cb), gpw->item_factory); widget_tree_item = gtk_item_factory_get_item (gpw->item_factory, "
/View/Widget Tree"); --=-6MqjhocF8Zod5ybG/7VR-- From e98cuenc@free.fr Fri Mar 14 19:41:48 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 14 Mar 2003 20:41:48 +0100 Subject: [Glade-devel] commit -- add_signal signal In-Reply-To: <1047627034.1152.19.camel@A5-1877> References: <3E70F013.4060104@karuna.uklinux.net> <1047617302.1156.7.camel@A5-1877> <1047626200.1184.2.camel@localhost.localdomain> <1047627034.1152.19.camel@A5-1877> Message-ID: <1047670911.1115.4.camel@localhost.localdomain> On Fri, 2003-03-14 at 08:30, Biswapesh Chattopadhyay wrote: > On Fri, 2003-03-14 at 12:46, Joaquin Cuenca Abela wrote: > > On Fri, 2003-03-14 at 05:48, Biswapesh Chattopadhyay wrote: > > > How about pinching the glade-2 menu editing code for glade-3. That seems > > > to be the only major thing missing before we go for anjuta integration. > > > > I've already started doing it :-) > > It seems that we're in sync... > > Great stuff ! Removing some of the warnings would be nice too. I removed them this past week. I've fixed all the crashes that I knew about, mem leakes and warnings. Current cvs version should be quite silent. If you find any warning/crash/anything, just send an email to the list, I will try to fix it. Cheers, From pborelli@katamail.com Sat Mar 15 12:54:21 2003 From: pborelli@katamail.com (paolo borelli) Date: 15 Mar 2003 13:54:21 +0100 Subject: [Glade-devel] [patch, glade3] don't warn on save file selector "cancel" Message-ID: <1047732860.11572.12.camel@localhost.localdomain> --=-rR3zZvm4YxRV7SBCYbqD Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! Thanks to Joaquin for applying my previos patches. The one attached fix the following problem: when the user is prompted with a file selection dialog on "save" or "save as" and clicks on "cancel" a g_warning is showed. ciao paolo --=-rR3zZvm4YxRV7SBCYbqD Content-Disposition: attachment; filename=save-no-warn-on-cancel.patch Content-Type: text/x-patch; name=save-no-warn-on-cancel.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -pur gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-15 13:48:36.000000000 +0100 +++ glade3/ChangeLog 2003-03-15 13:51:29.000000000 +0100 @@ -1,3 +1,7 @@ +2003-03-15 Paolo Borelli + + * src/glade-project.c: don't warn on save file selector "cancel" + 2003-03-14 Paolo Borelli * src/glade-project-window.c: remove gpw_keypress_widget_tree_cb diff -pur gnome2/glade3/src/glade-project.c glade3/src/glade-project.c --- gnome2/glade3/src/glade-project.c 2003-03-12 19:05:44.000000000 +0100 +++ glade3/src/glade-project.c 2003-03-15 13:49:56.000000000 +0100 @@ -631,6 +631,13 @@ glade_project_save (GladeProject *projec if (project->path == NULL) { g_free (project->name); project->path = glade_project_ui_get_path (_("Save ...")); + + /* If the user hit cancel, restore its previous name and return */ + if (project->path == NULL) { + project->path = backup; + return FALSE; + } + project->name = g_path_get_basename (project->path); g_free (backup); } @@ -665,7 +672,13 @@ glade_project_save_as (GladeProject *pro /* Keep the previous path */ backup = project->path; - project->path = glade_project_ui_get_path (_("Save ...")); + project->path = glade_project_ui_get_path (_("Save as ...")); + + /* If the user hit cancel, restore its previous name and return */ + if (project->path == NULL) { + project->path = backup; + return FALSE; + } /* On error, warn and restore its previous name and return */ if (!glade_project_save_to_file (project, project->path)) { --=-rR3zZvm4YxRV7SBCYbqD-- From e98cuenc@free.fr Mon Mar 17 22:28:28 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 17 Mar 2003 23:28:28 +0100 Subject: [Glade-devel] [patch, glade3] don't warn on save file selector "cancel" In-Reply-To: <1047732860.11572.12.camel@localhost.localdomain> References: <1047732860.11572.12.camel@localhost.localdomain> Message-ID: <1047940108.1112.2.camel@localhost.localdomain> On Sat, 2003-03-15 at 13:54, paolo borelli wrote: > Hi! > > Thanks to Joaquin for applying my previos patches. > > The one attached fix the following problem: when the user is prompted > with a file selection dialog on "save" or "save as" and clicks on > "cancel" a g_warning is showed. I committed this patch, but I forget to send an email to the ML. Sorry. Paolo, would you be interested in having cvs access? I would still like to keep an eye on the hardest patches, but for most of the patches you will be able to commit directly. If so, contact me privately and we will email somebody in charge of the gnome cvs accounts. Cheers, From pborelli@katamail.com Tue Mar 18 15:10:29 2003 From: pborelli@katamail.com (paolo borelli) Date: 18 Mar 2003 16:10:29 +0100 Subject: [Glade-devel] [patch, glade3] glade_utils_hide_window Message-ID: <1048000075.7811.6.camel@localhost.localdomain> --=-DMvZxdF5rGpyAAkoca/j Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! The attached patch introduces glade_utils_hide_window(), a function which wraps gtk_widget_hide so that when a window is closed and then reshown it reappears in the same place where it was before; implemantation is taken from glade-2 utils.c. Then the patches use this function for the palette, widget tree, editor and clipboard. ciao paolo --=-DMvZxdF5rGpyAAkoca/j Content-Disposition: attachment; filename=util-hide-window.patch Content-Type: text/x-patch; name=util-hide-window.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -pur gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-15 15:36:41.000000000 +0100 +++ glade3/ChangeLog 2003-03-18 15:58:42.000000000 +0100 @@ -1,3 +1,8 @@ +2003-03-18 Paolo Borelli + + * src/glade-utils.[ch]: intrduce glade_utils_hide_window() + * src/glade-project-window.c: use it for the palette, editor etc. + 2003-03-15 Paolo Borelli * src/glade-project.c: don't warn on save file selector "cancel" diff -pur gnome2/glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- gnome2/glade3/src/glade-project-window.c 2003-03-14 20:44:28.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-18 15:56:21.000000000 +0100 @@ -39,6 +39,7 @@ #include "glade-project-window.h" #include "glade-command.h" #include "glade-debug.h" +#include "glade-utils.h" #include #include @@ -298,7 +299,7 @@ gpw_hide_palette_on_delete (GtkWidget *p { GtkWidget *palette_item; - gtk_widget_hide (GTK_WIDGET (palette)); + glade_util_hide_window (GTK_WIDGET (palette)); palette_item = gtk_item_factory_get_item (item_factory, "
/View/Palette"); gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (palette_item), FALSE); @@ -357,7 +358,7 @@ gpw_hide_palette (GladeProjectWindow *gp g_return_if_fail (gpw != NULL); - gtk_widget_hide (GTK_WIDGET (gpw->palette_window)); + glade_util_hide_window (GTK_WIDGET (gpw->palette_window)); palette_item = gtk_item_factory_get_item (gpw->item_factory, "
/View/Palette"); @@ -370,7 +371,7 @@ gpw_hide_editor_on_delete (GtkWidget *ed { GtkWidget *editor_item; - gtk_widget_hide (GTK_WIDGET (editor)); + glade_util_hide_window (GTK_WIDGET (editor)); editor_item = gtk_item_factory_get_item (item_factory, "
/View/Property Editor"); gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (editor_item), FALSE); @@ -431,7 +432,7 @@ gpw_hide_editor (GladeProjectWindow *gpw g_return_if_fail (gpw != NULL); - gtk_widget_hide (GTK_WIDGET (gpw->editor_window)); + glade_util_hide_window (GTK_WIDGET (gpw->editor_window)); editor_item = gtk_item_factory_get_item (gpw->item_factory, "
/View/Property Editor"); @@ -444,7 +445,7 @@ gpw_hide_widget_tree_on_delete (GtkWidge { GtkWidget *widget_tree_item; - gtk_widget_hide (widget_tree); + glade_util_hide_window (widget_tree); widget_tree_item = gtk_item_factory_get_item (item_factory, "
/View/Widget Tree"); @@ -502,7 +503,7 @@ gpw_hide_widget_tree (GladeProjectWindow g_return_if_fail (gpw != NULL); - gtk_widget_hide (GTK_WIDGET (gpw->widget_tree)); + glade_util_hide_window (GTK_WIDGET (gpw->widget_tree)); widget_tree_item = gtk_item_factory_get_item (gpw->item_factory, "
/View/Widget Tree"); @@ -529,7 +530,7 @@ gpw_hide_clipboard_view_on_delete (GtkWi { GtkWidget *clipboard_item; - gtk_widget_hide (clipboard_view); + glade_util_hide_window (clipboard_view); clipboard_item = gtk_item_factory_get_item (item_factory, "
/View/Clipboard"); @@ -586,7 +587,7 @@ gpw_hide_clipboard_view (GladeProjectWin g_return_if_fail (gpw != NULL); - gtk_widget_hide (GTK_WIDGET (gpw->clipboard->view)); + glade_util_hide_window (GTK_WIDGET (gpw->clipboard->view)); clipboard_item = gtk_item_factory_get_item (gpw->item_factory, "
/View/Clipboard"); diff -pur gnome2/glade3/src/glade-utils.c glade3/src/glade-utils.c --- gnome2/glade3/src/glade-utils.c 2003-03-11 21:20:17.000000000 +0100 +++ glade3/src/glade-utils.c 2003-03-18 15:56:21.000000000 +0100 @@ -92,3 +92,27 @@ glade_util_ui_warn (const gchar *warning gtk_dialog_run (GTK_DIALOG (dialog)); gtk_widget_destroy (dialog); } + +/* + * This allows the window to appear in the same place when it's shown again. + */ +gboolean +glade_util_hide_window (GtkWidget *widget) +{ + gint x, y; + gboolean set_position = FALSE; + + /* remember position of window */ + if (widget->window) { + gdk_window_get_root_origin (widget->window, &x, &y); + set_position = TRUE; + } + + gtk_widget_hide (widget); + + if (set_position) + gtk_widget_set_uposition (widget, x, y); + + return TRUE; +} + diff -pur gnome2/glade3/src/glade-utils.h glade3/src/glade-utils.h --- gnome2/glade3/src/glade-utils.h 2003-03-11 21:20:17.000000000 +0100 +++ glade3/src/glade-utils.h 2003-03-18 15:56:21.000000000 +0100 @@ -14,6 +14,7 @@ G_BEGIN_DECLS void glade_util_widget_set_tooltip (GtkWidget *widget, const gchar *str); GType glade_util_get_type_from_name (const gchar *name); void glade_util_ui_warn (const gchar *warning); +gboolean glade_util_hide_window (GtkWidget *widget); G_END_DECLS --=-DMvZxdF5rGpyAAkoca/j-- From pborelli@katamail.com Thu Mar 20 17:48:43 2003 From: pborelli@katamail.com (paolo borelli) Date: 20 Mar 2003 18:48:43 +0100 Subject: [Glade-devel] [patch, glade3] add status bar Message-ID: <1048182523.3234.13.camel@localhost.localdomain> --=-HqkRra1ideSgc9Wxvjun Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! The patch attached adds a statusbar to glade-3. Note that with this patch the status bar doesn't display any messages yet; I hope to submit other patches adding messages, but I'm still reflecting on how to handle context_id... glade-2 just passed 1 having only 1 context, but since glade-3 can handle multiple projects maybe it would be nice to have a context per projet so that messages as "Project Saved" refer only to the proper project... or maybe I misunderstood the whole thing? ;) The patch also contains minor cleanups and some trivial ui changes I did along the way, that make glade more similar to other gnome apps (add a separator, move Help near the other menus and add a "New" button to the toolbar). Note that the patch, even if independent, is diffed against the last patch I sent (glade_utils_hide_window); if you don't plan to apply that one, tell me and I'll rediff this. ciao paolo --=-HqkRra1ideSgc9Wxvjun Content-Disposition: attachment; filename=status-bar.patch Content-Type: text/x-patch; name=status-bar.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -pur ../glade3/ChangeLog glade3/ChangeLog --- ../glade3/ChangeLog 2003-03-20 17:13:08.000000000 +0100 +++ glade3/ChangeLog 2003-03-20 17:52:05.000000000 +0100 @@ -1,3 +1,8 @@ +2003-03-20 Paolo Borelli + + * src/glade-project-window.[ch]: implement the statusbar; minor + cleanups and ui love along the way. + 2003-03-18 Paolo Borelli * src/glade-utils.[ch]: intrduce glade_utils_hide_window() diff -pur ../glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- ../glade3/src/glade-project-window.c 2003-03-20 17:13:08.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-20 17:22:22.000000000 +0100 @@ -188,12 +188,6 @@ gpw_redo_cb (void) glade_command_redo (); } -static void -gpw_delete_event (GtkWindow *w, gpointer not_used) -{ - gpw_quit_cb (); -} - static GtkItemFactoryEntry menu_items[] = { @@ -201,9 +195,10 @@ static GtkItemFactoryEntry menu_items[] { "/_File", NULL, 0, 0, "" }, { "/File/_New", "N", gpw_new_cb, 0, "", GTK_STOCK_NEW }, { "/File/_Open", "O", gpw_open_cb, 0, "", GTK_STOCK_OPEN }, + { "/File/sep1", NULL, NULL, 0, "" }, { "/File/_Save", "S", gpw_save_cb, 0, "", GTK_STOCK_SAVE }, { "/File/Save _As...", "S", gpw_save_as_cb, 0, "", GTK_STOCK_SAVE_AS }, - { "/File/sep1", NULL, NULL, 0, "" }, + { "/File/sep2", NULL, NULL, 0, "" }, { "/File/_Quit", "Q", gpw_quit_cb, 0, "", GTK_STOCK_QUIT }, @@ -228,13 +223,13 @@ static GtkItemFactoryEntry menu_items[] { "/Project", NULL, 0, 0, "" }, /* ============ HELP ===================== */ - { "/_Help", NULL, NULL, 0, "" }, + { "/_Help", NULL, NULL, 0, "" }, { "/Help/_About", NULL, gpw_about_cb, 0 }, }; static void -glade_project_window_construct_menu (GladeProjectWindow *gpw) +gpw_construct_menu (GladeProjectWindow *gpw) { GtkItemFactory *item_factory; GtkAccelGroup *accel_group; @@ -246,7 +241,7 @@ glade_project_window_construct_menu (Gla /* Item factory */ item_factory = gtk_item_factory_new (GTK_TYPE_MENU_BAR, "
", accel_group); gpw->item_factory = item_factory; - gtk_object_ref (GTK_OBJECT (item_factory)); + g_object_ref (G_OBJECT (item_factory)); gtk_object_sink (GTK_OBJECT (item_factory)); g_object_set_data_full (G_OBJECT (gpw->window), "
", @@ -261,12 +256,18 @@ glade_project_window_construct_menu (Gla } static void -glade_project_window_construct_toolbar (GladeProjectWindow *gpw) +gpw_construct_toolbar (GladeProjectWindow *gpw) { GtkWidget *toolbar; toolbar = gtk_toolbar_new (); - + + gtk_toolbar_insert_stock (GTK_TOOLBAR (toolbar), + GTK_STOCK_NEW, + "New project", + NULL, + G_CALLBACK (gpw_new_cb), + gpw, -1); gtk_toolbar_insert_stock (GTK_TOOLBAR (toolbar), GTK_STOCK_OPEN, "Open project", @@ -293,6 +294,24 @@ glade_project_window_construct_toolbar ( toolbar); } +static void +gpw_construct_statusbar (GladeProjectWindow *gpw) +{ + GtkWidget *statusbar; + + statusbar = gtk_statusbar_new (); + gpw->statusbar = statusbar; + + g_object_ref (G_OBJECT (statusbar)); + gtk_object_sink (GTK_OBJECT (statusbar)); + g_object_set_data_full (G_OBJECT (gpw->window), + "
", + statusbar, + (GDestroyNotify) g_object_unref); + + gtk_box_pack_end_defaults (GTK_BOX (gpw->main_vbox), statusbar); +} + static gboolean gpw_hide_palette_on_delete (GtkWidget *palette, gpointer not_used, GtkItemFactory *item_factory) @@ -659,6 +678,12 @@ gpw_toggle_clipboard_cb (void) gpw_hide_clipboard_view (gpw); } +static void +gpw_delete_event (GtkWindow *w, gpointer not_used) +{ + gpw_quit_cb (); +} + static GtkWidget * glade_project_window_create (GladeProjectWindow *gpw, GladeProjectView *view) { @@ -673,8 +698,10 @@ glade_project_window_create (GladeProjec gtk_container_add (GTK_CONTAINER (app), vbox); gpw->main_vbox = vbox; - glade_project_window_construct_menu (gpw); - glade_project_window_construct_toolbar (gpw); + gpw_construct_menu (gpw); + gpw_construct_toolbar (gpw); + gpw_construct_statusbar (gpw); + glade_project_window_refresh_undo_redo (gpw); g_signal_connect (G_OBJECT (app), "delete_event", Only in glade3/src: glade-project-window.c~ diff -pur ../glade3/src/glade-project-window.h glade3/src/glade-project-window.h --- ../glade3/src/glade-project-window.h 2003-03-20 17:12:21.000000000 +0100 +++ glade3/src/glade-project-window.h 2003-03-20 17:54:25.000000000 +0100 @@ -13,11 +13,10 @@ G_BEGIN_DECLS struct _GladeProjectWindow { - GtkWidget *window; /* Main window*/ + GtkWidget *window; /* Main window */ GtkWidget *main_vbox; - GtkWidget *statusbar; /* A pointer to the (not yet implemented) - * status bar. We might have to come up with - * a glade-statusbar object if it makes sense + GtkWidget *statusbar; /* A pointer to the status bar. We might have to come + * up with a glade-statusbar object if it makes sense */ GtkItemFactory *item_factory; /* A pointer to the Item factory. * We need it to be able to later add --=-HqkRra1ideSgc9Wxvjun-- From e98cuenc@free.fr Thu Mar 20 20:49:22 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 20 Mar 2003 21:49:22 +0100 Subject: [Glade-devel] commit -- Paolo patches Message-ID: <1048193363.1157.7.camel@localhost.localdomain> I've committed all the latests Paolo patches, except for a little change: the "New Project" button in the toolbar. Even if Paolo is right in that is almost a standard, and that it's used in almost every application, I don't find the "New Project" operation to be so usually selected as to be placed on the toolbar, so I've removed this change. I understand that this change it's subjective, but I would rather accept a couple of "undo & redo" buttons than a new project button. This point is open to discussion :-) Cheers, From e98cuenc@free.fr Thu Mar 20 21:43:22 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 20 Mar 2003 22:43:22 +0100 Subject: [Glade-devel] commit -- beginning of the menu editor Message-ID: <1048196606.1157.13.camel@localhost.localdomain> I've committed the beginning of the menu editor. Don't be too excited. That's just a copy from glade-2, adapting the indentation style, copying some functions from utils.c, and #if 0'ing a bunch of stuff. But it's a start :-) Cheers, From biswapesh_chatterjee@tcscal.co.in Fri Mar 21 04:35:26 2003 From: biswapesh_chatterjee@tcscal.co.in (Biswapesh Chattopadhyay) Date: 21 Mar 2003 10:05:26 +0530 Subject: [Glade-devel] commit -- beginning of the menu editor In-Reply-To: <1048196606.1157.13.camel@localhost.localdomain> References: <1048196606.1157.13.camel@localhost.localdomain> Message-ID: <1048221326.1089.10.camel@A5-1877> > I've committed the beginning of the menu editor. Don't be too excited. > That's just a copy from glade-2, adapting the indentation style, copying > some functions from utils.c, and #if 0'ing a bunch of stuff. I'm sorry - I can't help feeling exited ;-) Once menu editing and gnome/custom widget set support is in place, and we integrate it into Anjuta, we'll really have a kick-ass IDE for the MS converts :-) BTW, I know I promised to do the auto* stuff to get glade-3 installed as library + headers, but I haven't got qround to doing it yet - sorry. I'll try and get it done next week. -- Rgds, Biswa. From biswapesh_chatterjee@tcscal.co.in Fri Mar 21 07:52:51 2003 From: biswapesh_chatterjee@tcscal.co.in (Biswapesh Chattopadhyay) Date: 21 Mar 2003 13:22:51 +0530 Subject: [Glade-devel] Re: Toolbox widget for libegg In-Reply-To: <3E7ABDFB.3080500@hawaii.rr.com> References: <3E7ABDFB.3080500@hawaii.rr.com> Message-ID: <1048233171.18627.10.camel@A5-1877> This looks super cool ! We could really use something like this in Anjuta. I bet the Glade guys would probably salivate over this as well. Something for Glade-3, Joaquin ? > The HIG describes how toolboxes should be designed, but there isn't a > really > easy way for application developers to make toolboxes right now. > > To address this I've spent the last couple weekends working on a toolbox > widget. I'd like to see this widget go into libegg and eventually GTK+. > Currently, I think it's approximately right (enough to get it into CVS, > so that it's version controlled), but it's not complete yet. > > A screenshot is here: > http://www.grokthecruft.org/projects/toolbox/eggtoolbox.png > > The patch is here: > http://www.grokthecruft.org/projects/toolbox/eggtoolbox.patch > > and some images I stole from gimp to help me compare to HIG mockup > are here: > http://www.grokthecruft.org/projects/toolbox/gimp-images.tar.bz2 > (just untar in libegg/toolbox and run ./test-toolbox after building) > > Anyway, comments welcome... > --Ray > > > > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Rgds, Biswa. From pborelli@katamail.com Fri Mar 21 18:00:18 2003 From: pborelli@katamail.com (paolo borelli) Date: 21 Mar 2003 19:00:18 +0100 Subject: [Glade-devel] [patch, glade3] add menu tips displayed in the status bar Message-ID: <1048260506.9794.7.camel@localhost.localdomain> --=-ahOe7YOkEgf5f1+/K7Kf Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! The attached patch shows tips for menu items in the recently introduced statusbar. Since I didn't find any examples on how to do it, I had to figure out by myself, so maybe there is a better method! I appreciate any suggestion. While at it I also added undo/redo to the toolbar as suggested by Joaquin. ciao paolo --=-ahOe7YOkEgf5f1+/K7Kf Content-Disposition: attachment; filename=menu_tips.patch Content-Type: text/x-patch; name=menu_tips.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -pur gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-21 12:54:27.000000000 +0100 +++ glade3/ChangeLog 2003-03-21 16:17:23.000000000 +0100 @@ -1,3 +1,8 @@ +2003-03-21 Paolo Borelli + + * src/glade-project-window.c: show menu tips in the statusbar + * src/glade-project-window.c: add undo/redo to the toolbar + 2003-03-20 Joaquin Cuenca Abela * src/glade-keys-dialog.[ch]: Dialog box that appears when the user diff -pur gnome2/glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- gnome2/glade3/src/glade-project-window.c 2003-03-21 12:54:52.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-21 16:13:27.000000000 +0100 @@ -188,51 +188,95 @@ gpw_redo_cb (void) glade_command_redo (); } - static GtkItemFactoryEntry menu_items[] = { - /* ============ FILE ===================== */ - { "/_File", NULL, 0, 0, "" }, - { "/File/_New", "N", gpw_new_cb, 0, "", GTK_STOCK_NEW }, - { "/File/_Open", "O", gpw_open_cb, 0, "", GTK_STOCK_OPEN }, + /* ============ FILE ============ */ + { "/_File", NULL, 0, 0, "" }, + { "/File/_New", "N", gpw_new_cb, 1, "", GTK_STOCK_NEW }, + { "/File/_Open", "O", gpw_open_cb, 2, "", GTK_STOCK_OPEN }, { "/File/sep1", NULL, NULL, 0, "" }, - { "/File/_Save", "S", gpw_save_cb, 0, "", GTK_STOCK_SAVE }, - { "/File/Save _As...", "S", gpw_save_as_cb, 0, "", GTK_STOCK_SAVE_AS }, + { "/File/_Save", "S", gpw_save_cb, 3, "", GTK_STOCK_SAVE }, + { "/File/Save _As...", "S", gpw_save_as_cb, 4, "", GTK_STOCK_SAVE_AS }, { "/File/sep2", NULL, NULL, 0, "" }, - { "/File/_Quit", "Q", gpw_quit_cb, 0, "", GTK_STOCK_QUIT }, - + { "/File/_Quit", "Q", gpw_quit_cb, 5, "", GTK_STOCK_QUIT }, - /* ============ EDIT ===================== */ - { "/Edit", NULL, 0, 0, "" }, - { "/Edit/_Undo", "Z", gpw_undo_cb, 0, "", GTK_STOCK_UNDO }, - { "/Edit/_Redo", "R", gpw_redo_cb, 0, "", GTK_STOCK_REDO }, - { "/Edit/sep1", NULL, NULL, 0, "" }, - { "/Edit/C_ut", NULL, gpw_cut_cb, 0, "", GTK_STOCK_CUT }, - { "/Edit/_Copy", NULL, gpw_copy_cb, 0, "", GTK_STOCK_COPY }, - { "/Edit/_Paste", NULL, gpw_paste_cb, 0, "", GTK_STOCK_PASTE }, - { "/Edit/_Delete", "Delete", gpw_delete_cb, 0, "", GTK_STOCK_DELETE }, + /* ============ EDIT ============ */ + { "/Edit", NULL, 0, 0, "" }, + { "/Edit/_Undo", "Z", gpw_undo_cb, 6, "", GTK_STOCK_UNDO }, + { "/Edit/_Redo", "R", gpw_redo_cb, 7, "", GTK_STOCK_REDO }, + { "/Edit/sep1", NULL, NULL, 0, "" }, + { "/Edit/C_ut", NULL, gpw_cut_cb, 8, "", GTK_STOCK_CUT }, + { "/Edit/_Copy", NULL, gpw_copy_cb, 9, "", GTK_STOCK_COPY }, + { "/Edit/_Paste", NULL, gpw_paste_cb, 10, "", GTK_STOCK_PASTE }, + { "/Edit/_Delete", "Delete", gpw_delete_cb, 11, "", GTK_STOCK_DELETE }, - /* ============ VIEW ===================== */ + /* ============ VIEW ============ */ { "/View", NULL, 0, 0, "" }, - { "/View/_Palette", NULL, gpw_toggle_palette_cb, 0, "" }, - { "/View/Property _Editor", NULL, gpw_toggle_editor_cb, 0, "" }, - { "/View/_Widget Tree", NULL, gpw_toggle_widget_tree_cb, 0, "" }, - { "/View/_Clipboard", NULL, gpw_toggle_clipboard_cb, 0, "" }, + { "/View/_Palette", NULL, gpw_toggle_palette_cb, 12, "" }, + { "/View/Property _Editor", NULL, gpw_toggle_editor_cb, 13, "" }, + { "/View/_Widget Tree", NULL, gpw_toggle_widget_tree_cb, 14, "" }, + { "/View/_Clipboard", NULL, gpw_toggle_clipboard_cb, 15, "" }, - /* ============ PROJECT=================== */ + /* =========== PROJECT ========== */ { "/Project", NULL, 0, 0, "" }, - /* ============ HELP ===================== */ + /* ============ HELP ============ */ { "/_Help", NULL, NULL, 0, "" }, - { "/Help/_About", NULL, gpw_about_cb, 0 }, + { "/Help/_About", NULL, gpw_about_cb, 16 }, }; +/* + * Note! The action number in menu_items MUST match the position in this array + */ +static gchar *menu_tips[] = +{ + NULL, /* action 0 (branches and separators) */ + N_("Create a new project file"), /* action 1 (New) */ + N_("Open a project file"), /* action 2 (Open) */ + N_("Save the current project file"), /* action 3 (Save) */ + N_("Save the current project file with a different name"), /* action 4 (Save as) */ + N_("Quit the program"), /* action 5 (Quit) */ + + N_("Undo the last action"), /* action 6 (Undo) */ + N_("Redo the last action"), /* action 7 (Redo) */ + N_("Cut the selection"), /* action 8 (Cut) */ + N_("Copy the selection"), /* action 9 (Copy) */ + N_("Paste the clipboard"), /* action 10 (Paste) */ + N_("Delete the selection"), /* action 11 (Delete) */ + + N_("Change the visibility of the palette of widgets"), /* action 12 (Palette) */ + N_("Change the visibility of the property editor"), /* action 13 (Editor) */ + N_("Change the visibility of the project widget tree"), /* action 14 (Tree) */ + N_("Change the visibility of the clipboard"), /* action 15 (Clipboard) */ + + N_("About this application"), /* action 16 (About) */ +}; + + +static void +gpw_push_statusbar_hint (GtkWidget* menuitem, const gchar *tip) +{ + GladeProjectWindow *gpw; + + gpw = glade_project_window_get (); + gtk_statusbar_push ( GTK_STATUSBAR (gpw->statusbar), 1, tip); +} + +static void +gpw_pop_statusbar_hint (GtkWidget* menuitem, gpointer not_used) +{ + GladeProjectWindow *gpw; + + gpw = glade_project_window_get (); + gtk_statusbar_pop (GTK_STATUSBAR (gpw->statusbar), 1); +} static void gpw_construct_menu (GladeProjectWindow *gpw) { GtkItemFactory *item_factory; GtkAccelGroup *accel_group; + gint i; /* Accelerators */ accel_group = gtk_accel_group_new (); @@ -253,6 +297,19 @@ gpw_construct_menu (GladeProjectWindow * menu_items, gpw->window); gtk_box_pack_start_defaults (GTK_BOX (gpw->main_vbox), gtk_item_factory_get_widget (item_factory, "
")); + + /* set the tooltips */ + for (i = 1; i < G_N_ELEMENTS (menu_tips); i++) { + GtkWidget *item; + + item = gtk_item_factory_get_widget_by_action (item_factory, i); + g_signal_connect (G_OBJECT (item), "select", + G_CALLBACK (gpw_push_statusbar_hint), + menu_tips[i]); + g_signal_connect (G_OBJECT (item), "deselect", + G_CALLBACK (gpw_pop_statusbar_hint), + NULL); + } } static void @@ -276,6 +333,19 @@ gpw_construct_toolbar (GladeProjectWindo gpw, -1); gtk_toolbar_append_space (GTK_TOOLBAR (toolbar)); gtk_toolbar_insert_stock (GTK_TOOLBAR (toolbar), + GTK_STOCK_UNDO, + "Undo the last action", + NULL, + G_CALLBACK (gpw_undo_cb), + gpw, -1); + gtk_toolbar_insert_stock (GTK_TOOLBAR (toolbar), + GTK_STOCK_REDO, + "Redo the last action", + NULL, + G_CALLBACK (gpw_redo_cb), + gpw, -1); + gtk_toolbar_append_space (GTK_TOOLBAR (toolbar)); + gtk_toolbar_insert_stock (GTK_TOOLBAR (toolbar), GTK_STOCK_QUIT, "Quit glade", NULL, --=-ahOe7YOkEgf5f1+/K7Kf-- From eric@debian.org Sun Mar 23 04:15:13 2003 From: eric@debian.org (Eric Dorland) Date: Sat, 22 Mar 2003 23:15:13 -0500 Subject: [Glade-devel] glade 1.1.3 fails to build with the latest libgnomedb2 (0.11.0) Message-ID: <20030323041513.GQ2187@apocalypse> --fu8LepSeDvpxVgv6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Trying to build glade 1.1.3 with the latest gnome-db support fails with the error: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DORBIT2=3D1 -pthread -I/usr/include/libxml2 -I/usr/include/libxml2/libxml -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/linc-1.0 -I/usr/include/bonobo-activation-2.0 -I/usr/X11R6/include -g -O2 -c gnomedbsqleditor.c gnomedbsqleditor.c:22:44: libgnomedb/gnome-db-sql-editor.h: No such file or directory make[5]: *** [gnomedbsqleditor.o] Error 1 make[5]: Leaving directory `/home/eric/debian/glade-2-1.1.3/glade/gnome-db' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/eric/debian/glade-2-1.1.3/glade' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/eric/debian/glade-2-1.1.3' make[2]: *** [all-recursive-am] Error 2 make[2]: Leaving directory `/home/eric/debian/glade-2-1.1.3' make[1]: *** [build-gnome-stamp] Error 2 make[1]: Leaving directory `/home/eric/debian/glade-2-1.1.3' make: *** [install] Error 2 --=20 Eric Dorland ICQ: #61138586, Jabber: hooty@jabber.com 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+=20 O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+=20 G e h! r- y+=20 ------END GEEK CODE BLOCK------ --fu8LepSeDvpxVgv6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+fTTRYemOzxbZcMYRAvJPAKC5MiLInN+dbRZIIOwiU3/wsDBAEwCeMEqc EWF7udN44entjWyQMkKcus4= =mc4U -----END PGP SIGNATURE----- --fu8LepSeDvpxVgv6-- From e98cuenc@free.fr Sun Mar 23 21:54:42 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: Sun, 23 Mar 2003 22:54:42 +0100 Subject: [Glade-devel] Re: Toolbox widget for libegg In-Reply-To: <1048233171.18627.10.camel@A5-1877> Message-ID: <000301c2f186$e0d1c230$7fe03851@lou> Biswapesh wrote: > > This looks super cool ! We could really use something like > this in Anjuta. I bet the Glade guys would probably salivate > over this as well. Something for Glade-3, Joaquin ? I don't want to change very much the current interface until we get the same functionality as glade-2, but yes, I would like to change the palette in the future. The toolbox of the screenshot is already better than the current one, because you can show several categories at the same time, but in my experience, you lost too much time scanning the toolbox each time that you look for a weird widget. Maybe it's just that the current icons are not clear enough in some cases, or maybe we need a better classification of widgets (by category instead of by "library") or maybe it's a matter of adding the textual description of the widget next to the icon like MS does. I don't really know. When I will be done with the menu editor, I will tweak this toolbox to try these alternatives and see how they look. Another part of the GUI that I will like to change a little bit (specially now that we will be integrated with anjuta, is the signal editor). With the current interface it's quite easy to "lost" data (or it's only me who forget to click the "Add" button when adding a new signal?), and some signal could be added in a more direct way (like clicking on a button to add a new click signal handler). Cheers, From e98cuenc@free.fr Tue Mar 25 18:27:42 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 25 Mar 2003 19:27:42 +0100 Subject: [Glade-devel] commit -- Paolo patches + more menu editor work Message-ID: <1048616863.1111.29.camel@localhost.localdomain> cf. subject. I did some little changes to Paolo patch before committing it. Now you can even see the menu editor in action (create a GtkMenuBar, and click on "Edit Menus...", just like in glade-2), but I guess that it will crash as soon as you start playing with it :-) Cheers, From pborelli@katamail.com Thu Mar 27 19:53:00 2003 From: pborelli@katamail.com (paolo borelli) Date: 27 Mar 2003 20:53:00 +0100 Subject: [Glade-devel] [patch, glade3] same project file passed more than once on cmd line Message-ID: <1048794032.4962.16.camel@localhost.localdomain> --=-Px7oJUB+pJ8EDotOTgOS Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! The patch attached fixes the (unlikely) case where the same file is passed more than once on the command line, e.g. glade-3 foo.glade2 foo.glade2 >From the file selector we don't allow to have the same project opened more than once. While fixing this I took the chance to make glade_project_open_from_file private to glade_project.c. Some micro cleanups along the way. If you don't like the patch, you probably want to fix a little leak that is present in glade_project_open(): "path" is not freed on error. ciao paolo --=-Px7oJUB+pJ8EDotOTgOS Content-Disposition: attachment; filename=same_project_cmd_line.patch Content-Type: text/x-patch; name=same_project_cmd_line.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -rup gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-26 10:28:20.000000000 +0100 +++ glade3/ChangeLog 2003-03-27 20:38:13.000000000 +0100 @@ -1,3 +1,9 @@ +2003-03-27 Paolo Borelli + + * src/glade-project.[ch]: make glade_project_open_from_file() static + and fix the callers. This fixes the (unlikely) case of passing the + same file more than once on the command line. + 2003-03-25 Joaquin Cuenca Abela * src/glade-gtk.c: create a "Edit Menus..." button that... surprise! diff -rup gnome2/glade3/src/glade-project.c glade3/src/glade-project.c --- gnome2/glade3/src/glade-project.c 2003-03-15 15:36:43.000000000 +0100 +++ glade3/src/glade-project.c 2003-03-27 20:18:23.000000000 +0100 @@ -150,7 +150,7 @@ glade_project_destroy (GtkObject *object } static GladeProject * -glade_project_check_previously_loaded (gchar *path) +glade_project_check_previously_loaded (const gchar *path) { GladeProjectWindow *gpw; GladeProject *project; @@ -163,7 +163,7 @@ glade_project_check_previously_loaded (g project = GLADE_PROJECT (list->data); if (project->path != NULL && !strcmp (project->path, path)) - return project; + return project; } return NULL; @@ -497,7 +497,7 @@ glade_project_write_widgets (const Glade * glade_project_write: * @project: * - * Retrns the root node of a newly created xml representation of the project and its contents + * Returns the root node of a newly created xml representation of the project and its contents * * Return Value: **/ @@ -527,7 +527,7 @@ glade_project_write (GladeXmlContext *co **/ static gboolean glade_project_save_to_file (GladeProject *project, - const gchar * full_path) + const gchar *full_path) { GladeXmlContext *context; GladeXmlNode *root; @@ -555,7 +555,6 @@ glade_project_save_to_file (GladeProject return TRUE; } - static GladeProject * glade_project_new_from_node (GladeXmlNode *node) { @@ -584,7 +583,7 @@ glade_project_new_from_node (GladeXmlNod return project; } -GladeProject * +static GladeProject * glade_project_open_from_file (const gchar *path) { GladeXmlContext *context; @@ -699,41 +698,48 @@ glade_project_save_as (GladeProject *pro /** * glade_project_open: - * @: + * @path: * - * Open a project. Launches a file selector + * Open a project. If @path is NULL launches a file selector * * Return Value: TRUE on success false on error. **/ gboolean -glade_project_open (void) +glade_project_open (const gchar *path) { GladeProjectWindow *gpw; GladeProject *project; - gchar *path; - + gchar *file_path = NULL; + gpw = glade_project_window_get (); - path = glade_project_ui_get_path (_("Open ...")); if (!path) + file_path = glade_project_ui_get_path (_("Open ...")); + else + file_path = g_strdup (path); + + /* If the user hit cancel, return */ + if (!file_path) return FALSE; /* If the project is previously loaded, don't re-load */ if ((project = glade_project_check_previously_loaded (path)) != NULL) { glade_project_window_set_project (gpw, project); + g_free (file_path); return TRUE; } - project = glade_project_open_from_file (path); + project = glade_project_open_from_file (file_path); if (!project) { glade_util_ui_warn (_("Could not open project.")); - g_free (path); + g_free (file_path); return FALSE; } glade_project_window_add_project (gpw, project); - g_free (path); + g_free (file_path); return TRUE; } + diff -rup gnome2/glade3/src/glade-project.h glade3/src/glade-project.h --- gnome2/glade3/src/glade-project.h 2002-04-23 19:13:30.000000000 +0200 +++ glade3/src/glade-project.h 2003-03-27 20:11:14.000000000 +0100 @@ -66,7 +66,6 @@ GladeProject * glade_project_new (gboole gboolean glade_project_save (GladeProject *project); gboolean glade_project_save_as (GladeProject *project); gboolean glade_project_open (); -GladeProject * glade_project_open_from_file (const gchar *path); /* Widget related stuff */ diff -rup gnome2/glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- gnome2/glade3/src/glade-project-window.c 2003-03-26 10:28:21.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-27 20:15:36.000000000 +0100 @@ -61,7 +61,7 @@ static void gpw_about_cb (void) {} static void gpw_open_cb (void) { - glade_project_open (); + glade_project_open (NULL); } static void diff -rup gnome2/glade3/src/main.c glade3/src/main.c --- gnome2/glade3/src/main.c 2003-03-08 17:23:41.000000000 +0100 +++ glade3/src/main.c 2003-03-27 20:13:42.000000000 +0100 @@ -98,7 +98,6 @@ int main (int argc, char *argv[]) { GladeProjectWindow *gpw; - GladeProject *project; poptContext popt_context; GList *files; @@ -114,7 +113,7 @@ main (int argc, char *argv[]) poptFreeContext (popt_context); gtk_init (&argc, &argv); - + if (!glade_init ()) return -1; @@ -131,10 +130,10 @@ main (int argc, char *argv[]) if (files) { for (; files != NULL; files = files->next) { - project = glade_project_open_from_file (files->data); - glade_project_window_add_project (gpw, project); + glade_project_open (files->data); } } else { + GladeProject *project; project = glade_project_new (TRUE); glade_project_window_add_project (gpw, project); } @@ -144,7 +143,6 @@ main (int argc, char *argv[]) return 0; } - static GList * parse_command_line (poptContext pctx) { --=-Px7oJUB+pJ8EDotOTgOS-- From e98cuenc@free.fr Thu Mar 27 22:20:43 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 27 Mar 2003 23:20:43 +0100 Subject: [Glade-devel] commit -- latest Paolo patch Message-ID: <1048803644.1113.0.camel@localhost.localdomain> cf. subject. Committed without changes. Cheers, From pborelli@katamail.com Fri Mar 28 17:35:06 2003 From: pborelli@katamail.com (paolo borelli) Date: 28 Mar 2003 18:35:06 +0100 Subject: [Glade-devel] [patch, glade3] glade_util_flash_message() Message-ID: <1048872698.25066.26.camel@localhost.localdomain> --=-pGVpAOY2pkAAEhDFPdzb Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! The patch attached implements a utility function to display messages in the statusbar and uses it to display the "Project Saved" message. Note: I'm not sure that this patch is ready for inclusion, so don't apply it unless you reviewed it carefully and you are confident it's ok. I'm sending it out for review and maybe to get some advices, because I have at least a couple of doubts: First thing, I'm not sure if I got the gtk_timeout behaviur right. Second, I'm quite puzzled by this whole context_id thing used for the statusbar. I thought that assigning a different context id for each project you would get the following beahviour: suppose you save a project, a "Project Saved" message is displayed; then you change project (before the message is removed by the timeout); I thought that at this point the message would be hidden because in the statusbar is disaplyed the message stack relative to the current project. This does not happen, so now I wonder why I have to set up different context_ids when the resulting behavoiur is the same as when you simply pass "1" every time you need a context_id. ciao paolo PS: I'd like to thank to Joaquin for having applied (and corrected!) my previous patches --=-pGVpAOY2pkAAEhDFPdzb Content-Disposition: attachment; filename=flash-message.patch Content-Type: text/x-patch; name=flash-message.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -upr gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-28 13:27:15.000000000 +0100 +++ glade3/ChangeLog 2003-03-28 17:20:42.000000000 +0100 @@ -1,3 +1,9 @@ +2003-03-28 Paolo Borelli + + * src/glade-utils.[ch]: implement glade_util_flash_message() + * src/glade-project.[ch]: use the above to display "Project Saved" + in the statusbar. + 2003-03-27 Paolo Borelli * src/glade-project.[ch]: make glade_project_open_from_file() static diff -upr gnome2/glade3/src/glade-project.c glade3/src/glade-project.c --- gnome2/glade3/src/glade-project.c 2003-03-28 13:27:16.000000000 +0100 +++ glade3/src/glade-project.c 2003-03-28 15:10:10.000000000 +0100 @@ -34,6 +34,7 @@ #include "glade-widget-class.h" #include "glade-xml-utils.h" #include "glade-widget.h" +#include "glade-utils.h" static void glade_project_class_init (GladeProjectClass * klass); static void glade_project_init (GladeProject *project); @@ -149,6 +150,19 @@ glade_project_destroy (GtkObject *object } +static void +glade_project_set_context_id (GladeProject *project) +{ + GladeProjectWindow *gpw; + static guint i = 1; + + gpw = glade_project_window_get (); + + /* We do not want our context id to collide with the menu context id */ + project->context_id = (gpw->statusbar_menu_context_id) + i; + i++; +} + static GladeProject * glade_project_check_previously_loaded (const gchar *path) { @@ -204,6 +218,7 @@ glade_project_new (gboolean untitled) if (untitled) project->name = g_strdup_printf ("Untitled %i", i++); + glade_project_set_context_id (project); glade_project_update_menu_path (project); return project; @@ -601,6 +616,7 @@ glade_project_open_from_file (const gcha project->path = g_strdup_printf ("%s", path); g_free (project->name); project->name = g_path_get_basename (project->path); + glade_project_set_context_id (project); /* Setup the menu item to be shown in the /Project menu. */ glade_project_update_menu_path (project); } @@ -649,6 +665,7 @@ glade_project_save (GladeProject *projec } glade_project_refresh_menu_item (project); + glade_util_flash_message (project->context_id, _("Project Saved")); return TRUE; } diff -upr gnome2/glade3/src/glade-project.h glade3/src/glade-project.h --- gnome2/glade3/src/glade-project.h 2003-03-28 13:27:16.000000000 +0100 +++ glade3/src/glade-project.h 2003-03-28 14:56:49.000000000 +0100 @@ -18,6 +18,8 @@ struct _GladeProject gchar *name; /* The name of the project like network-conf */ gchar *path; /* The full path of the xml file for this project*/ + + guint context_id; /* the context_id for statusbar messages */ GtkItemFactoryEntry entry; /* The menu entry in the /Project menu */ diff -upr gnome2/glade3/src/glade-utils.c glade3/src/glade-utils.c --- gnome2/glade3/src/glade-utils.c 2003-03-20 21:48:02.000000000 +0100 +++ glade3/src/glade-utils.c 2003-03-28 17:18:08.000000000 +0100 @@ -95,6 +95,49 @@ glade_util_ui_warn (const gchar *warning gtk_widget_destroy (dialog); } +typedef struct { + GtkStatusbar *statusbar; + guint context_id; + guint message_id; +} FlashInfo; + +static const guint32 flash_length = 3000; + +static gboolean +remove_message_timeout (FlashInfo * fi) +{ + gtk_statusbar_remove (fi->statusbar, fi->context_id, fi->message_id); + g_free (fi); + + return FALSE; /* removes the timeout */ +} + +/** + * glade_utils_flash: + * @msg: Message to flash on the statusbar + * + * Flash a temporary message on the statusbar. + **/ +void +glade_util_flash_message (guint context_id, const gchar *message) +{ + GladeProjectWindow *gpw; + FlashInfo *fi; + + g_return_if_fail (message != NULL); + + gpw = glade_project_window_get (); + + fi = g_new (FlashInfo, 1); + fi->statusbar = GTK_STATUSBAR (gpw->statusbar); + fi->context_id = context_id; + fi->message_id = gtk_statusbar_push (fi->statusbar, context_id, message); + + gtk_timeout_add (flash_length, + (GtkFunction) remove_message_timeout, + fi); +} + static gint glade_util_compare_uline_labels (const gchar *labela, const gchar *labelb) { diff -upr gnome2/glade3/src/glade-utils.h glade3/src/glade-utils.h --- gnome2/glade3/src/glade-utils.h 2003-03-20 21:48:02.000000000 +0100 +++ glade3/src/glade-utils.h 2003-03-28 13:09:46.000000000 +0100 @@ -20,6 +20,7 @@ typedef enum void glade_util_widget_set_tooltip (GtkWidget *widget, const gchar *str); GType glade_util_get_type_from_name (const gchar *name); void glade_util_ui_warn (const gchar *warning); +void glade_util_flash_message (guint context_id, const gchar *message); /* This is a GCompareFunc for comparing the labels of 2 stock items, ignoring any '_' characters. It isn't particularly efficient. */ --=-pGVpAOY2pkAAEhDFPdzb-- From e98cuenc@free.fr Sat Mar 29 13:07:48 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: Sat, 29 Mar 2003 14:07:48 +0100 Subject: [Glade-devel] [patch, glade3] glade_util_flash_message() In-Reply-To: <1048872698.25066.26.camel@localhost.localdomain> Message-ID: <000001c2f5f4$367492f0$7fe03851@lou> Paolo wrote: > > Hi! > > The patch attached implements a utility function to display > messages in the statusbar and uses it to display the "Project > Saved" message. > > Note: I'm not sure that this patch is ready for inclusion, so > don't apply it unless you reviewed it carefully and you are > confident it's ok. > > I'm sending it out for review and maybe to get some advices, > because I have at least a couple of doubts: > > First thing, I'm not sure if I got the gtk_timeout behaviur right. > > Second, I'm quite puzzled by this whole context_id thing used > for the statusbar. I thought that assigning a different > context id for each project you would get the following > beahviour: suppose you save a project, a "Project Saved" > message is displayed; then you change project (before the > message is removed by the timeout); I thought that at this > point the message would be hidden because in the statusbar is > disaplyed the message stack relative to the current project. > This does not happen, so now I wonder why I have to set up > different context_ids when the resulting behavoiur is the > same as when you simply pass "1" every time you need a context_id. Ok, I'm sorry I didn't explained why I removed the "1" as context_id, and used a real context_id as returned by gtk_statusbar_get_context_id. Nowhere in the public documentation says that you can use a context_id before you've allocated it with get_context_id, so just using "1" as context_id was undefined behaviour. I also skimmed a bit the source of GtkStatusBar and I didn't say anything that imply that you can just use "1", so I put a real context_id. Now, what's the purpose of context id? We have several "users" of the status bar. The menu wants to add messages to the status bar, events add messages (as "project saved"), etc. Think about the following use-case: * The user is over a menu item: We pop the latest message in the status bar that came from the menu, and we push a new message (say "Menu Item 1") * A event happens (say auto-save): pop latest message from events, and push a new message (say "Project auto-saved"). Arm a timer to pop the message after 2 seconds. * The user moves to another menu item: pop latest message from the menu, and push a new message (say "Menu item 2"). * The timer fires, and it pops the latest message from events. If you don't have a way to say where the message comes from (events or menu, in this example), you end having: Menu Item 1 -> Project auto-saved -> Menu Item 2 -> Nothing The timer would remove "Menu Item 2" when it should just remove "Project auto-saved". You should also take in account that the context id doesn't have any effect on the message displayed. To show the messages the whole thing just looks like a stack. The context id it's just there to help you push or pop the right kind of message. I will take later a deeper look at your patch. Thank you for your help! Cheers, From pborelli@katamail.com Sat Mar 29 13:30:22 2003 From: pborelli@katamail.com (pborelli@katamail.com) Date: Sat, 29 Mar 2003 13:30:22 +0000 Subject: [Glade-devel] [patch, glade3] glade_util_flash_message() Message-ID: <127.0.0.1+y1aDjWccCYHaQSq2qJHHhE@hal-3.inet.it> > >Ok, I'm sorry I didn't explained why I removed the "1" as context_id, >and used a real context_id as returned by gtk_statusbar_get_context_id. > Just to make things clear, I'm 100% fine with the change you made for menu tips :) What I was wondering is if we should simply have one context_id for events messages (different from the menu context_id) or instead have a different context_id for each project... also beacuse in the patch I sent I keep track of each message_id to remove it. ciao From e98cuenc@free.fr Sat Mar 29 13:34:04 2003 From: e98cuenc@free.fr (Joaquin Cuenca Abela) Date: 29 Mar 2003 14:34:04 +0100 Subject: [Glade-devel] [patch, glade3] glade_util_flash_message() In-Reply-To: <127.0.0.1+y1aDjWccCYHaQSq2qJHHhE@hal-3.inet.it> References: <127.0.0.1+y1aDjWccCYHaQSq2qJHHhE@hal-3.inet.it> Message-ID: <1048944845.1242.1.camel@localhost.localdomain> On Sat, 2003-03-29 at 14:30, pborelli@katamail.com wrote: > > > >Ok, I'm sorry I didn't explained why I removed the "1" as context_id, > >and used a real context_id as returned by gtk_statusbar_get_context_id. > > > > Just to make things clear, I'm 100% fine with the change you made for menu tips :) > > What I was wondering is if we should simply have one context_id for events messages (different from the menu context_id) or instead have a different context_id for each project... also beacuse in the patch I sent I keep track of each message_id to remove it. IMO, just one context_id for event messages, independent of the current project. Cheers, From bighead@users.sourceforge.net Sun Mar 30 00:53:13 2003 From: bighead@users.sourceforge.net (Archit Baweja) Date: Sat, 29 Mar 2003 19:53:13 -0500 Subject: [Glade-devel] Has glade3 development started? Message-ID: <200303300053.h2U0rDQ0001761@n2-193-168.resnet.drexel.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Back after a little over 4-5 month absence, I was wondering about the current state of Glade3 development? I heard some noise on the mailing lists. updating my glade3 branch from CVS. Cheers! Archit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard iD8DBQE+hj/52rWNPKmGjMcRAi2XAJ0dl3J3i0VjwWrsIZlfp3kUmFMw+ACghwqK Tv32X1F0wPD9u+VfpAUtlUI= =eRfh -----END PGP SIGNATURE----- From pborelli@katamail.com Sun Mar 30 12:52:43 2003 From: pborelli@katamail.com (paolo borelli) Date: 30 Mar 2003 14:52:43 +0200 Subject: [Glade-devel] [patch, glade3] glade_util_flash_message() In-Reply-To: <1048944845.1242.1.camel@localhost.localdomain> References: <127.0.0.1+y1aDjWccCYHaQSq2qJHHhE@hal-3.inet.it> <1048944845.1242.1.camel@localhost.localdomain> Message-ID: <1049028727.14334.2.camel@localhost.localdomain> --=-qKlp1HPLy2D3h/hZosx2 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2003-03-29 at 14:34, Joaquin Cuenca Abela wrote: > IMO, just one context_id for event messages, independent of the current > project. Here it is an updated patch. I also made the flash util take a formatted argument. ciao paolo --=-qKlp1HPLy2D3h/hZosx2 Content-Disposition: attachment; filename=flash-message-2.patch Content-Type: text/x-patch; name=flash-message-2.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -upr gnome2/glade3/ChangeLog glade3/ChangeLog --- gnome2/glade3/ChangeLog 2003-03-30 10:47:06.000000000 +0200 +++ glade3/ChangeLog 2003-03-30 14:45:44.000000000 +0200 @@ -1,3 +1,9 @@ +2003-03-30 Paolo Borelli + + * src/glade-utils.[ch]: implement glade_util_flash_message() + * src/glade-project.[ch]: use the above to display "Project Saved" + in the statusbar. + 2003-03-29 Joaquin Cuenca Abela * src/glade-editor.c: Now we don't create a new "Edit Menus..." button diff -upr gnome2/glade3/src/glade-project.c glade3/src/glade-project.c --- gnome2/glade3/src/glade-project.c 2003-03-28 13:27:16.000000000 +0100 +++ glade3/src/glade-project.c 2003-03-30 14:45:44.000000000 +0200 @@ -34,6 +34,7 @@ #include "glade-widget-class.h" #include "glade-xml-utils.h" #include "glade-widget.h" +#include "glade-utils.h" static void glade_project_class_init (GladeProjectClass * klass); static void glade_project_init (GladeProject *project); @@ -621,10 +622,13 @@ glade_project_open_from_file (const gcha gboolean glade_project_save (GladeProject *project) { + GladeProjectWindow *gpw; gchar *backup; g_return_val_if_fail (GLADE_IS_PROJECT (project), FALSE); + gpw = glade_project_window_get (); + backup = project->path; if (project->path == NULL) { @@ -649,6 +653,8 @@ glade_project_save (GladeProject *projec } glade_project_refresh_menu_item (project); + glade_util_flash_message (gpw->statusbar_actions_context_id, + _("Project '%s' saved"), project->name); return TRUE; } @@ -665,10 +671,13 @@ glade_project_save (GladeProject *projec gboolean glade_project_save_as (GladeProject *project) { + GladeProjectWindow *gpw; gchar *backup; g_return_val_if_fail (GLADE_IS_PROJECT (project), FALSE); + gpw = glade_project_window_get (); + /* Keep the previous path */ backup = project->path; project->path = glade_project_ui_get_path (_("Save as ...")); @@ -688,10 +697,13 @@ glade_project_save_as (GladeProject *pro } /* Free the backup and return; */ + g_free (backup); g_free (project->name); project->name = g_path_get_basename (project->path); + glade_project_refresh_menu_item (project); - g_free (backup); + glade_util_flash_message (gpw->statusbar_actions_context_id, + _("Project saved as '%s'"), project->name); return TRUE; } diff -upr gnome2/glade3/src/glade-project-window.c glade3/src/glade-project-window.c --- gnome2/glade3/src/glade-project-window.c 2003-03-28 13:27:15.000000000 +0100 +++ glade3/src/glade-project-window.c 2003-03-30 14:45:44.000000000 +0200 @@ -366,6 +366,7 @@ gpw_construct_statusbar (GladeProjectWin statusbar = gtk_statusbar_new (); gpw->statusbar = statusbar; gpw->statusbar_menu_context_id = gtk_statusbar_get_context_id (GTK_STATUSBAR (statusbar), "menu"); + gpw->statusbar_actions_context_id = gtk_statusbar_get_context_id (GTK_STATUSBAR (statusbar), "actions"); gtk_box_pack_end_defaults (GTK_BOX (gpw->main_vbox), statusbar); } diff -upr gnome2/glade3/src/glade-project-window.h glade3/src/glade-project-window.h --- gnome2/glade3/src/glade-project-window.h 2003-03-26 10:28:21.000000000 +0100 +++ glade3/src/glade-project-window.h 2003-03-30 14:45:44.000000000 +0200 @@ -15,8 +15,10 @@ struct _GladeProjectWindow { GtkWidget *window; /* Main window */ GtkWidget *main_vbox; + GtkWidget *statusbar; /* A pointer to the status bar. */ guint statusbar_menu_context_id; /* The context id of the menu bar */ + guint statusbar_actions_context_id; /* The context id of actions messages */ GtkItemFactory *item_factory; /* A pointer to the Item factory. * We need it to be able to later add diff -upr gnome2/glade3/src/glade-utils.c glade3/src/glade-utils.c --- gnome2/glade3/src/glade-utils.c 2003-03-20 21:48:02.000000000 +0100 +++ glade3/src/glade-utils.c 2003-03-30 14:46:38.000000000 +0200 @@ -95,6 +95,57 @@ glade_util_ui_warn (const gchar *warning gtk_widget_destroy (dialog); } +typedef struct { + GtkStatusbar *statusbar; + guint context_id; + guint message_id; +} FlashInfo; + +static const guint32 flash_length = 3000; + +static gboolean +remove_message_timeout (FlashInfo * fi) +{ + gtk_statusbar_remove (fi->statusbar, fi->context_id, fi->message_id); + g_free (fi); + + /* remove the timeout */ + return FALSE; +} + +/** + * glade_utils_flash_message: + * @context_id: The message context_id + * @format: The message to flash on the statusbar + * + * Flash a temporary message on the statusbar. + **/ +void +glade_util_flash_message (guint context_id, gchar *format, ...) +{ + va_list args; + GladeProjectWindow *gpw; + FlashInfo *fi; + gchar *message; + + g_return_if_fail (format != NULL); + + gpw = glade_project_window_get (); + + va_start (args, format); + message = g_strdup_vprintf (format, args); + va_end (args); + + fi = g_new (FlashInfo, 1); + fi->statusbar = GTK_STATUSBAR (gpw->statusbar); + fi->context_id = context_id; + fi->message_id = gtk_statusbar_push (fi->statusbar, fi->context_id, message); + + gtk_timeout_add (flash_length, (GtkFunction) remove_message_timeout, fi); + + g_free (message); +} + static gint glade_util_compare_uline_labels (const gchar *labela, const gchar *labelb) { Only in glade3/src: glade-utils.c~ diff -upr gnome2/glade3/src/glade-utils.h glade3/src/glade-utils.h --- gnome2/glade3/src/glade-utils.h 2003-03-20 21:48:02.000000000 +0100 +++ glade3/src/glade-utils.h 2003-03-30 14:45:44.000000000 +0200 @@ -20,6 +20,7 @@ typedef enum void glade_util_widget_set_tooltip (GtkWidget *widget, const gchar *str); GType glade_util_get_type_from_name (const gchar *name); void glade_util_ui_warn (const gchar *warning); +void glade_util_flash_message (guint context_id, gchar *format, ...); /* This is a GCompareFunc for comparing the labels of 2 stock items, ignoring any '_' characters. It isn't particularly efficient. */ --=-qKlp1HPLy2D3h/hZosx2--