csv (comma separated value) file
i didn't find nothing about to manage (read/write) csv files with glib do you know about something that i didn't find? otherwise i might develop it thanks in advance ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
On Mon, Aug 3, 2009 at 12:03 PM, Andrea Zagliaza...@inwind.it wrote: i didn't find nothing about to manage (read/write) csv files with glib do you know about something that i didn't find? Currently its pretty easy using g_file_get_contents()/g_strsplit() if you can have it all in ram, or using GIO and again, g_strsplit() on a per line basis if you need to stream it. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
Il giorno lun 03 ago 2009 18:45:28 CEST, Tristan Van Berkom ha scritto: On Mon, Aug 3, 2009 at 12:03 PM, Andrea Zagliaza...@inwind.it wrote: i didn't find nothing about to manage (read/write) csv files with glib do you know about something that i didn't find? Currently its pretty easy using g_file_get_contents()/g_strsplit() if you can have it all in ram, or using GIO and again, g_strsplit() on a per line basis if you need to stream it. yet in fact i developed like this for a very small project. but i wanted to recycle the code by putting/found it in a library and with a more accurate parsing; for example i cannot split by , beacause , can be inside string fields then i thought to make a more accurate function with some parameters (ex. the character separating the fields, if the first line of the file are the names of the fields, etc.) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
Tristan Van Berkom ha scritto: On Mon, Aug 3, 2009 at 12:03 PM, Andrea Zagliaza...@inwind.it wrote: i didn't find nothing about to manage (read/write) csv files with glib do you know about something that i didn't find? Currently its pretty easy using g_file_get_contents()/g_strsplit() if you can have it all in ram, or using GIO and again, g_strsplit() on a per line basis if you need to stream it. Cheers, -Tristan it's not so easy, for example the following csv file: a;b;c has only two columns, you cannot handle this case with a simple g_strsplit call - Paolo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
treeview with compact indentation?
I wonder if there's a way to produce a more compact layout for a treeview with expanders? I'd like this for a case where the treeview is in a left-hand pane, alongside stuff that the tree represents. I mean, the default looks something like this, with heading 1 expanded: heading 1 item 1 item 2 But the effect I'm looking for is like: heading 1 item 1 item 2 with the children tucked under their parent. I noticed the existence of gtk_tree_view_set_level_indentation(), but this doesn't accept a negative argument. Thanks for any suggestions. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
On Mon, 2009-08-03 at 12:45 -0400, Tristan Van Berkom wrote: [...] Currently its pretty easy using g_file_get_contents()/g_strsplit() CSV files are not just comma separated, and in some cases can have column headers and other metadata. There's also escaping. a,b,c\d,e a,b,c,d,e a;b;c,d;e You also have to deal with differing line ending conventions. It's enough of a mess that both MS Office and most other office programs today seem o use XML instead :-) Probably gnumeric has code for this, though. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: treeview with compact indentation?
On Mon, 3 Aug 2009, Allin Cottrell wrote: I wonder if there's a way to produce a more compact layout for a treeview with expanders? I'd like this for a case where the treeview is in a left-hand pane, alongside stuff that the tree represents. I mean, the default looks something like this, with heading 1 expanded: heading 1 item 1 item 2 But the effect I'm looking for is like: heading 1 item 1 item 2 with the children tucked under their parent. Duh, sorry for the noise: I just had to _not_ put the headings into a separate first column in the treeview. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
On Mon, Aug 3, 2009 at 1:21 PM, Liam R E Quinl...@holoweb.net wrote: On Mon, 2009-08-03 at 12:45 -0400, Tristan Van Berkom wrote: [...] Currently its pretty easy using g_file_get_contents()/g_strsplit() CSV files are not just comma separated, and in some cases can have column headers and other metadata. There's also escaping. a,b,c\d,e a,b,c,d,e a;b;c,d;e I see that was an uneducated comment on my part ;-) (I have been doing alot of *simple* csv parsing with glib lately that doesnt have these kind of requirements). Sorry for the noise ;-) Dont have much of an opinion if it should be in glib, we have GKeyFile wich does similar high-levelish stuff already so it might be a suitable addition. Cheers, -Tristan (interestingly my own use-case, would be a mix of both - a fixed length keyfile like header, with variable length trailing csv data). You also have to deal with differing line ending conventions. It's enough of a mess that both MS Office and most other office programs today seem o use XML instead :-) Probably gnumeric has code for this, though. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
Hi 2009/8/3 Andrea Zagli aza...@inwind.it: i didn't find nothing about to manage (read/write) csv files with glib do you know about something that i didn't find? GSF (GNOME Structured File Library)[1], which Gnumeric uses, does CSV: http://library.gnome.org/devel/gsf/stable/gsf-Text.html otherwise i might develop it 1. http://library.gnome.org/devel/gsf/stable/index.html Cheers, Joshua -- Joshua Lock ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: csv (comma separated value) file
On Mon, 2009-08-03 at 14:23 -0400, Tristan Van Berkom wrote: On Mon, Aug 3, 2009 at 1:21 PM, Liam R E Quinl...@holoweb.net wrote: On Mon, 2009-08-03 at 12:45 -0400, Tristan Van Berkom wrote: [...] I see that was an uneducated comment on my part ;-) My reply wasn't meant as a criticism, hope it didn't appear this. [...] Dont have much of an opinion if it should be in glib, we have GKeyFile wich does similar high-levelish stuff already so it might be a suitable addition. I'd rather steer people towards XML for new stuff, and for old stuff, maybe a csv library split off from gnumeric might be possible? Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Thoughts on GTK+ and CSS
On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkomt...@gnome.org wrote: [...] Ofcourse, great example - the way I would suggest implementing this is a.) we recognize the need to show itemized groups b.) we define GTK_STOCK_STYLE_ITEM_GROUP c.) we allow some customized containers define themselves as itemized groups: - Base container classes would not be itemized groups, this would obstruct the programmer - Classes like GtkButtonBox for instance could be an itemized group - or GtkMenuShell - Classes that define themselves or their children as styled widgets are always higher level composite widgets or special purpose widgets. Then, the implemented CSS style for an item group would also cover GtkBox, allowing GtkBox to be styled as an itemized group, but not be one by nature, allowing programmers to implement their own treeviews and column headers for example - and still leverage the itemized group definitions from the theme. Is that complexity really needed? Details below. [...] Is it important that the CSS subsystem have this data directly from GtkContainer ? For instance, there really is not many classes with positional data; and the positional data can vary depending on the container type, GtkBin doesnt have positional data - so would it represent much work to handle the position data only for GtkBox, GtkMenuShell and GtkToolBar instead of on the GtkContainer ? I would also expect that the nature of what the CSS subsystem is doing with a GtkTable is going to be all together different, and you probably wont want a position at all (i.e. you might want to know all the widgets that are on top, or on the left), and the position of a page in a notebook is well, entirely different ;-) I really have no idea how the css subsystem is implemented and I am probably overlooking some things; only it seems to me, if only for the sake of OO purity and api clarity; that the position property doesnt really mean anything for the GtkContainer class itself. HTML applies CSS on the DOM tree, thus positional pseudo classes like :first-child don't imply any semantics -- it's just the first element below the parent node. So I think it would be valid for containers that don't really have a notion of order (e.g. GtkFixed) to just match the first child of their internal list of children. - Rob ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
capturing interrupts from other peripherals
I am developing a GUI application for my embedded system. I have attached a keypad peripheral through RS232. I have a code to capture any interrupt coming from that keypad. But how do I propogate the interrupt to gtk GUI? I have been trying to use gtk_signal_emit., but I am facing some issues. Is there any standard method to interface Input devices other than keyboard and mouse, which gtk events can recognize? Kindly throw some light on this as I am stuck on this badly. Thanks in Advance. Karthik -- View this message in context: http://www.nabble.com/capturing-interrupts-from-other-peripherals-tp24786597p24786597.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
Bastien Nocera wrote: I could think of at least 5 types of compressions that would be useful to have without having to use a command-line tool to decompress: - gzip for anything and everything that can come from a web server (in my case, iTunes Music Store playlist parsing, or more widely, GOffice file formats) - zip for OpenOffice.org documents and Comic Books (evince) - 7zip/LZMA/Xz formats for Comic Books - Rar for the same as above Aren't there two classes of file types there ? Compression vs Archiving I mean, zip, 7z, and rar are archiving format who store files in a compressed fashion (kind of like a tar of gzipped files) so rather than just having a stream you need to have some support for archives there, and not just the compression part like gzip or bzip2... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
2009/8/3 Steve Frécinaux nudr...@gmail.com: Bastien Nocera wrote: I could think of at least 5 types of compressions that would be useful to have without having to use a command-line tool to decompress: - gzip for anything and everything that can come from a web server (in my case, iTunes Music Store playlist parsing, or more widely, GOffice file formats) - zip for OpenOffice.org documents and Comic Books (evince) - 7zip/LZMA/Xz formats for Comic Books - Rar for the same as above Aren't there two classes of file types there ? Compression vs Archiving I mean, zip, 7z, and rar are archiving format who store files in a compressed fashion (kind of like a tar of gzipped files) so rather than just having a stream you need to have some support for archives there, and not just the compression part like gzip or bzip2... I wonder if we should split this in two approaches, having gvfs modules for archives (compressed or not) and gio-loaders for compression only formats (gzip and bzip2). -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
On Mon, 03 Aug 2009 11:37:53 +0200, Steve Frécinaux wrote: I mean, zip, 7z, and rar are archiving format who store files in a compressed fashion (kind of like a tar of gzipped files) so rather than just having a stream you need to have some support for archives there, and not just the compression part like gzip or bzip2... 7zip's LZMA algorithm is implemented in xz-utils (previously called lzma-utils) in the same way as gzip and bzip2 work. Also, 7-zip itself can be used (with some limitations) in streamed mode on *nix. -- Jernej Simončič http://eternallybored.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
From: Steve Fr-23;cinaux, Date: 03/08/2009 19:38, Wrote: Bastien Nocera wrote: I could think of at least 5 types of compressions that would be useful to have without having to use a command-line tool to decompress: - gzip for anything and everything that can come from a web server (in my case, iTunes Music Store playlist parsing, or more widely, GOffice file formats) - zip for OpenOffice.org documents and Comic Books (evince) - 7zip/LZMA/Xz formats for Comic Books - Rar for the same as above Aren't there two classes of file types there ? Compression vs Archiving Archiving formats would be better supported by GVFS, wouldn't they...? Treating an archive as a virtual directory. However, zip has a few compression formats, rar compression can be applied both before and after bundling of the files (a rar solid archive is similar to a tar.gz archive). There may be some value to supporting those compression formats even without supporting the entire archive format. The compression is pretty much the hard part of handling these archives. Going the extra step further, though, the next obvious idea would be to do the same thing that gunzip does when you concatenate together a series of gzipped files - it simply returns the uncompressed content of each file sequentially. I guess, though, you still need to understand the archive format, for at least some of those formats. So I suppose some kind of archive handler would be needed to pick out the individual streams for concatenation. Given that, reading a zip file as a compressed stream could instantiate a concatenation object that sets up the appropriate archive handler and just iterates over the available files, joining the uncompressed data of each individual decompression stream together as a single continuous stream. Which would give you the option to set up the archive handler yourself and extract the one(s) you want individually. This would be a boon even for gzipped files, giving you the option to extract concatenated compressed streams individually rather than as a solid indistinguishable stream. The ability to manipulate archives as well as simple compression would be fantastic. I did at one stage need to apply a filter to the files matching a certain mask within a tgz archive. With support like that, I could uncompress the tgz, split the tar, pass through files I'm not interested in, apply the filtering to the ones I am, and then repackage and re-compress the lot on the way out, without having to mess around with spawning external commands and correctly handling the myriad of things that can go wrong. Fredderic Worried about your move? Relocation Services can do the work for you. Click Here! Relocation Services http://tagline.excite.com/fc/FgElN1gwiSlWpkKFMLvDoO0n7NxKyoB5FLHN0tUNYVebcYZiatk3W9RdaIg/___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
On Mon, 2009-08-03 at 07:58 -0400, Freddie Unpenstein wrote: From: Steve Fr-23;cinaux, Date: 03/08/2009 19:38, Wrote: Bastien Nocera wrote: I could think of at least 5 types of compressions that would be useful to have without having to use a command-line tool to decompress: - gzip for anything and everything that can come from a web server (in my case, iTunes Music Store playlist parsing, or more widely, GOffice file formats) - zip for OpenOffice.org documents and Comic Books (evince) - 7zip/LZMA/Xz formats for Comic Books - Rar for the same as above Aren't there two classes of file types there ? Compression vs Archiving Archiving formats would be better supported by GVFS, wouldn't they...? Treating an archive as a virtual directory. However, zip has a few compression formats, rar compression can be applied both before and after bundling of the files (a rar solid archive is similar to a tar.gz archive). There may be some value to supporting those compression formats even without supporting the entire archive format. The compression is pretty much the hard part of handling these archives. Going the extra step further, though, the next obvious idea would be to do the same thing that gunzip does when you concatenate together a series of gzipped files - it simply returns the uncompressed content of each file sequentially. I guess, though, you still need to understand the archive format, for at least some of those formats. So I suppose some kind of archive handler would be needed to pick out the individual streams for concatenation. Given that, reading a zip file as a compressed stream could instantiate a concatenation object that sets up the appropriate archive handler and just iterates over the available files, joining the uncompressed data of each individual decompression stream together as a single continuous stream. Which would give you the option to set up the archive handler yourself and extract the one(s) you want individually. This would be a boon even for gzipped files, giving you the option to extract concatenated compressed streams individually rather than as a solid indistinguishable stream. The ability to manipulate archives as well as simple compression would be fantastic. I did at one stage need to apply a filter to the files matching a certain mask within a tgz archive. With support like that, I could uncompress the tgz, split the tar, pass through files I'm not interested in, apply the filtering to the ones I am, and then repackage and re-compress the lot on the way out, without having to mess around with spawning external commands and correctly handling the myriad of things that can go wrong. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
On Mon, 2009-08-03 at 07:58 -0400, Freddie Unpenstein wrote: Archiving formats would be better supported by GVFS, wouldn't they...? Treating an archive as a virtual directory. We already have gvfsd-archive for some time, based on libarchive, able to handle TAR and ZIP archiving formats with GZIP, BZ2 compression, easily extendable to LZMA and XZ (available from libarchive, not yet enabled by default in gvfs). However, zip has a few compression formats, rar compression can be applied both before and after bundling of the files (a rar solid archive is similar to a tar.gz archive). Remember we can't build anything around RAR format due to incompatible licensing, except of the file-roller way (spawning external commands). I guess, though, you still need to understand the archive format, for at least some of those formats. So I suppose some kind of archive handler would be needed to pick out the individual streams for concatenation. Given that, reading a zip file as a compressed stream could instantiate a concatenation object that sets up the appropriate archive handler and just iterates over the available files, joining the uncompressed data of each individual decompression stream together as a single continuous stream. Which would give you the option to set up the archive handler yourself and extract the one(s) you want individually. This would be a boon even for gzipped files, giving you the option to extract concatenated compressed streams individually rather than as a solid indistinguishable stream. libarchive can be easily used as a filter between two streams, transparently decoding incoming data. This should be really implemented as an extension, we don't want to have another dependency in glib. P.S.: sorry for the previous empty e-mail, key shortcuts are sometimes dangerous in Evolution... -- Tomas Bzatek tbza...@redhat.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
2009/8/3 Freddie Unpenstein fredde...@excite.com: From: Steve Fr-23;cinaux, Date: 03/08/2009 19:38, Wrote: Bastien Nocera wrote: I could think of at least 5 types of compressions that would be useful to have without having to use a command-line tool to decompress: - gzip for anything and everything that can come from a web server (in my case, iTunes Music Store playlist parsing, or more widely, GOffice file formats) - zip for OpenOffice.org documents and Comic Books (evince) - 7zip/LZMA/Xz formats for Comic Books - Rar for the same as above Aren't there two classes of file types there ? Compression vs Archiving Archiving formats would be better supported by GVFS, wouldn't they...? Treating an archive as a virtual directory. From an end user perspective I can see the value in this abstraction - being able to browse into archieves, however from a developer perspective I think I would mostly find it as an annoying abstraction. I'm pretty confident that in 98%[1] of the use cases the developer needs to know that this is really about an on-disk file and not a directory. Bear in mind that I would need to do a g_file_enumerate_children() and open streams on nested URIs I get from the GFileInfos returned by the GFileEnumerator. From a programmatic perspective I like the Java approach much better. Abstracting the ZipInputStream to general archives should be trivial (and making it more GIO-stylish is also a task for the reader): InputStream rawStream = new FileInputStream(/tmp/foo.zip); ZipInputStream zip = new ZipInputStream(rawStream); ZipEntry entry = zip.nextEntry(); System.out.println(Got zip entry: + entry.getPath()); InputStream nestedStream = entry.getStream(); System.out.println(Entry contents: + nestedStream.readTheWholeBloodyStream()); // Do the zip.nextEntry() entry dance until we have read all entries -- Cheers, Mikkel [1]: And because I include arbitrary made up statistics I automatically loose this argument ;-) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: capturing interrupts from other peripherals
On 08/03/2009 09:42 AM, karthik.sreeni wrote: I am developing a GUI application for my embedded system. I have attached a keypad peripheral through RS232. I have a code to capture any interrupt coming from that keypad. But how do I propogate the interrupt to gtk GUI? Have you looked at how GTK+ propagates key input to the main loop? You probably want to do something similar. A quick look in gdk/x11/gdkevents-x11.c reveals that they are adding an event source (GSource) to the main loop. I suggest you do the same. Hth, Martin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
From: Mikkel Kamstrup Erlandsen, Date: 04/08/2009 00:22, Wrote: On Mon, 2009-08-03 at 07:58 -0400, Freddie Unpenstein wrote: Archiving formats would be better supported by GVFS, wouldn't they...? Treating an archive as a virtual directory. I'm pretty confident that in 98%[1] of the use cases the developer needs to know that this is really about an on-disk file and not a directory. Bear in mind that I would need to do a g_file_enumerate_children() and open streams on nested URIs I get from the GFileInfos returned by the GFileEnumerator. I understand this... I don't know the details, but I had a suspicion it would be a pain. However, it may be possible to abstract some of that away to return a simple list of names, or the stream corresponding to a given name...? However, zip has a few compression formats, rar compression can be applied both before and after bundling of the files (a rar solid archive is similar to a tar.gz archive). Remember we can't build anything around RAR format due to incompatible licensing, except of the file-roller way (spawning external commands). It was more an example than anything... I have heard there are licencing issues with RAR... It's the fact that the compression can be on either side of the archive structure that I thought worth bringing up... Same as for tar/(g|b)zip... You can quite conceivably have a tar archive of gzipped files. libarchive can be easily used as a filter between two streams, transparently decoding incoming data. This should be really implemented as an extension, we don't want to have another dependency in glib. That sounds fair enough... A quick glance over at libarchive, and it seems to do pretty much everything required (can't tell if it handles concatenated gzipped files). But embracing it looks like duplicating a fair chunk of functionality. I wonder if it would be better to do it over in a more GLib/GIO-esque style than trying to embrace it. GIO streams can completely replace the I/O layers at both ends of the libarchive engine, while compression and at least some of the archive format handling is done by external libraries. It really doesn't look like there's much left for libarchive to do, apart from format detection, at least as far as I could tell from my quick look over the documentation. Anyhow... Wish I'd known about libarchive a while back. I really have to practice my Google technique... :( I do, though, wish there was a compression library that was able to snapshot an in-progress compression, allowing you to rewind to a saved state and continue from there. Fredderic Toupee Find toupees to help you look your best! Click now! http://tagline.excite.com/fc/FgElN1g05cL012R3SRh8CWFbYT1xuTXgkfM2tibgFh5Lo8J77cLU8SCTbBO/___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
On Mon, Aug 3, 2009 at 3:34 AM, Robert Staudingerrobert.staudin...@gmail.com wrote: On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkomt...@gnome.org wrote: [...] [...] Then, the implemented CSS style for an item group would also cover GtkBox, allowing GtkBox to be styled as an itemized group, but not be one by nature, allowing programmers to implement their own treeviews and column headers for example - and still leverage the itemized group definitions from the theme. Is that complexity really needed? Details below. [...] HTML applies CSS on the DOM tree, thus positional pseudo classes like :first-child don't imply any semantics -- it's just the first element below the parent node. So I think it would be valid for containers that don't really have a notion of order (e.g. GtkFixed) to just match the first child of their internal list of children. I think half of that complexity is certainly needed, and the other half can be reliably introspected. For instance: a.) I think its necessary for a customized composite widget author to be able to mark a vbox as an itemized list, which directly translates to: its wrong to assume a GtkBox contains an itemized list of widgets, and its bad design to write code that tries to guess that information by casing the types in the hierarchy. b.) I think its not important to specifically have the GtkBox mark the first or last child as first or left or top, if the positional information needed to layout the contents of a GtkBox can be introspected with consistent results. Also, Christian suggested that we expose read-only child properties specifically for use in the theme engine, this would work but IMO would be equivalent to assigning some theme tag data to the child widgets of a container, i.e. it would be code written in the GtkContainer implementation dictating how the theme should handle the child widgets. Either way would work well, also, it would be possible to instead introspect the packing at runtime reliably by listing the children of a container and comparing their coordinates to eachother relative to the parent container, thus deriving virtual row/column information. The problems I see with the current gtkrc/GtkStyle is only the guesswork thats done on the classes directly, this causes apps to be written more rigidly to cooperate with the theme and I also think GTK+ application layouts can potentially be pretty complex and definitely have needs that span beyond every GtkEntry looks like this. To fix these limitations I think its necessary to add a level of abstraction across the board, that allows the application to define what is the style to be used for a widget or container and also allows the theme to define classes that suit an idea from a list of stock items that would be required to implement the base GTK+ theme. In an ideal world, only a composite/specialized widget would have some theme data defined, and a GtkButton, GtkEntry or GtkComboBox would always come out reliably naked and unthemed - unless a style has been explicitly set for that widget, or unless you place the GtkButton in an itemized list or a dialog action area, the effect of adding a GtkEntry to a spreadsheet area might be different than the effect of setting a GtkEntry to be of the style urlbar or password. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list