From bobchuhello@hotmail.com Sat Jan 1 15:33:11 2005 From: bobchuhello@hotmail.com (Bob Zhu) Date: Sat, 1 Jan 2005 23:33:11 +0800 Subject: [Glade-devel] glade2.6.7 can't generate C++ code on Windows2000? Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4F05A.42DBA3F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi friends: I can=A1=AFt create C++ code with glade2.6.7. It=A1=AFs the first time I = try glade. Who knows the problem? Thanks! Haibo=20 ------=_NextPart_000_0000_01C4F05A.42DBA3F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi friends:

I can=A1=AFt create C++ code with = glade2.6.7. It=A1=AFs the first time I try glade. Who knows the problem? = Thanks!

Haibo

------=_NextPart_000_0000_01C4F05A.42DBA3F0-- From damon@karuna.uklinux.net Sat Jan 1 15:55:30 2005 From: damon@karuna.uklinux.net (Damon Chaplin) Date: Sat, 01 Jan 2005 15:55:30 +0000 Subject: [Glade-devel] glade2.6.7 can't generate C++ code on Windows2000? In-Reply-To: References: Message-ID: <1104594930.2964.1.camel@Eternity> On Sat, 2005-01-01 at 15:33, Bob Zhu wrote: > Hi friends: > > I can�t create C++ code with glade2.6.7. It�s the first time I try > glade. Who knows the problem? Thanks! The C++ code generator is a separate package. See http://home.wtal.de/petig/ I'm not sure if it has been ported to Windows. There is also a mailing list for the C++ code generator here: http://lists.gnome.org/mailman/listinfo/glademm-list Damon From email@ivanwong.info Sat Jan 1 16:16:51 2005 From: email@ivanwong.info (Ivan Wong) Date: Sun, 02 Jan 2005 00:16:51 +0800 Subject: [Glade-devel] glade2.6.7 can't generate C++ code on Windows2000? In-Reply-To: <1104594930.2964.1.camel@Eternity> References: <1104594930.2964.1.camel@Eternity> Message-ID: <41D6CCF3.7090108@ivanwong.info> > The C++ code generator is a separate package. > See http://home.wtal.de/petig/ > > I'm not sure if it has been ported to Windows. http://www.pcpm.ucl.ac.be/~gustin/win32_ports/ This gtkmm Developer Environment package (including libglademm) is approved by the gtkmm team. (see the bottom of http://www.gtkmm.org/download.shtml) Cheers, Ivan. From micke@imendio.com Mon Jan 3 19:56:18 2005 From: micke@imendio.com (Mikael Hallendal) Date: Mon, 03 Jan 2005 20:56:18 +0100 Subject: [Glade-devel] Better support for adding external catalogs in Glade3 Message-ID: <41D9A362.6010600@imendio.com> Hi, I'm working on improving the support for external libraries in Glade3. Currently you have a file called glade-palette.xml which contains the catalogs to load. This isn't very feasible when you want to add your own catalog file. The palette file also has another function, it describes the order in which the catalogs should be displayed in the UI. For telling which catalogs exist I think it would be better try to load all xml-files available in $prefix/share/glade-$VERSION/catalogs. This way you will only have to install catalog file in that directory in order to have it available for Glade3. When it comes to the order it might just be OK to hard code it as: Gtk+ Base Gtk+ Additional Gtk+ Standard Dialogs Gtk+ Obsolete or something. This would make the glade-palette file obsolete. Another thing that cought my eye is that we should probably not name the data directory glade-$VERSION as third party libraries won't be visible after an update from glade-3.0.1 to glade-3.0.2. Probably better to just call the directory 'glade-3'. Any thoughts on this, as soon as we can reach a concensus on this I'll implement it. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ From micke@imendio.com Mon Jan 3 23:33:31 2005 From: micke@imendio.com (Mikael Hallendal) Date: Tue, 04 Jan 2005 00:33:31 +0100 Subject: [Fwd: Re: [Glade-devel] Better support for adding external catalogs in Glade3] Message-ID: <41D9D64B.7000102@imendio.com> This is a multi-part message in MIME format. --------------060508000200080709040805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -- Imendio AB, http://www.imendio.com/ --------------060508000200080709040805 Content-Type: message/rfc822; name="Re: [Glade-devel] Better support for adding external catalogs in Glade3" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [Glade-devel] Better support for adding external catalogs in Glade3" Message-ID: <41D9D5FC.2070302@imendio.com> Date: Tue, 04 Jan 2005 00:32:12 +0100 From: Mikael Hallendal User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bighead@users.sourceforge.net Subject: Re: [Glade-devel] Better support for adding external catalogs in Glade3 References: <41D9A362.6010600@imendio.com> <1104792330.7397.3.camel@debian> In-Reply-To: <1104792330.7397.3.camel@debian> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archit Baweja wrote: > Hi Hi, > Yup, sounds better. > > But I don't understand why can't 'make install' or rpm/deb's > post_install scripts just have a simple 'sed command' to add it to > glade-palette.xml? > > Just a thought. Thought about that to but the conclusion I came to was that it was very little (none) to this solution and it would just be a hassle for packagers to run yet another script in there postinstalls. You would only append to the palette file anyway. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ --------------060508000200080709040805-- From micke@imendio.com Tue Jan 4 01:57:54 2005 From: micke@imendio.com (Mikael Hallendal) Date: Tue, 04 Jan 2005 02:57:54 +0100 Subject: [Glade-devel] Better support for adding external catalogs in Glade3 In-Reply-To: <41D9A362.6010600@imendio.com> References: <41D9A362.6010600@imendio.com> Message-ID: <41D9F822.7000202@imendio.com> Mikael Hallendal wrote: Hi again, Found Tristan on IRC so we discussed it here and came to the conclusion that it would be nice to get rid of all the xml files per widget. Another thing was to merge all gtk catalogs into one file. So here is a first draft on a format that we could use: The idea is that GladeCatalog becomes a container of everything that has to do with a certain library, using Gtk+ as example here: ignore ignore ... ... As you can see I have also splitted the definition of a class from the grouping of them. The idea here is to in the future be able to have user defined groups, like "My favorites" that can use the same format but reside in the users home directory. It won't define any widgets but would be something like: We also need to define the format in a DTD for validation of catalog files. Any comments? Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ From richard@imendio.com Wed Jan 5 18:37:08 2005 From: richard@imendio.com (Richard Hult) Date: Wed, 05 Jan 2005 19:37:08 +0100 Subject: [Glade-devel] Libglade integration thoughts Message-ID: <41DC33D4.10000@imendio.com> Hi all, I've been thinking a bit about the LIBGLADE_INTEGRATION branch and I have some thoughts about it. Basically as I see it, there is one pro with using libglade to load the files: The parser doesn't need to be duplicated. Some cons: Libglade is really meant to be used for "runtime" operation, as used normally by applications. In order to be used to load glade files in glade, it needs to either be hacked to have two "modes", one normal mode and one for glade where it keeps more data around, or it will need to keep unneccesary data. An example of this is the i18n metadata (translatable, context, i18n comment) that is edited by the user in glade, but only used during parsing in normal use, or not used at all (the comment). Besides just storing the metadata, there are additional problems handling it. For instance, the i18n context: libglade optionally strips a context prefix from strings before translating them and this prefix needs to be kept when used in glade, since it's part of the original string that the user inputs. Translations also need to be special cased in some way. Right now, all strings that happen to be translated in glade itself, also are translated in the loaded files. Every time we need to add some kind of metadata, libglade would need to be involved. There would be an added constraint on what we can do with the glade UI, and also be more work to fit it into libglade's parser. Finally, there are plans for GTK+ to get an equivalence of libglade soon, in 2.8 if possible. Once that happens, there will be no possibility for glade special casing, additions or hacks inside GTK+ for glade specific stuff. If we have our own parser, we can handle everything inside glade. In my opinion, the code duplication involved here (pretty small, the parser isn't that big), is worth the gains. Any comments on this would be appreciated. Regards, Richard -- Imendio AB, http://www.imendio.com/ From micke@imendio.com Wed Jan 5 19:29:28 2005 From: micke@imendio.com (Mikael Hallendal) Date: Wed, 05 Jan 2005 20:29:28 +0100 Subject: [Glade-devel] Better support for adding external catalogs in Glade3 In-Reply-To: <41D9F822.7000202@imendio.com> References: <41D9A362.6010600@imendio.com> <41D9F822.7000202@imendio.com> Message-ID: <41DC4018.6040909@imendio.com> This is a multi-part message in MIME format. --------------010107010301010407090107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mikael Hallendal wrote: Hi, Just implemented the changes to do this, available in imendio-0501-branch for testing. Here is the resulting gtk+.catalog. There might still be some issues I haven't found yet so please let me know if you find anything. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ --------------010107010301010407090107 Content-Type: text/plain; name="gtk+.catalog" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gtk+.catalog" ignore ignore glade_gtk_standard_string_spec glade_gtk_widget_set_tooltip glade_gtk_widget_get_tooltip ignore ignore GtkWidget glade_gtk_container_replace_child glade_gtk_container_fill_empty glade_gtk_standard_int_spec The number of items in the box glade_gtk_box_set_size glade_gtk_box_get_size glade_gtk_box_verify_size GtkWidget empty GtkWidget glade_gtk_paned_fill_empty glade_gtk_window_post_create ignore ignore ignore ignore ignore ignore GtkWidget empty glade_gtk_standard_int_spec The number of items in the toolbar glade_gtk_toolbar_set_size glade_gtk_toolbar_get_size glade_gtk_toolbar_verify_size GtkWidget empty glade_gtk_stock_spec glade_gtk_button_set_stock glade_gtk_standard_int_spec The response ID of this button in a dialog (it's NOT useful if this button is not in a GtkDialog) ignore ignore GtkWidget empty glade_gtk_standard_string_spec glade_gtk_radio_button_set_group glade_gtk_radio_button_get_group glade_gtk_tree_view_post_create glade_gtk_dialog_post_create glade_gtk_dialog_get_internal_child glade_gtk_dialog_child_property_applies ignore GtkWidget glade_gtk_dialog_fill_empty glade_gtk_table_set_n_rows glade_gtk_table_verify_n_rows glade_gtk_table_set_n_columns glade_gtk_table_verify_n_columns GtkWidget empty glade_gtk_standard_int_spec The number of pages in the notebook glade_gtk_notebook_set_n_pages glade_gtk_notebook_get_n_pages glade_gtk_notebook_verify_n_pages GtkWidget empty glade_gtk_notebook_replace_child glade_gtk_standard_string_spec The tab label text of this page widget glade_gtk_notebook_set_tab_label_text glade_gtk_notebook_get_tab_label_text Boolean Set if the statusbar has a resize grip or not glade_gtk_statusbar_set_has_resize_grip glade_gtk_statusbar_get_has_resize_grip GtkWidget empty glade_gtk_fixed_post_create GtkWidget empty glade_gtk_message_dialog_post_create ignore --------------010107010301010407090107-- From Tristan Van Berkom Wed Jan 5 20:31:12 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Wed, 5 Jan 2005 15:31:12 -0500 Subject: [Glade-devel] Libglade integration thoughts In-Reply-To: <41DC33D4.10000@imendio.com> References: <41DC33D4.10000@imendio.com> Message-ID: <560259cb05010512316aa8c332@mail.gmail.com> On Wed, 05 Jan 2005 19:37:08 +0100, Richard Hult wrote: > Hi all, > > I've been thinking a bit about the LIBGLADE_INTEGRATION branch and I > have some thoughts about it. For those who are interested, this is the meeting post where use of libglade as a loader/saver was originaly brought up: http://lists.ximian.com/archives/public/glade-devel/2004-October/000844.html I just re-read it to refresh my memory. > Basically as I see it, there is one pro with using libglade to load the > files: The parser doesn't need to be duplicated. > > Some cons: > > Libglade is really meant to be used for "runtime" operation, as used > normally by applications. In order to be used to load glade files in > glade, it needs to either be hacked to have two "modes", one normal mode > and one for glade where it keeps more data around, or it will need to > keep unneccesary data. I wouldn't call it a hack at all, the libglade api uses glade_xml_build_widget () to actualy construct the widget and add it to a hash table for lookups (and some other misc stuff), But the glade file is already parsed at that point and loaded into a GladeInterface structure, we use the GladeInterface struct to build our widgets, not a dual mode to glade_xml_new(). Note also that libglade dosn't need all that much extra code to be able to load files, the GladeInterface struct might grow a few bytes in user applications but if those applications are written properly, they'll g_object_unref (xml) once they finished doing any glade_xml_get_widget() (since the GladeXML is heavy and useless to have around after application startup anyway). > An example of this is the i18n metadata (translatable, context, i18n > comment) that is edited by the user in glade, but only used during > parsing in normal use, or not used at all (the comment). > > Besides just storing the metadata, there are additional problems > handling it. For instance, the i18n context: libglade optionally strips > a context prefix from strings before translating them and this prefix > needs to be kept when used in glade, since it's part of the original > string that the user inputs. > > Translations also need to be special cased in some way. Right now, all > strings that happen to be translated in glade itself, also are > translated in the loaded files. > > Every time we need to add some kind of metadata, libglade would need to > be involved. There would be an added constraint on what we can do with > the glade UI, and also be more work to fit it into libglade's parser. In 99% of these cases, namespaced custom properties can be used (which are transperent to libglade), and in any other cases (such as: `text' which forces us to add `->translatable' to the GladePropInfo struct) this does two good things for us: 1.) It forces us to reconsider this design (I'm still wondering why "translatable" isn't just a custom property on GtkLabel or any other translatable widgets, I have to admit I havent understood why "properties" are translatable directly. 2.) It forces us to update GladeInterface structures in the 1% of the time when its really nescisary, this IMO is a good thing because it should reduce overall confusion (It should be a plus that the GladeInterface structures are a direct and complete replication of all glade metadata) Since it would have to be updated somewhere in glade-3 anyway, why not do it in one centralized place ? > Finally, there are plans for GTK+ to get an equivalence of libglade > soon, in 2.8 if possible. Once that happens, there will be no > possibility for glade special casing, additions or hacks inside GTK+ for > glade specific stuff. If we have our own parser, we can handle > everything inside glade. I dont see why this should be a problem, we can still use an exposed low level parser in gtk+ to get GladeInterface built from xml files, we also get the added gain of alot more people arguing for or against integration of features (which are most likely hacks) such as "translatable" on properties (and in normal cases, we just use custom properties). There is this one major added gain in loading/saving glade files in our own duplicated codebase: It allows us to dictate the functionality of glade without being forced to cooperate directly with other projects, I am not convinced that this is a valid plus. Cheers, -Tristan From richard@imendio.com Wed Jan 5 23:32:36 2005 From: richard@imendio.com (Richard Hult) Date: Thu, 06 Jan 2005 00:32:36 +0100 Subject: [Glade-devel] Libglade integration thoughts In-Reply-To: <560259cb05010512316aa8c332@mail.gmail.com> References: <41DC33D4.10000@imendio.com> <560259cb05010512316aa8c332@mail.gmail.com> Message-ID: <41DC7914.9050302@imendio.com> Tristan Van Berkom wrote: > On Wed, 05 Jan 2005 19:37:08 +0100, Richard Hult wrote: Hi again, >>Some cons: >> >>Libglade is really meant to be used for "runtime" operation, as used >>normally by applications. In order to be used to load glade files in >>glade, it needs to either be hacked to have two "modes", one normal mode >>and one for glade where it keeps more data around, or it will need to >>keep unneccesary data. > > > I wouldn't call it a hack at all, > the libglade api uses glade_xml_build_widget () to actualy construct > the widget and add it to a hash table for lookups (and some other misc stuff), > But the glade file is already parsed at that point and loaded into a > GladeInterface structure, we use the GladeInterface struct to build our widgets, > not a dual mode to glade_xml_new(). Yes, I know. It needs to parse and handle any glade specific metadata at the parser level, data that has nothing to do with libglade. This is not necessarily too bad, just a reflection if we want to take all aspects in consideration. > Note also that libglade dosn't need all that much extra code to be able > to load files, the GladeInterface struct might grow a few bytes in > user applications > but if those applications are written properly, they'll g_object_unref (xml) > once they finished doing any glade_xml_get_widget() (since the GladeXML is > heavy and useless to have around after application startup anyway). Indeed, although I was thinking of the parser code rather than the GladeXML parts. Also not necessarily bad, but it adds complexity to libglade. Like above, just another point to show that there isn't only gains in using libglade for this. >>An example of this is the i18n metadata (translatable, context, i18n >>comment) that is edited by the user in glade, but only used during >>parsing in normal use, or not used at all (the comment). >> >>Besides just storing the metadata, there are additional problems >>handling it. For instance, the i18n context: libglade optionally strips >>a context prefix from strings before translating them and this prefix >>needs to be kept when used in glade, since it's part of the original >>string that the user inputs. We need to update the libglade patch to handle this if we are going the libglade route. The i18n metadata needs to be handled differently when running in "glade mode" and "normal mode". Maybe this can be done by deferring the translation and stripping GladeXML layer instead and keeping the original string in the GladeInterface layer, like you suggested on IRC. >>Every time we need to add some kind of metadata, libglade would need to >>be involved. There would be an added constraint on what we can do with >>the glade UI, and also be more work to fit it into libglade's parser. > > > In 99% of these cases, namespaced custom properties can be used (which > are transperent to libglade), and in any other cases (such as: > `text' > which forces us to add `->translatable' to the GladePropInfo struct) this > does two good things for us: If all additions can be handled with new properties rather than parameters on exisiting properties, it can be done this way. I don't know if that's the case. > 1.) It forces us to reconsider this design (I'm still wondering why > "translatable" isn't just a custom property on GtkLabel or any > other translatable widgets, I have to admit I havent understood > why "properties" are translatable directly. You need to be able to set this on a property-by-property basis. If the widget has more than one string, not all of them needs to be marked for translation. The context and comment are also properties of each string, not the whole widget. In short it's not the widget that is translatable, it's each individual string. > 2.) It forces us to update GladeInterface structures in the 1% of the time > when its really nescisary, this IMO is a good thing because it should > reduce overall confusion (It should be a plus that the GladeInterface > structures are a direct and complete replication of all > glade metadata) > Since it would have to be updated somewhere in glade-3 anyway, why > not do it in one centralized place ? If libglade isn't used and therefore doesn't need changing due to glade changes, we already have one centralized place which would be glade... Or maybe I misunderstood what you meant. >>Finally, there are plans for GTK+ to get an equivalence of libglade >>soon, in 2.8 if possible. Once that happens, there will be no >>possibility for glade special casing, additions or hacks inside GTK+ for >>glade specific stuff. If we have our own parser, we can handle >>everything inside glade. > > > I dont see why this should be a problem, we can still use an exposed > low level parser in gtk+ to get GladeInterface built from xml files, we also > get the added gain of alot more people arguing for or against integration > of features (which are most likely hacks) such as "translatable" on properties > (and in normal cases, we just use custom properties). If this will follow the rest of the patterns in GTK+ recently there probably won't be much interface exposed here. The exposed interface would not be changable as a semi-public API in libglade either. It might be possible to design the API to be very generic and useful for all glade needs though. Anyway, since the non-libglade parser is currently nonfunctional, and since there are no huge problems with the libglade way, and the libglade maintainer is on track with us, I guess libglade is the way to go. I was just very concerned that nobody seemed to have thought about the issues I saw, and wanted to make sure that they were considered. Regards, Richard -- Imendio AB, http://www.imendio.com/ From micke@imendio.com Wed Jan 5 23:58:04 2005 From: micke@imendio.com (Mikael Hallendal) Date: Thu, 06 Jan 2005 00:58:04 +0100 Subject: [Glade-devel] Better support for adding external catalogs in Glade3 In-Reply-To: <41DC4018.6040909@imendio.com> References: <41D9A362.6010600@imendio.com> <41D9F822.7000202@imendio.com> <41DC4018.6040909@imendio.com> Message-ID: <41DC7F0C.20509@imendio.com> Mikael Hallendal wrote: Hi, Seems I'm the only one on this thread so I'll continue to reply to myself ;) I'm planning to write a DTD for validating this new format but thought at the same time to make it consistent, in the old catalog format some attributes where written with studly caps and some not and so on. Looking at .glade files they use the current format: ... So I suggest we do it the same in the catalog files, I'm planning on starting on the DTD tomorrow. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ From Tristan Van Berkom Thu Jan 6 15:38:30 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Thu, 6 Jan 2005 10:38:30 -0500 Subject: [Glade-devel] Libglade integration thoughts In-Reply-To: <41DC7914.9050302@imendio.com> References: <41DC33D4.10000@imendio.com> <560259cb05010512316aa8c332@mail.gmail.com> <41DC7914.9050302@imendio.com> Message-ID: <560259cb0501060738391efd41@mail.gmail.com> Richard has brought up a few points in light of using libglade as a save/load backend to glade-3. - Some complexity has to be added to libglade to ensure that the GladeInterface structures stay intact and are usable for both glade-3 and libglade purposes. - If and when gtk+ integrates a glade file parser, we'll have a frozen api to deal with (although this might still be workable if we reach an agreement for an amply versatile api). Since I think that our current solution doesn't impact libglade in a huge or really negative way, and that we'd have to rethink things when gtk+ integrates a glade parser anyway; I'm still comfortable with the current solution. Cheers, -Tristan From richard@imendio.com Thu Jan 6 19:44:47 2005 From: richard@imendio.com (Richard Hult) Date: Thu, 06 Jan 2005 20:44:47 +0100 Subject: [Glade-devel] Libglade integration thoughts In-Reply-To: <560259cb0501060738391efd41@mail.gmail.com> References: <41DC33D4.10000@imendio.com> <560259cb05010512316aa8c332@mail.gmail.com> <41DC7914.9050302@imendio.com> <560259cb0501060738391efd41@mail.gmail.com> Message-ID: <41DD952F.9060606@imendio.com> Tristan Van Berkom wrote: > Richard has brought up a few points in light of using libglade as a > save/load backend to glade-3. > > - Some complexity has to be added to libglade to ensure that the > GladeInterface structures stay intact and are usable for both glade-3 > and libglade purposes. Yeah, we also need to change the current libglade patch to not modify the API, since it is used by third-party libraries that install libglade modules. There are several modules in gnomecvs that do this and I don't think we can assume that there are no third-party modules out there doing the same. /Richard -- Imendio AB, http://www.imendio.com/ From Tristan Van Berkom Thu Jan 6 20:47:36 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Thu, 6 Jan 2005 15:47:36 -0500 Subject: [Glade-devel] Libglade integration thoughts In-Reply-To: <41DD952F.9060606@imendio.com> References: <41DC33D4.10000@imendio.com> <560259cb05010512316aa8c332@mail.gmail.com> <41DC7914.9050302@imendio.com> <560259cb0501060738391efd41@mail.gmail.com> <41DD952F.9060606@imendio.com> Message-ID: <560259cb05010612476705fee4@mail.gmail.com> On Thu, 06 Jan 2005 20:44:47 +0100, Richard Hult wrote: [...] > Yeah, we also need to change the current libglade patch to not modify > the API, since it is used by third-party libraries that install libglade > modules. There are several modules in gnomecvs that do this and I don't > think we can assume that there are no third-party modules out there > doing the same. Ah yes, I didn't catch this during the implementation, when a library registers a widget with libglade using glade_register_widget(), the build_children callback is called with a GladeWidgetInfo struct, thus rendering GladeWidgetInfo & GladeProperty public data types. Hmm, I did kind of enjoy refering to properties as GladeProperty, but I guess well have to find a new name... Cheers, -Tristan From dearestchum@yahoo.co.in Sun Jan 9 12:55:39 2005 From: dearestchum@yahoo.co.in (Muthu) Date: Sun, 9 Jan 2005 04:55:39 -0800 (PST) Subject: [Glade-devel] Octave GUI Editor Based on Glade In-Reply-To: <41DD952F.9060606@imendio.com> Message-ID: <20050109125539.21393.qmail@web8407.mail.in.yahoo.com> Hi! Im trying to make a Octave GUI Editor Based on Glade, version 2.0. I have been succesful in extending GLADE, GTK GUI Builder for use with Octave so that we could have a GUI-IDE like the ones available for NON-FREE software. RIght now this GLADE editor can allow you to create a new UI, with the base as a GtkFixed widget, so that user need not bother about packing/box layouts etc. The output is saved as a .glade file. Now we are planning to extend this .glade file to generate the octave sources, with help of libXML etc. But we need to have the octave GUI API ready before that. Well thats another thing we are working on ... I would like to know if version 2.6 and other versions will be compatible with the current glade stuff? More news soon. Cheers Muthu. __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From fanzhe.cui@intel.com Mon Jan 10 16:24:06 2005 From: fanzhe.cui@intel.com (Cui, Fanzhe) Date: Mon, 10 Jan 2005 11:24:06 -0500 Subject: [Glade-devel] Win32 port of GTK+2.6.1 Message-ID: <7C3C94178AEE594DAB38B13DBCD68C76CFE10B@pysmsx401.amr.corp.intel.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F730.CEB3136C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I saw the GTK+2.6.1 pkg that was posted on http://www.gtk.org/, and was the latest stable version available right now, and I hope some one can post the Win32 port soon. I am using GTK 2.4.14 of win32 port from http://gladewin32.sourceforge.net/. But I have a problem with GLIB in GTK+2.4.14, so I need to upgrade to GTK+2.6.1. Does anybody know when the Win32 port will be posted on web, or any ideas how to make it available? =20 Best Regards, Fanz Intel America's, Inc =20 ------_=_NextPart_001_01C4F730.CEB3136C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I saw = the GTK+2.6.1=20 pkg that was posted on http://www.gtk.org/,=20 and was the latest stable version available right now, and I hope = some one=20 can post the Win32 port soon. I am using GTK 2.4.14 of win32 port = from http://gladewin32.sourceforge= .net/.
But I = have a problem=20 with GLIB in GTK+2.4.14, so I need to upgrade to GTK+2.6.1. Does = anybody=20 know when the Win32 port will be posted on web, or any ideas how to make = it=20 available?
 
Best = Regards,
Fanz
Intel=20 America's, Inc
 
------_=_NextPart_001_01C4F730.CEB3136C-- From fanzhe.cui@intel.com Mon Jan 10 18:59:23 2005 From: fanzhe.cui@intel.com (Cui, Fanzhe) Date: Mon, 10 Jan 2005 13:59:23 -0500 Subject: [Glade-devel] RE: Win32 port of GTK+2.6.1 Message-ID: <7C3C94178AEE594DAB38B13DBCD68C76CFE492@pysmsx401.amr.corp.intel.com> Tor, Thank you for the descriptions on current GTK+2.6.1, and I am excited to hear that the GTK+2.6.1 win32 port will be release some time in the future. Do you have in your mind something about when win32 port will roughly be available. I am considering if I want to wait for the release or to try to build the win32 port by myself. Regards, Fanz=20 -----Original Message----- From: Tor Lillqvist [mailto:tml@iki.fi]=20 Sent: Monday, January 10, 2005 12:51 PM To: Cui, Fanzhe Cc: tml@iki.fi; glade-devel@lists.ximian.com Subject: Win32 port of GTK+2.6.1 Cui, Fanzhe writes: > Does anybody know when the Win32 port will be posted on web, > or any ideas how to make it available? There are still a couple of relatively important (IMHO) open Win32 issues in the GTK+ 2.6.1 sources. As soon as they have been resolved (fixes committed), I will build and release Win32 binaries (i.e. a 2.6.1-timestamp snapshot unless 2.6.2 happens to be relased suitably). A warning to people thinking of building software for Windows against GTK+ 2.6.1: Plase read and ponder what it says in the README file: * GLib 2.6 introduces the concept of 'GLib filename encoding', which is the on-disk encoding on Unix, but UTF-8 on Windows. All GLib functions returning or accepting pathnames have been changed to expect filenames in this encoding, and the common POSIX functions dealing with pathnames have been wrapped. These wrappers are declared in the header which must be included explicitly; it is not included through . On current (NT-based) Windows versions, where the on-disk file names are Unicode, these wrappers use the wide-character API in the C library. Thus applications can handle file names containing any Unicode characters through GLib's own API and its POSIX wrappers, not just file names restricted to characters in the system codepage. To keep binary compatibility with applications compiled against older versions of GLib, the Windows DLL still provides entry points with the old semantics using the old names, and applications compiled against GLib 2.6 will actually use new names for the functions. This is transparent to the programmer. When compiling against GLib 2.6, applications intended to be portable to Windows must take the UTF-8 file name encoding into consideration, and use the gstdio wrappers to access files whose names have been constructed from strings returned from GLib. * Likewise, g_get_user_name() and g_get_real_name() have been changed=20 to return UTF-8 on Windows, while keeping the old semantics for=20 applications compiled against older versions of GLib. I.e., if you construct file names from strings returned from GLib (g_get_user_name, g_dir_read_name, g_get_current_dir, etc), you *must* use the so-called gstdio wrappers (g_open, g_fopen, etc) with these file names. (No ifdefs needed, it doesn't to use the wrappers on Unix, too, although they don't do anything.) --tml From =?ks_c_5601-1987?B?wba8wQ==?= Wed Jan 12 02:53:56 2005 From: =?ks_c_5601-1987?B?wba8wQ==?= (=?ks_c_5601-1987?B?wba8wQ==?=) Date: Wed, 12 Jan 2005 11:53:56 +0900 Subject: [Glade-devel] XML DTD description document location in glade.... Message-ID: <39f801c4f851$f51833e0$8310fe81@etri.info> This is a multi-part message in MIME format. ------=_NextPart_000_39F9_01C4F89D.64FFDBE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_39F9_01C4F89D.64FFDBE0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+DQo8RElWIGlkPW1zZ2JvZHkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6ILG8uLIiPkhpPC9ESVY+DQo8RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiCxvLiyIj4mbmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6ILG8uLIiPkkgYW0gdHJ5aW5nIHRvIGJ1aWxkIGFuIFhNTCZuYnNwO2NvbmZp ZyBmaWxlIGFuZCB0cnlpbmcgdG8gZmluZCB0aGUgY3VycmVudCBEVEQgZGVzY3JpcHRpb24gZG9j cy4uLjwvRElWPg0KPERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4 siI+Jm5ic3A7PC9ESVY+DQo8RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiCxvLiyIj5QcmV2aW91c2x5IGluIGdsYWRlL2RvYy9maWxlX2Zvcm1hdC50eHQ8L0RJVj4NCjxE SVYgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLIiPiZuYnNwOzwvRElW Pg0KPERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+QW55IGlk ZWEuLndoZXJlIHRoaXMgZG9jIGhhcyBtb3ZlZCB0byA/PC9ESVY+DQo8RElWIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiyIj4mbmJzcDs8L0RJVj4NCjxESVYgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLIiPlRoYW5rczwvRElWPg0KPERJViBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+Jm5ic3A7PC9ESVY+DQo8 RElWIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiyIj5Kb2U8L0RJVj48 QlI+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0w IHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1h aWw9Z2xhZGUtZGV2ZWxAbGlzdHMueGltaWFuLmNvbSZuYW1lPWdsYWRlLWRldmVsJTQwbGlzdHMu eGltaWFuLmNvbSZmcm9tZW1haWw9dmlub2RAZXRyaS5yZS5rciZtZXNzYWdlaWQ9JTNDMjBlMzA1 ZTgtZmY3Ny00MTc3LTg2MmYtZTZiZjJmNDVjNDZiQGV0cmkucmUua3IlM0UiPg== ------=_NextPart_000_39F9_01C4F89D.64FFDBE0-- From fanzhe.cui@intel.com Wed Jan 12 04:16:27 2005 From: fanzhe.cui@intel.com (Cui, Fanzhe) Date: Tue, 11 Jan 2005 23:16:27 -0500 Subject: FW: [Glade-devel] RE: Win32 port of GTK+2.6.1 Message-ID: <7C3C94178AEE594DAB38B13DBCD68C76D4F4EF@pysmsx401.amr.corp.intel.com> Hi, Tor and Ivan, Thank you for building and posting the GTK+2.6.1 for win32 port. The package was great, and I was able to use g_fopen() in the program. I built the project of gtk-demo (I call it gtk-demo_win32) with MS VC++ 7.3, and most of them are working except a couple of things.=20 So I want to provide some feedback. I know you still working on some issues of this release, and I am not sure the problem I am seeing was related to the issue you mentioned. After I started gtk-demo_win32 I was able to select the functions like "Button Boxes" and "Change Display" etc, which behaved the exactly same as gtk-demo which came with the installation of gtk+, and these functions were working. But When I selected "Images" from gtk-demo_win32, I got error a dialog box with error message: "Failure reading image file 'alphatest.png': Bad file descriptor". The image file exists on the right folder with other image files. I think the problem was caused by a kind of compatibility between cygwin (mingw) and msvc.=20 Regards, Fanz -----Original Message----- From: Cui, Fanzhe=20 Sent: Tuesday, January 11, 2005 8:17 AM To: 'Ivan Wong' Subject: RE: [Glade-devel] RE: Win32 port of GTK+2.6.1 Hi, Ivan, That's great! I am going to try that immediately. Cheers! Fanz=20 -----Original Message----- From: Ivan Wong [mailto:email@ivanwong.info]=20 Sent: Tuesday, January 11, 2005 8:00 AM To: Cui, Fanzhe Subject: Re: [Glade-devel] RE: Win32 port of GTK+2.6.1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Cui, I just released the new installer: http://gladewin32.sourceforge.net However, as Tor said, he will apply a couple of important patches to the ~ official binaries. As soon as he makes a release, I will update the installer again. Rgrds, Ivan. -----Original Message----- From: glade-devel-admin@lists.ximian.com [mailto:glade-devel-admin@lists.ximian.com] On Behalf Of Cui, Fanzhe Sent: Monday, January 10, 2005 1:59 PM To: Tor Lillqvist Cc: glade-devel@lists.ximian.com Subject: [Glade-devel] RE: Win32 port of GTK+2.6.1 Tor, Thank you for the descriptions on current GTK+2.6.1, and I am excited to hear that the GTK+2.6.1 win32 port will be release some time in the future. Do you have in your mind something about when win32 port will roughly be available. I am considering if I want to wait for the release or to try to build the win32 port by myself. Regards, Fanz=20 -----Original Message----- From: Tor Lillqvist [mailto:tml@iki.fi]=20 Sent: Monday, January 10, 2005 12:51 PM To: Cui, Fanzhe Cc: tml@iki.fi; glade-devel@lists.ximian.com Subject: Win32 port of GTK+2.6.1 Cui, Fanzhe writes: > Does anybody know when the Win32 port will be posted on web, > or any ideas how to make it available? There are still a couple of relatively important (IMHO) open Win32 issues in the GTK+ 2.6.1 sources. As soon as they have been resolved (fixes committed), I will build and release Win32 binaries (i.e. a 2.6.1-timestamp snapshot unless 2.6.2 happens to be relased suitably). A warning to people thinking of building software for Windows against GTK+ 2.6.1: Plase read and ponder what it says in the README file: * GLib 2.6 introduces the concept of 'GLib filename encoding', which is the on-disk encoding on Unix, but UTF-8 on Windows. All GLib functions returning or accepting pathnames have been changed to expect filenames in this encoding, and the common POSIX functions dealing with pathnames have been wrapped. These wrappers are declared in the header which must be included explicitly; it is not included through . On current (NT-based) Windows versions, where the on-disk file names are Unicode, these wrappers use the wide-character API in the C library. Thus applications can handle file names containing any Unicode characters through GLib's own API and its POSIX wrappers, not just file names restricted to characters in the system codepage. To keep binary compatibility with applications compiled against older versions of GLib, the Windows DLL still provides entry points with the old semantics using the old names, and applications compiled against GLib 2.6 will actually use new names for the functions. This is transparent to the programmer. When compiling against GLib 2.6, applications intended to be portable to Windows must take the UTF-8 file name encoding into consideration, and use the gstdio wrappers to access files whose names have been constructed from strings returned from GLib. * Likewise, g_get_user_name() and g_get_real_name() have been changed=20 to return UTF-8 on Windows, while keeping the old semantics for=20 applications compiled against older versions of GLib. I.e., if you construct file names from strings returned from GLib (g_get_user_name, g_dir_read_name, g_get_current_dir, etc), you *must* use the so-called gstdio wrappers (g_open, g_fopen, etc) with these file names. (No ifdefs needed, it doesn't to use the wrappers on Unix, too, although they don't do anything.) --tml _______________________________________________ Glade-devel maillist - Glade-devel@lists.ximian.com http://lists.ximian.com/mailman/listinfo/glade-devel From Joao Victor Wed Jan 12 11:01:44 2005 From: Joao Victor (Joao Victor) Date: Wed, 12 Jan 2005 11:01:44 +0000 Subject: [Glade-devel] Proposal: new website design Message-ID: Hi, recently i've made a new design for the Java-Gnome website, which can be seen here: http://java-gnome.sourceforge.net/ And i was thinking about making a new design for the Glade website too. What do you think? The idea is to make it more visually pleasant *and* to make it look Gnomeish, by using that Gnome style which you see on the Java-Gnome website. In case you guys agree on making a new design, who should i contact to exchange opinions, upload the files, etc? Cheers, J.V. From damon@karuna.uklinux.net Wed Jan 12 13:11:52 2005 From: damon@karuna.uklinux.net (Damon Chaplin) Date: Wed, 12 Jan 2005 13:11:52 +0000 Subject: [Glade-devel] XML DTD description document location in glade.... In-Reply-To: <39f801c4f851$f51833e0$8310fe81@etri.info> References: <39f801c4f851$f51833e0$8310fe81@etri.info> Message-ID: <1105535512.2946.3.camel@Eternity> On Wed, 2005-01-12 at 02:53, 조셉 wrote: > Hi > > I am trying to build an XML config file and trying to find the current > DTD description docs... > > Previously in glade/doc/file_format.txt > > Any idea..where this doc has moved to ? You can find the DTD at http://glade.gnome.org/glade-2.0.dtd Damon From damon@karuna.uklinux.net Wed Jan 12 13:15:46 2005 From: damon@karuna.uklinux.net (Damon Chaplin) Date: Wed, 12 Jan 2005 13:15:46 +0000 Subject: [Glade-devel] Octave GUI Editor Based on Glade In-Reply-To: <20050109125539.21393.qmail@web8407.mail.in.yahoo.com> References: <20050109125539.21393.qmail@web8407.mail.in.yahoo.com> Message-ID: <1105535746.2946.7.camel@Eternity> On Sun, 2005-01-09 at 12:55, Muthu wrote: > Hi! > Im trying to make a Octave GUI Editor Based on Glade, > version 2.0. > > I have been succesful in extending GLADE, GTK GUI > Builder for use with Octave so that we could have a > GUI-IDE like the ones available for NON-FREE > software. > > RIght now this GLADE editor can allow you to create a > new UI, with the base as a GtkFixed widget, so that > user need not bother about packing/box layouts etc. > The output is saved as a .glade file. > > Now we are planning to extend this .glade file to > generate the octave sources, with help of libXML etc. > But we need to have the octave GUI > API ready before that. Well thats another thing we are > working on ... > > I would like to know if version 2.6 and other versions > will be compatible with the current glade stuff? Yes, there are no plans on changing the file format. We will just be adding support for new widgets and new widget properties. Note that the use of GtkFixed is not recommended, since it doesn't work well when interfaces are translated into different languages. Text in some languages is a lot longer than in others. Damon From damon@karuna.uklinux.net Wed Jan 12 13:18:14 2005 From: damon@karuna.uklinux.net (Damon Chaplin) Date: Wed, 12 Jan 2005 13:18:14 +0000 Subject: [Glade-devel] Proposal: new website design In-Reply-To: References: Message-ID: <1105535894.2946.11.camel@Eternity> On Wed, 2005-01-12 at 11:01, Joao Victor wrote: > Hi, > > recently i've made a new design for the Java-Gnome website, which can > be seen here: > http://java-gnome.sourceforge.net/ > > And i was thinking about making a new design for the Glade website > too. What do you think? The idea is to make it more visually pleasant > *and* to make it look Gnomeish, by using that Gnome style which you > see on the Java-Gnome website. > > In case you guys agree on making a new design, who should i contact to > exchange opinions, upload the files, etc? I would like a new website. But I only want a few basic pages of HTML, like we have now. If you could come up with a nice redesign, that would be handy. Damon From fanzhe.cui@intel.com Wed Jan 12 14:38:01 2005 From: fanzhe.cui@intel.com (Cui, Fanzhe) Date: Wed, 12 Jan 2005 09:38:01 -0500 Subject: [Glade-devel] RE: Win32 port of GTK+2.6.1 Message-ID: <7C3C94178AEE594DAB38B13DBCD68C76D4F732@pysmsx401.amr.corp.intel.com> Tor, I think I going to try with the suggestion that I made. Personally I think the info you provided is very helpful, and I think some other users developing system with MS VC++ 7.xx could have the same issue. If we have tips or documents addressing such issue, it could be beneficial to others. Regards, Fanz=20 -----Original Message----- From: Tor Lillqvist [mailto:tml@iki.fi]=20 Sent: Wednesday, January 12, 2005 4:19 AM To: Cui, Fanzhe Cc: Ivan Wong; Tor Lillqvist; glade-devel@lists.ximian.com; gtk-devel-list@gnome.org Subject: FW: [Glade-devel] RE: Win32 port of GTK+2.6.1 Cui, Fanzhe writes: > I built the project of gtk-demo (I call it gtk-demo_win32) with MS > VC++ 7.3, and most of them are working except a couple of things. Remember that file descriptors (the small numbers returned by open() etc, and also stored inside FILE structs) are local to the C runtime. They are not known to the Windows kernel, like file descriptors in Unix. You cannot pass file descriptors (and thus by extension FILE structs) between .exes/.dlls that use different C runtime and expect it to work. If you use MSVC 7.x, the code you produce most likely uses the MSVCR7*.DLL C runtime (or even worse, static C library). If you have a GLib that built with mingw, it uses the MSVCRT.DLL C runtime. I.e. the FILE* that g_fopen() returns won't work in stdio calls in your code. (Or it might work completely wrong, i.e. if you g_fopen() a file, the file descriptor used might be in use for some completely other file in your code, causing very odd things to happen, possibly corrupting important files.) You should rebuild your code to use MSVCRT.DLL. Do a Google search; I am sure that somebody has figured out how to coerce MSVC 7.* to do this. If not, use mingw. Or find a copy of the old but reliable (at least for C) MSVC6 (and apply the SPs) and use that. Also, as the MSVCR7*.DLL are not part of the operating system like MSVCRT.DLL, it's against the (L)GPL to distribute (L)GPL software that would use MSVCR7*.DLL. (I am not a lawyer, but this seems to be the common interpretation of the situation.) Thus, now and in the foreseeable future, (L)GPL software for Windows should continue to use MSVCRT.DLL. I strongly advice people who might still insist on building GLib, GTK+ etc themselves with MSVC 7.* and to use MSVCR7*.DLL to use different names for their DLLs, to avoid confusion. The "standard" DLL names that a mingw build produces should be used only for DLLs that use MSVCRT.DLL. Otherwise there will be no end of confusion if and when there starts to appear various distributions of GTK+ etc built to use different C runtimes but using the same DLL names. --tml From Joao Victor Wed Jan 12 15:16:05 2005 From: Joao Victor (Joao Victor) Date: Wed, 12 Jan 2005 15:16:05 +0000 Subject: [Glade-devel] Proposal: new website design In-Reply-To: <1105539226.7000.25.camel@localhost.localdomain> References: <1105539226.7000.25.camel@localhost.localdomain> Message-ID: On Wed, 12 Jan 2005 09:13:46 -0500, Owen Taylor wrote: > On Wed, 2005-01-12 at 11:01 +0000, Joao Victor wrote: > > Hi, > > > > recently i've made a new design for the Java-Gnome website, which can > > be seen here: > > http://java-gnome.sourceforge.net/ > > [offlist] > > I'm not sure we can allow that modification of the GNOME logo... > usually trademark lawyers aren't very happy about that sort of > thing. > > (The use of Sun purple and the coffee cup might also give > lawyers fits. Not sure.) > > If you want I can try to get it run by the lawyers who have been > handling the GNOME trademark and see what they think. Hmmm... i think it would be nice if you could that yes, please. I'm send a copy of this email to Mark, he's the Java-Gnome maintainer. Cheers, J.V. From micke@imendio.com Wed Jan 12 16:15:20 2005 From: micke@imendio.com (Mikael Hallendal) Date: Wed, 12 Jan 2005 17:15:20 +0100 Subject: [Glade-devel] Glade 3 menu support Message-ID: <41E54D18.2080802@imendio.com> Hi, I'm planning to start working on getting the current menu editor and menu support into a working state. My plan is to do a couple of things: * Create the menu with a bunch of default items (File, Edit, Help). * Set the menu to not expand as default. * Reread the menu when opening the menu editor again, it currently starts from an empty menu. * Making sure that it works properly... It would probably be nice to make the menu editor nicer as suggested on bug 133865 [1] in the future but I'll work now on getting the current editor to work for a first release. If anyone is working on this at the moment, please let me know as soon as possible. Best Regards, Mikael Hallendal [1] http://bugzilla.gnome.org/show_bug.cgi?id=133865 -- Imendio AB, http://www.imendio.com/ From otaylor@redhat.com Wed Jan 12 17:11:33 2005 From: otaylor@redhat.com (Owen Taylor) Date: Wed, 12 Jan 2005 12:11:33 -0500 Subject: FW: [Glade-devel] RE: Win32 port of GTK+2.6.1 In-Reply-To: <41E5452A.2030001@wingide.com> References: <7C3C94178AEE594DAB38B13DBCD68C76D4F4EF@pysmsx401.amr.corp.intel.com> <16868.60294.504000.221805@gargle.gargle.HOWL> <41E5452A.2030001@wingide.com> Message-ID: <1105549893.7603.52.camel@localhost.localdomain> --=-neAOoYOBDbY4ogE98YJZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-01-12 at 10:41 -0500, John Ehresman wrote: > Tor Lillqvist wrote: > > Also, as the MSVCR7*.DLL are not part of the operating system like > > MSVCRT.DLL, it's against the (L)GPL to distribute (L)GPL software that > > would use MSVCR7*.DLL. (I am not a lawyer, but this seems to be the > > common interpretation of the situation.) Thus, now and in the > > foreseeable future, (L)GPL software for Windows should continue to use > > MSVCRT.DLL. The actual language of the operating system exception in the GPL is: : However, as a special exception, the source code distributed need not : include anything that is normally distributed (in either source or : binary form) with the major components (compiler, kernel, and so on) : of the operating system on which the executable runs, unless that : component itself accompanies the executable. Which might possibly provide an out for MSVCR7*.DLL ... since they accompany the (most commonly used) compiler. I suspect what was being thought of was static linking to libraries provided with the compiler, but it could conceivably be stretched to cover this as well. > IANAL, but isn't the situation different w/ GPL v the LGPL? LGPL allows=20 > linking with non-opensource components. It's not a clear issue, but the language in section 5 of the LGPL=20 is specifically about "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it". My interpretation is that the provisions for distributing a LGPL library linked against a proprietary library are pretty much identical to those for distributing a GPL application linked against a proprietary library. My personal, non-legal, non-binding, opinion is that I wouldn't be comfortable distributing a version of GTK+ modified to depend upon a proprietary library unless that proprietary library is=20 covered by the GPL system exception. If no modification to GTK+ is necessary, and the library being=20 linked to is simply a reimplementation of an existing API, I'm a lot more comfortable with it, even though that probably doesn't=20 affect the legal situation. Microsoft redistributables such as GDI+ are probably close enough to being part of the operating system to pass the GPL system exception, even if they weren't distributed with the particular version that the user is rnuning on. > > I strongly advice people who might still insist on building GLib, GTK+ > > etc themselves with MSVC 7.* and to use MSVCR7*.DLL to use different > > names for their DLLs, to avoid confusion. The "standard" DLL names > > that a mingw build produces should be used only for DLLs that use > > MSVCRT.DLL. Otherwise there will be no end of confusion if and when > > there starts to appear various distributions of GTK+ etc built to use > > different C runtimes but using the same DLL names. >=20 > Yes, the names should be changed. Note that this situation is almost=20 > certainly going to become more common as more software will be built=20 > using MSVC 7+. I wonder if we need a "GTK+ Win32 binary API test app" ... some standard .exe to download from gtk.org to check your library build. Regards, Owen --=-neAOoYOBDbY4ogE98YJZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBB5VpFS+2LB0B90LERAllcAKDCNqAQwKu4Be8UAWWYaPRg2tFyCQCfQ6MC fxgCMbTrhdLOH0tBGozOhxY= =SqIa -----END PGP SIGNATURE----- --=-neAOoYOBDbY4ogE98YJZ-- From richard@imendio.com Thu Jan 13 15:13:43 2005 From: richard@imendio.com (Richard Hult) Date: Thu, 13 Jan 2005 16:13:43 +0100 Subject: [Glade-devel] Toolbar support Message-ID: <41E69027.7040806@imendio.com> Hi, I've been looking at getting toolbar editing working (bug #157163). There are basically two options: 1. Make it work like in glade-2, where the toolbar is just a regular container, and you have additional tool items in the palette for toolbar buttons, check/togglebuttons and a toolbar separator item. You can also put any other widget in the toolbar, in which case glade automatically inserts a tool item container for you. 2. Implement a toolbar editor instead and don't expose the toolbar as a container. If anyone has any thoughts about this, I'd be interested in hearing about them. The first solution is pretty good in my opinion. Having a toolbar editor that would work nicely with drag and drop etc would be nice, but it would be a lot more work. Maybe it is something that we can implement later on. Bringing the current glade-2 like toolbar editing to a working state should be pretty quick, I've done most of it already. Adding a container widget automatically like glade-2 does is more tricky, I don't think it's possible currently so we would have to add some infrastructure for that. Do we want this? Comments, anyone? Regards, Richard -- Imendio AB, http://www.imendio.com/ From Tristan Van Berkom Thu Jan 13 15:52:34 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Thu, 13 Jan 2005 10:52:34 -0500 Subject: [Glade-devel] Toolbar support In-Reply-To: <41E69027.7040806@imendio.com> References: <41E69027.7040806@imendio.com> Message-ID: <560259cb050113075222a49cc1@mail.gmail.com> On Thu, 13 Jan 2005 16:13:43 +0100, Richard Hult wrote: > Hi, > > I've been looking at getting toolbar editing working (bug #157163). > There are basically two options: > > 1. Make it work like in glade-2, where the toolbar is just a regular > container, and you have additional tool items in the palette for toolbar > buttons, check/togglebuttons and a toolbar separator item. You can also > put any other widget in the toolbar, in which case glade automatically > inserts a tool item container for you. > > 2. Implement a toolbar editor instead and don't expose the toolbar as a > container. 3. Implement a non-widget relationship between the GtkToolbar and the GtkToolItem. This would mean that on a right click of a GtkToolbar parent would give you an "Add" submenu that allows you to add a choice of - GtkToolItem - GtkToolButton - GtkMenuToolButton - GtkToggleToolButton - GtkRadioToolButton - GtkSeparatorToolItem In the case of a GtkToolItem we could add a placeholder. Currently this is how non-widgets work in glade-3, we could probably do the same thing for menus come to think of it. Hmmmm, Food for thought. -Tristan From richard@imendio.com Fri Jan 14 12:21:52 2005 From: richard@imendio.com (Richard Hult) Date: Fri, 14 Jan 2005 13:21:52 +0100 Subject: [Glade-devel] Toolbar support In-Reply-To: <560259cb050113075222a49cc1@mail.gmail.com> References: <41E69027.7040806@imendio.com> <560259cb050113075222a49cc1@mail.gmail.com> Message-ID: <41E7B960.4050303@imendio.com> Tristan Van Berkom wrote: > On Thu, 13 Jan 2005 16:13:43 +0100, Richard Hult wrote: > >>Hi, >> >>I've been looking at getting toolbar editing working (bug #157163). >>There are basically two options: >> >>1. Make it work like in glade-2, where the toolbar is just a regular >>container, and you have additional tool items in the palette for toolbar >>buttons, check/togglebuttons and a toolbar separator item. You can also >>put any other widget in the toolbar, in which case glade automatically >>inserts a tool item container for you. >> >>2. Implement a toolbar editor instead and don't expose the toolbar as a >>container. > > > 3. Implement a non-widget relationship between the GtkToolbar and > the GtkToolItem. > > This would mean that on a right click of a GtkToolbar parent would > give you an "Add" submenu that allows you to add a choice of > - GtkToolItem > - GtkToolButton > - GtkMenuToolButton > - GtkToggleToolButton > - GtkRadioToolButton > - GtkSeparatorToolItem > > In the case of a GtkToolItem we could add a placeholder. > > Currently this is how non-widgets work in glade-3, we could probably > do the same thing for menus come to think of it. We talked a bit about this on IRC, for those that weren't there, Tristan explained a bit more. Basically, the toolitems would be handled differently than regular widgets, and would not be available in the palette. I don't think that is a good idea since the UI gets a lot less obvious that way, I would definitely prefer to handle this like glade-2 does, as regular widgets, or have a separate toolbar editor dialog. /Richard -- Imendio AB, http://www.imendio.com/ From Tristan Van Berkom Fri Jan 14 14:56:34 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Fri, 14 Jan 2005 09:56:34 -0500 Subject: [Glade-devel] Toolbar support In-Reply-To: <41E7B960.4050303@imendio.com> References: <41E69027.7040806@imendio.com> <560259cb050113075222a49cc1@mail.gmail.com> <41E7B960.4050303@imendio.com> Message-ID: <560259cb0501140656232ac912@mail.gmail.com> On Fri, 14 Jan 2005 13:21:52 +0100, Richard Hult wrote: > Tristan Van Berkom wrote: > > On Thu, 13 Jan 2005 16:13:43 +0100, Richard Hult [...] > > Currently this is how non-widgets work in glade-3, we could probably > > do the same thing for menus come to think of it. > > We talked a bit about this on IRC, for those that weren't there, Tristan > explained a bit more. Basically, the toolitems would be handled > differently than regular widgets, and would not be available in the > palette. I don't think that is a good idea since the UI gets a lot less > obvious that way, I would definitely prefer to handle this like glade-2 > does, as regular widgets, or have a separate toolbar editor dialog. Hmmm, The problem is that the UI gets alot less obvious in the case of non-widgets anyway, what happens when you want to add a GtkEntryCompletion to a GtkEntry (this is probably a bad example), or a GtkSizeGroup to a GtkBox (or are size-groups always toplevels ?). On the one hand, I really want to make the glade-3 code as generic as possible with the highest possible level of code reuse (when dealing with irratic toolkits that are always changing, we want glade-3 to "just work" as much as possible). On the other hand, the GtkOptionMenu in glade-2 (that I just looked at) is really sexy I have to admit :) I think we have to ask ourselves if it is worth special-casing every wierd doodad like toolbars and menus with entire editor codebases ? Cheers, -Tristan Hmmm, the glade-2 menu editor is basicly a property editor for each MenuItem with a treeview that allows you to select the menu items, an equivalent can be reached by navigating the project-view and editing the menu/tool items directly in the editor. What if optionaly the property-editor could display a treeview of its non-widget children (or more specificly its non "GtkContainer->GtkWidget" relation children) and allow Add/Remove capabilities from there ? From pclouds Sat Jan 15 08:24:27 2005 From: pclouds (pclouds) Date: Sat, 15 Jan 2005 15:24:27 +0700 Subject: [Glade-devel] [glade3] notebook tab label Message-ID: Hi, glade3 uses property tab-label to set notebook tab labels. Older glade files use a node with pack option 'tab'. The result is opening old .glade files with glade3 produces double tabs and tabs don't have correct label. Is anyone working on this or is there anyway to convert old glade files to be able to use with glade3? --=20 Bi C=E1=BB=9D Lao From pclouds Sat Jan 15 18:28:11 2005 From: pclouds (pclouds) Date: Sun, 16 Jan 2005 01:28:11 +0700 Subject: [Glade-devel] Re: [glade3] notebook tab label In-Reply-To: References: Message-ID: Noone answered. I tried myself :) I can make the notebook behave just like one in glade-2 and save in glade-2 format. But i can't make it read glade-2 format properly. When it rebuilds the widget tree, it creates (and attachs) all widget first, applies packing properties later. So when packing properties are applied, all tab pages and tab labels are created as tab pages (GladeSupportedChild::add doesn't know anything about packing properties). Any ideas to solve this? On Sat, 15 Jan 2005 15:24:27 +0700, pclouds wrote: > Hi, > glade3 uses property tab-label to set notebook tab labels. Older glade > files use a node with pack option 'tab'. The result is opening > old .glade files with glade3 produces double tabs and tabs don't have > correct label. Is anyone working on this or is there anyway to convert > old glade files to be able to use with glade3? > -- > Bi C=E1=BB=9D Lao >=20 --=20 Bi C=E1=BB=9D Lao From shane_b@users.sourceforge.net Sat Jan 15 23:02:22 2005 From: shane_b@users.sourceforge.net (Shane Butler) Date: Sun, 16 Jan 2005 10:02:22 +1100 Subject: [Glade-devel] Re: [glade3] notebook tab label In-Reply-To: References: Message-ID: <1105830142.4534.4.camel@pluto> --=-lStAtCAk42GP9riRdwNl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, If you need an immediate solution just use glade 2.x series. I was working on fixing the problem but I stopped after realising I would have to use the LIBGLADE_INTEGRATION branch. If you want to look into it, checkout the LIBGLADE_INTEGRATION branch and see how you go. Cheers, Shane On Sun, 2005-01-16 at 01:28 +0700, pclouds wrote: > Noone answered. I tried myself :) I can make the notebook behave just > like one in glade-2 and save in glade-2 format. But i can't make it > read glade-2 format properly. When it rebuilds the widget tree, it > creates (and attachs) all widget first, applies packing properties > later. So when packing properties are applied, all tab pages and tab > labels are created as tab pages (GladeSupportedChild::add doesn't know > anything about packing properties). Any ideas to solve this? > > > On Sat, 15 Jan 2005 15:24:27 +0700, pclouds wrote: > > Hi, > > glade3 uses property tab-label to set notebook tab labels. Older glade > > files use a node with pack option 'tab'. The result is opening > > old .glade files with glade3 produces double tabs and tabs don't have > > correct label. Is anyone working on this or is there anyway to convert > > old glade files to be able to use with glade3? > > -- > > Bi Cờ Lao > > > > --=-lStAtCAk42GP9riRdwNl Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

If you need an immediate solution just use glade 2.x series. I was working on fixing the problem but I stopped after realising I would have to use the LIBGLADE_INTEGRATION branch. If you want to look into it, checkout the LIBGLADE_INTEGRATION branch and see how you go.

Cheers, Shane

On Sun, 2005-01-16 at 01:28 +0700, pclouds wrote: 
Noone answered. I tried myself :) I can make the notebook  behave just
like one in glade-2 and save in glade-2 format. But i can't make it
read glade-2 format properly. When it rebuilds the widget tree, it
creates (and attachs) all widget first, applies packing properties
later. So when packing properties are applied, all tab pages and tab
labels are created as tab pages (GladeSupportedChild::add doesn't know
anything about packing properties). Any ideas to solve this?


On Sat, 15 Jan 2005 15:24:27 +0700, pclouds <pclouds@gmail.com> wrote:
> Hi,
> glade3 uses property tab-label to set notebook tab labels. Older glade
> files use a <child> node with pack option 'tab'. The result is opening
> old .glade files with glade3 produces double tabs and tabs don't have
> correct label. Is anyone working on this or is there anyway to convert
> old glade files to be able to use with glade3?
> --
> Bi Cờ Lao
>
--=-lStAtCAk42GP9riRdwNl-- From email@ivanwong.info Tue Jan 18 20:41:45 2005 From: email@ivanwong.info (Ivan Wong) Date: Wed, 19 Jan 2005 04:41:45 +0800 Subject: [Glade-devel] Re: [glade3] notebook tab label In-Reply-To: <1105830142.4534.4.camel@pluto> References: <1105830142.4534.4.camel@pluto> Message-ID: <41ED7489.5080805@ivanwong.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shane, | If you need an immediate solution just use glade 2.x series. I was | working on fixing the problem but I stopped after realising I would have | to use the LIBGLADE_INTEGRATION branch. If you want to look into it, | checkout the LIBGLADE_INTEGRATION branch and see how you go. I have fixed that (I am currently working on glade-2 file loading so that glade-2 users can use glade-3 immediately when it's ready), changes have not been committed though. Handling tab-label is not the complete solution. As GtkNotebook accepts any GtkWidget as the tab label, that might be another hierarchy. Other widgets such as GtkFrame have similar problems. These widgets should have their own add-child-functions (in glade-gtk, to keep the introspectionism of glade-3) that are able to handle these special child type. e.g. the glade_gtk_notebook_add_child() knows the special child type "tab" and add that to the notebook by a gtk_notebook_set_tab_label(). Cheers, Ivan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7XSJLISyrXd1/bsRAip3AJ9nXM1BhhoYKLZIheR+xH4z3d0OmACfQut9 6sBYESt8odB2VgCgZ+3ZjYA= =ALeq -----END PGP SIGNATURE----- From Tristan Van Berkom Thu Jan 20 19:26:59 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Thu, 20 Jan 2005 14:26:59 -0500 Subject: [Glade-devel] Re: libglade vs glade for dialog generation In-Reply-To: <20050120173747.0f4c3807.gtk@spamkiller.bytechase.cx> References: <41E7B95F.9000902@itxolutions.com> <560259cb050114070237e7f73b@mail.gmail.com> <20050119133752.0a65fadd.gtk@spamkiller.bytechase.cx> <200501191726.00159.zen18864@zen.co.uk> <20050120173747.0f4c3807.gtk@spamkiller.bytechase.cx> Message-ID: <560259cb050120112619b4c1b5@mail.gmail.com> On Thu, 20 Jan 2005 17:37:47 +0100, Gus Koppel wrote: [...] > Let me briefly sum up, again. Using libglade + XML file instead of Glade > generated code means, you > - have more external library dependancies, therefore > - have higher disk space consumption > - have greater installation package if it's to be self-contained This is definitly a point to take into consideration when one is managing their own embedded distro, we at touchtunes still prefer to use libglade because it allows us to update skinsets seperatly from the code and basicly keep the code clear. But fair, its a potentialy unnescisary framework for a given context. > - have higher RAM conumption at application execution time Only at startup time afaik; Unless your talking about the actual code segments in memory. I'm not an expert on OS's but doesn't the OS usualy handle that nicely ? > - have lower application execution speed (dialog open delays) Why would you create your dialog from the xml more than once in the application ? Do you have such a complex dialog that its inacceptable to just hide and keep in memory ? I guess this is a question one has to ask whether you are hardcoding it or not. > - should write extra conviencience funtions to compensate libglade's > deficencies. Here I really dont follow, libglade hardly needs any adjustments to support new features in gtk, whereas when writing code generation segments, all that code has to be written by hand. Now as for a something like "export plugins" solution, I agree with Todd that its probably the way to go, Implementing a smart plugin interface for that purpose doesn't scare me; the whole distribution process might be a hassle but thats not so bad. Cheers, -Tristan PS: By now this really does belong on the glade list, please excuse the evil cross-post Heres a link the the beginning of the thread for anyone on glade-devel that didn't catch this thread on app-devel: http://mail.gnome.org/archives/gtk-app-devel-list/2005-January/msg00148.html From h.lai@chello.nl Thu Jan 20 19:59:15 2005 From: h.lai@chello.nl (Hongli Lai) Date: Thu, 20 Jan 2005 20:59:15 +0100 Subject: [Glade-devel] Re: libglade vs glade for dialog generation In-Reply-To: <560259cb050120112619b4c1b5@mail.gmail.com> References: <41E7B95F.9000902@itxolutions.com> <560259cb050114070237e7f73b@mail.gmail.com> <20050119133752.0a65fadd.gtk@spamkiller.bytechase.cx> <200501191726.00159.zen18864@zen.co.uk> <20050120173747.0f4c3807.gtk@spamkiller.bytechase.cx> <560259cb050120112619b4c1b5@mail.gmail.com> Message-ID: <41F00D93.5090008@chello.nl> Tristan Van Berkom wrote: >Let me briefly sum up, again. Using libglade + XML file instead of Glade >generated code means, you >- have more external library dependancies, >- have higher disk space consumption >- have greater installation package if it's to be self-contained Statically link to libglade. libglade isn't that big. And one can write a script/program to convert the bytes in the XML file to a C array, similar to gdk-pixbuf-csource. Then you tell libglade to parse the XML file from a variable instead of from a file. > - have higher RAM conumption at application execution time I really doubt that matters compared to the rest of the app or the desktop. libglade apps run fine even on my Pentium 166 48 MB RAM. You can free the GladeXML object once the widgets have been created. From bighead@users.sourceforge.net Thu Jan 20 20:33:52 2005 From: bighead@users.sourceforge.net (Archit Baweja) Date: Thu, 20 Jan 2005 15:33:52 -0500 Subject: [Glade-devel] Re: Glade integration in Anjuta In-Reply-To: <1106226665.20333.69.camel@db1> References: <1106226665.20333.69.camel@db1> Message-ID: <1106253232.18190.0.camel@debian> Hi Naba, Looks sweet man :-) btw, long time man! How have you been? Regards, Archit On Thu, 2005-01-20 at 18:41 +0530, Naba Kumar wrote: > Hi all, > > I am not sure where is the proper mailing list to discuss glade-3 > related developments, so I am sending it to all of you :-). Please feel > free to point me to the correct mailing list. > > As we keep on getting many requests, I have been thinking a lot about > Glade[-3] integration in Anjuta and recently did some work to get it > working. > > Please see the following screenshot: > http://www.anjuta.org/screenshots/anjuta-2.0/anjuta-2.0.0-shot3.png > > (More about Anjuta 2.0: http://www.anjuta.org/wiki/index.php/Anjuta2) > > The requirement for such integration from Anjuta side is to have a > library that can allow re-construction of the glade UI. The framework is > such that we will have glade plugin in Anjuta that will install glade in > Anjuta shell. > > For glade-3, this basically means: > > 1) Segregating UI and application engine. > 2) Creating a library for the engine (I called it libgladeui, but feel > free to suggest a better name). > 3) glade application specific UI in glade-3 executable. > > glade-3 code is already nicely organized, so I had little difficulty in > doing the above. The only place I have to massively fix was > glade-project-window.[h,c]. > > Here is a patch and some new files that takes care of the above things. > > Originally, glade-project-window was a global app thingy. Now, I have > made it into a proper gobject class (derived from GladeApp, see below). > This class is now only the UI parts of glade that goes in the > executable. In a way, we can say it provides a UI for the > GladeApp/libgladeui engine in form of glade-3 program. > > I also introduced GladeApp class which basically separates the > UI-independent codes from glade-project-window, such as various project > related codes and overall functioning of glade. It, therefore, > represents the "engine" part and goes in the libgladeui library (along > with the rest of codes). > > The introduction of GladeApp was necessary to present a functioning > layer to the remaining codes while at the same time allowing having any > arbitrary GladeApp derived UIs. > > I also introduced some glade_default_app_* functions to make rest of the > codes feel minimal effect from this change -- kind of a wrapper for > earlier global app object. > > The changes does not affect the overall glade-3 functioning, so glade-3 > should just continue working like it used to before. > > One issue I can anticipate in this patch is windows specific bugs. > Someone with better knowledge, please see if there is anything that > should be done for win builds. > > Thanks and comments are welcome. > > Regards, > -Naba > From Tristan Van Berkom Fri Jan 21 15:58:03 2005 From: Tristan Van Berkom (Tristan Van Berkom) Date: Fri, 21 Jan 2005 10:58:03 -0500 Subject: [Glade-devel] Re: Glade integration in Anjuta In-Reply-To: <1106226665.20333.69.camel@db1> References: <1106226665.20333.69.camel@db1> Message-ID: <560259cb050121075811cfb90@mail.gmail.com> On Thu, 20 Jan 2005 18:41:05 +0530, Naba Kumar wrote: > Hi all, > > I am not sure where is the proper mailing list to discuss glade-3 > related developments, so I am sending it to all of you :-). Please feel > free to point me to the correct mailing list. > > As we keep on getting many requests, I have been thinking a lot about > Glade[-3] integration in Anjuta and recently did some work to get it > working. > > Please see the following screenshot: > http://www.anjuta.org/screenshots/anjuta-2.0/anjuta-2.0.0-shot3.png > > (More about Anjuta 2.0: http://www.anjuta.org/wiki/index.php/Anjuta2) > > The requirement for such integration from Anjuta side is to have a > library that can allow re-construction of the glade UI. The framework is > such that we will have glade plugin in Anjuta that will install glade in > Anjuta shell. Hi, As you probably know; glade-3 is having some issues that have to be dealt with before anything can really be distributed, namely glade file saving mechanism. As you've noticed, the bulk of glade-3 development has been emerging on the LIBGLADE_INTEGRATION branch and it makes no sence for me to apply major patches to HEAD ATM. As people in general are feeling hesitant to include file saveing in libglade I fear that we will have to write our equivalent in the glade-3 codebase (it turns out that it was a little more complicated than we thought, although that should be expected because its always the case ;-) In light of the situation; I think the appropriate course of action is to apply the anjuta changes to LIBGLADE_INTEGRATION (as you pointed out on irc, it doesn't change much for your patch) and then turn our focus to the libglade modifications that we are depending on. Right now that means: - Reconsidering the parser sharing aproach - Getting at least the other changes in (i18n'ness & non-widget objects) For that it would really be best if we could all have a meeting and sort this out with James. Unfortunatly, that might not be fast enough for your beta release... I dont really know what to say about that (and I wouldn't really call glade-3 beta material yet either, the core codebase is rock-solid IMO, only there are alot of annoying loose ends, like composite widget dialogs that are a true pain to deal with). Cheers, -Tristan From kh_naba@gmx.net Fri Jan 21 18:25:43 2005 From: kh_naba@gmx.net (Naba Kumar) Date: Fri, 21 Jan 2005 23:55:43 +0530 Subject: [Glade-devel] Re: Glade integration in Anjuta In-Reply-To: <560259cb050121075811cfb90@mail.gmail.com> References: <1106226665.20333.69.camel@db1> <560259cb050121075811cfb90@mail.gmail.com> Message-ID: <1106331942.14648.22.camel@anjuta> Hi Tristan, On Fri, 2005-01-21 at 21:28, Tristan Van Berkom wrote: > As you've noticed, the bulk of glade-3 development has been > emerging on the LIBGLADE_INTEGRATION branch and it makes > no sence for me to apply major patches to HEAD ATM. > Okay. I had no idea about LIBGLADE_INTEGRATION brach before so the patch was created from HEAD. > In light of the situation; I think the appropriate course of action is to > apply the anjuta changes to LIBGLADE_INTEGRATION (as you pointed > out on irc, it doesn't change much for your patch) and then turn our > focus to the libglade modifications that we are depending on. > Okay, I guess that means I should commit the patch in the branch. > Unfortunatly, that might not be fast enough for your beta release... > I dont really know what to say about that (and I wouldn't really call > glade-3 beta material yet either, the core codebase is rock-solid IMO, > only there are alot of annoying loose ends, like composite widget dialogs > that are a true pain to deal with). > That's fine. Anjuta beta release is just The Plan (tm). I am not even sure anjuta can make it either, but the point is to keep sticking on to it :-). Glade doesn't have to be released along with it, as the plugin will be conditionally compiled for now. I just wanted to have the option to demonstrate it to people interested in it. Thanks. Regards, -Naba From kh_naba@gmx.net Sat Jan 22 08:39:29 2005 From: kh_naba@gmx.net (Naba Kumar) Date: Sat, 22 Jan 2005 14:09:29 +0530 Subject: [Glade-devel] Re: libglade vs glade for dialog generation In-Reply-To: <560259cb050120112619b4c1b5@mail.gmail.com> References: <41E7B95F.9000902@itxolutions.com> <560259cb050114070237e7f73b@mail.gmail.com> <20050119133752.0a65fadd.gtk@spamkiller.bytechase.cx> <200501191726.00159.zen18864@zen.co.uk> <20050120173747.0f4c3807.gtk@spamkiller.bytechase.cx> <560259cb050120112619b4c1b5@mail.gmail.com> Message-ID: <1106383169.3440.23.camel@anjuta> Hi, On Fri, 2005-01-21 at 00:56, Tristan Van Berkom wrote: > Now as for a something like "export plugins" solution, I agree with Todd > that its probably the way to go, Implementing a smart plugin interface for > that purpose doesn't scare me; the whole distribution process might be > a hassle but thats not so bad. > May be the code generation plugin belongs to IDEs and should not be in glade? Regards, -Naba From vesuri@jormas.com Fri Jan 28 23:21:00 2005 From: vesuri@jormas.com (Vesa Halttunen) Date: Sat, 29 Jan 2005 01:21:00 +0200 Subject: [Glade-devel] GNOME Bugzilla 160264 (GtkFileChooserDialog internal children are not built correctly) Message-ID: <1106954460.3409.6.camel@pc.vesuri.net> Hello, could someone please take a look at bug #160264 in GNOME Bugzilla? It has been there for quite some time now and it doesn't seem to get any attention... http://bugzilla.gnome.org/show_bug.cgi?id=160264 The bug report includes a very simple test case - tar jxf attachment36666.tar.bz2 ; cd gladetest ; make ; ./gladetest should be enough to verify that the bug exists. It also includes a trivial one line patch to fix the problem. Someone with more knowledge about libglade internals should check that it's OK to fix it like that though but it works for me just fine. Thanks, -Vesa -- From damon@karuna.uklinux.net Mon Jan 31 18:43:14 2005 From: damon@karuna.uklinux.net (Damon Chaplin) Date: Mon, 31 Jan 2005 18:43:14 +0000 Subject: [Glade-devel] Glade 2.9.0 available Message-ID: <1107196994.2917.2.camel@Eternity> I've put Glade 2.9.0 up at: http://ftp.gnome.org/pub/GNOME/sources/glade/2.9/ Glade 2.9.0 (Jan 31 2005) =========== This is the first beta release for GTK+ 2.6 and GNOME 2.10. o Added support for new widgets - GtkMenuToolButton, GtkCellView, GtkIconView, GtkAboutDialog and GtkFileChooserButton. o Added support for new properties - "GtkLabel::ellipsize", "GtkLabel::width_chars", "GtkLabel::single_line_mode", "GtkLabel::angle", "GtkComboBoxEntry::add_tearoffs", "GtkComboBoxEntry::has_frame", "GtkComboBoxEntry::focus_on_click", "GtkComboBox::add_tearoffs", "GtkComboBox::focus_on_click", "GtkTreeView::fixed_height_mode", "GtkTreeView::hover_selection", "GtkTreeView::hover_expand", "GtkProgressBar::ellipsize", "GtkImage::icon_name", "GtkImage::pixel_size", "GtkWindow::icon_name", "GtkWindow::focus_on_map". Damon