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
Re: Problem about secondly run gtkdoc-mkdb
cee1 schrieb:
2009/8/3 Stefan Kost enso...@hora-obscura.de
cee1 schrieb:
2009/8/2 Stefan Kost enso...@hora-obscura.de
hi,
cee1 schrieb:
Hi all,
I'm using gtk-doc(1.11) to manager documents of my small project. I
encounter some problems like: ../xml/foo.xml:161: parser error :
Entity
'ast' not defined, when secondly running gtk-doc.
The steps are:
1) gtkdoc-scan --module=foo --source-dir=../../foo
--ignore-headers=a.h
b.h
2) gtkdoc-mkdb --module=foo --source-dir=../../foo --output-format=xml
--expand-content-files= --main-sgml-file=foo-docs.sgml --sgml-mode
--output-format=xml --ignore-files=a.c b.h
...
Are you using the normal gtkdoc.make included in your makefile?
Yes.
I find in the second time, gtkdoc-mkdb generates XML files missing the
following:
?xml version=1.0?
!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.3//EN
http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd
The doctype is copied if the foo-docs.sgml or foo-docs.xml main document
has it.
Is the project publicly available somewhere?
If the foo-docs.sgml already exists, rerunning gtkdoc-mkdb will generate
doctype-missing XML files, hence cause the ../xml/foo.xml:161: parser
error
: Entity 'ast' not defined.
How come it does not exist earlier? gtkdoc creates a template on the very
first
run, but you need to edit that to suit you and add it to your version
control
system.
After first run gtk-doc, the foo-docs.sgml is there. Re-run gtkdoc-mkdb
will generate doctype-missing XML files, unless delete the foo-docs.sgml.
The same problem exists in glib, when I do:
1) In the top-level directory of glib, run ./autogen.sh --enable-gtk-doc
2) cd docs/reference/glib# could see the glib-docs.sgml is shipped
with glib
3) make # check files in XML directory, they
are missing the doctype
4) rm -f glib-docs.sgml make clean make
5) now check files in XML directory, they are OK.
I had no time to try myself. If the generated foo-docs.sgml has no DOCTYPE in
the header, just add it yourself. Or try adding --output-format=xml to
MKDB_OPTIONS in your Makefile.am for the docs.
I had a quick look at the sources though and it needs a fix. If there is no
foo-docs.{sgml,xml} we add a xml DOCTYPE to add generated files, but generate
the main document as sgml. Please file a bug to bugzilla.gnome.org.
Stefan
Could you also try with gtk-doc from git.gnome.org - I'd like to release
1.12 in
september, would be good to see if its already fixed? Unfortunately I'll be
on
vacation starting from tomorrow, so I won't be able to reply in august
anymore.
Hopefully someone else on the list can help.
Stefan
OK, thanks any way.
The project is not public yet, since the documents not ready.
Stefan
Any suggestions?
Thanks.
___
gtk-doc-list mailing list
gtk-doc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-doc-list
Re: Problem about secondly run gtkdoc-mkdb
I've edited the foo-docs.sgml, following the glib style:
!ENTITY bar1 SYSTEM xml/bar1.xml
!ENTITY bar2 SYSTEM xml/bar2.xml
...
, and then reference not include them. The problem can be avoid.
2009/8/3 Stefan Kost enso...@hora-obscura.de
cee1 schrieb:
2009/8/3 Stefan Kost enso...@hora-obscura.de
cee1 schrieb:
2009/8/2 Stefan Kost enso...@hora-obscura.de
hi,
cee1 schrieb:
Hi all,
I'm using gtk-doc(1.11) to manager documents of my small project. I
encounter some problems like: ../xml/foo.xml:161: parser error :
Entity
'ast' not defined, when secondly running gtk-doc.
The steps are:
1) gtkdoc-scan --module=foo --source-dir=../../foo
--ignore-headers=a.h
b.h
2) gtkdoc-mkdb --module=foo --source-dir=../../foo
--output-format=xml
--expand-content-files= --main-sgml-file=foo-docs.sgml --sgml-mode
--output-format=xml --ignore-files=a.c b.h
...
Are you using the normal gtkdoc.make included in your makefile?
Yes.
I find in the second time, gtkdoc-mkdb generates XML files missing
the
following:
?xml version=1.0?
!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.3//EN
http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd
The doctype is copied if the foo-docs.sgml or foo-docs.xml main
document
has it.
Is the project publicly available somewhere?
If the foo-docs.sgml already exists, rerunning gtkdoc-mkdb will
generate
doctype-missing XML files, hence cause the ../xml/foo.xml:161: parser
error
: Entity 'ast' not defined.
How come it does not exist earlier? gtkdoc creates a template on the
very
first
run, but you need to edit that to suit you and add it to your version
control
system.
After first run gtk-doc, the foo-docs.sgml is there. Re-run gtkdoc-mkdb
will generate doctype-missing XML files, unless delete the foo-docs.sgml.
The same problem exists in glib, when I do:
1) In the top-level directory of glib, run ./autogen.sh --enable-gtk-doc
2) cd docs/reference/glib# could see the glib-docs.sgml is
shipped
with glib
3) make # check files in XML directory,
they
are missing the doctype
4) rm -f glib-docs.sgml make clean make
5) now check files in XML directory, they are OK.
I had no time to try myself. If the generated foo-docs.sgml has no DOCTYPE
in
the header, just add it yourself. Or try adding --output-format=xml to
MKDB_OPTIONS in your Makefile.am for the docs.
I had a quick look at the sources though and it needs a fix. If there is no
foo-docs.{sgml,xml} we add a xml DOCTYPE to add generated files, but
generate
the main document as sgml. Please file a bug to bugzilla.gnome.org.
Stefan
Could you also try with gtk-doc from git.gnome.org - I'd like to
release
1.12 in
september, would be good to see if its already fixed? Unfortunately I'll
be
on
vacation starting from tomorrow, so I won't be able to reply in august
anymore.
Hopefully someone else on the list can help.
Stefan
OK, thanks any way.
The project is not public yet, since the documents not ready.
Stefan
Any suggestions?
Thanks.
___
gtk-doc-list mailing list
gtk-doc-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-doc-list
Creating a new back-end for Pango
Hi, I'm trying to port Pango to the iPhone. The iPhone doesn't have ATSUI, but instead uses UIFont, which is a subset of the OS X's Cocoa Text system. And due to iPhone's memory size restraints, I'm trying to avoid including Cairo into the mix and draw directly with Core Graphics (which is what Cairo uses anyways). Do you guys have any pointers on what classes need subclassing, and what hooks are available in Pango to include a new backend? Any help would be much appreciated. Thanks! -James Hu ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: How can you ship with new libraries?
Hi, Am Donnerstag, den 23.07.2009, 11:59 -0500 schrieb Damian Frank: I'm sorry if this seems like a poorly targeted or researched question, but I can't find any information on this and I'm not sure where to look. This is indeed not the right place. But I don't know what the right place would be either. This is more a matter of accumulated experience and understanding the motivation behind fundamental design decisions. I want to ship an application with recent versions of pango and cairo, but it's important to me not to be dependent on platforms that include those libraries. On Linux, for instance, I want to support distributions at least as old as Centos 4.7. On Windows, this has been somewhat straightforward; once built, throwing all the DLLs together and loading them at runtime just works. Well, let's just say that this Windows feature comes at a price. But you are right that it is easier to do that sort of thing on Windows. On Linux, however, I am about to rip my hair out from the dependency problems; It is not impossible, but you will probably be either gray or bald in the end. In a nutshell, concerted distribution upgrades are the Linux answer to the dependency problem. The custom to ship and install any dependencies with the application itself is the Windows answer. I hope you have a choice... otherwise, good luck. You will be mostly on your own. Anyway, I think what I really want to know is, how on earth do people ship binary applications on Linux with specific versions of pango and cairo, i.e. without depending on the distribution? What's the best practice here? Easy. They don't, and it is generally not considered good practice. --Daniel ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
GTK+ compilation should work with automake = 1.7
Hello, I tried to compile Gtk+ with new versions of automake (1.10 and 1.11) and it worked without any problem. It would be great hear your experiencies compiling gtk+ with newer automake versions. I've filled a bug here [1] to track the progress. Regards [1] http://bugzilla.gnome.org/show_bug.cgi?id=588788 -- Javier Jardón Cabezas ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: csv (comma separated value) file
On Mon, 3 Aug 2009, Paolo Bacchilega paolo.bacchil...@libero.it wrote : 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 And for extra fun, I've recently had to handle a CSV format where the first line was: CSV version 2,.,*,, when generated in the UK and: CSV version 2;,;*;; when generated by our Italian customer. And yes, that does mean that the Italian version used ; as the separator and , for the decimal place, rather than , for the separator and . for the decimal. It also means that both versions use for quoting, and a line beginning with * is a comment. The tool reading this file is expected to deduce the correct format from that first line. -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Windows NT crashed. message are purely | I am the Blue Screen of Death. my opinion. Don't| No one hears your screams. believe a word. | ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib::IO-add_watch - file descriptor got locked till the end of all incoming data
Solved, I just put a new line to set the end of line and it works :), i cant
use sysread because i doesnt know the length of the input each time.
On Sun, Aug 2, 2009 at 7:34 PM, muppet sc...@asofyet.org wrote:
On Aug 2, 2009, at 3:03 AM, anguila wrote:
I want to update a treeview and this is the reason why i'm using the
add_watch function. The child is sending data all the time for many reasons
and the problem that i have is the file handler which have the incoming data
from child to parent. With watcher each time the child sent data the $line =
$reader must save this data in $line and call the function.
But dont know why the $reader just get locked till the end of all
$writerwrite() and then it save all those data into $line, and i dont want
that, i want to save the data of -write in $line each time child send data.
Any idea?
$watcher{$pid} = Glib::IO-add_watch($reader-fileno(), ['in',
'hup'], sub {
my ($fileno, $condition) = @_;
print -cond = $condition\n;
if ($condition 'in') {
print -reading from parent!!!\n;
$line = $reader;
Don't mix and match buffered reads and an unbuffered event watcher.
The operator will read until end of line, but the watch is based on
select(), and fires when any data is available on the file descriptor. The
end of line may not have arrived yet, and the will block until the end of
line does arrive.
You want to use sysread() here. This may involve keeping a partial string
checking to see if it contains an entire line.
--
Teeter tots are shaped like marshmallows.
-- Zella.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO-add_watch - file descriptor got locked till the end of all incoming data
On Aug 3, 2009, at 2:14 PM, anguila wrote: Solved, I just put a new line to set the end of line and it works :) If you control both sides, that's the cleanest solution. Rock. i cant use sysread because i doesnt know the length of the input each time. That's generally not a problem if the file handle is set to non- blocking; sysread() should read what's available up to the buffer size you give. -- The trees on the bus go pyoo pyoo pyoo... -- Yvonne, singing, um, something ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
