Re: C vs C++ for GTK
On Wed, 12 Dec 2007 09:26:25 -0700 Michael L Torrie [EMAIL PROTECTED] wrote: GTKmm is based on some very nice C++ abstractions around pointers, providing many of the same benefits as any managed language with pure C++. They are called smart pointers and for GUI development, they work very very well. Isn't smart pointers just a reference counting scheme? --D. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Memory debugging -- which tool?
Hello, I've written some C code which at some point seems to be trampling over memory that belongs to GTK-related stuff, which causes erratic crashed at some unrelated point much later. This is of course not a GTK issue, just a well-known phenomenon in general. I'm trying to use valgrind to track down this issue; however, this slows down my app to the point where it takes close to a minute for the GUI to start up, and then another minute to get to the crash. I've used ccmalloc with good success in the past, it has very little overhead, but it doesn't seem to support gcc-2.4.1 any more. I need something faster than valgrind. What tools do you guys use? Thanks, --D. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory debugging -- which tool?
On Dec 13, 2007 9:25 AM, Dan H [EMAIL PROTECTED] wrote: I'm trying to use valgrind to track down this issue; however, this slows down my app to the point where it takes close to a minute for the GUI to start up, and then another minute to get to the crash. I've used ccmalloc with good success in the past, it has very little overhead, but it doesn't seem to support gcc-2.4.1 any more. I need something faster than valgrind. I used to use efence, but it's valgrind all the way for me now. efence is fast but VERY memory hungry. I have a 64-bit machine now and valgrind works wonderfully well. My app needs at least 70MB of RAM on startup and that's enough for efence to run out of space on an 8 GB machine :-( valgrind is bit sluggish, but you can just go for a coffee while waiting for it to spot something. A good tip is to make a careful suppressions file so valgrind only stops your program for your errors. It makes using it much more hands-off. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Monitoring keyboard by an application in System Tray
Hi all, I want to know the procedure to monitor the keyboard for a particular key combination, by an application that sits on the System Tray. Can it be done thru' registering for signalling /callback? How is this possible in a GTK+ application? Thanks! Best Regards, Sundar Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Setting a background image for GtkCellRenderer.
Hi,
Am facing problem setting a background image to a GtkCellRenderer, trying to
set the background image for GtkCellRenderer, using the rc file,
my intention is to set a background image(a transparent one) to a cell
which is selected,
This is the part of the rc file i am using.
style sample-cellrenderer {
engine pixmap {
image {
function= FOCUS
file= sample.png
border = { 0, 0, 0, 0 }
stretch = TRUE
}
}
}
widget GtkCellRenderer style sample-cellrenderer.
can some help me through this.
Thanks,
Srikanth.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk on Embedded Device Query
Hi, I ported X11 and Gtk with X11 support on Embedded board(arm-linux). The problem I am facing now is setting the fontconfig. Because I have fontconfig and freetype libraries for X11 and I compiled Gtk with those libraries. The following error is produced when I tried to run gtkdemo application. *(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-' (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d Fontconfig warning: line 32: unknown element cachedir Fontconfig warning: line 33: unknown element cachedir Fontconfig error: conf.d, line 1: no element found (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d Segmentation fault * What I am doing is correct or not. Pls. suggest some solution for this. Thanks and Regards, Saroz ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: volume:// uri support
Am Donnerstag, den 13.12.2007, 02:07 -0500 schrieb David Zeuthen: On Thu, 2007-12-13 at 08:01 +0100, Mathias Hasselmann wrote: Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen: There's a screenshot here showing integration into Nautilus http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS style drive letters! That wish scares me. There must be a better solution than this geek style techie stuff. Why do think the URI would ever be displayed in the UI? The screenshot? (In fact, if you want to avoid implementations details like URI's leaking into the UI one way of solving that problem is to make them really ugly.) Might be true. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: volume:// uri support
On Thu, 2007-12-13 at 01:17 -0500, David Zeuthen wrote: Hey Alex, I've attached some preliminary patches to introduce a new volume:// name space. The thinking is that g_file_get_uri() will return a persistent URI if a local file is on user-visible media. (Emphasis on user-visible. As in the media is visible in the UI, e.g. computer://, Nautilus's sidebar and the file chooser). Notably files on your rootfs (which we hide in the UI) will still use file:// URI's.) For example this snippet GFile *f; f = g_vfs_get_file_for_path (/media/disk/path/to/file.txt); uri = g_file_get_uri (f); printf (uri is %s, uri); f = g_vfs_get_file_uri (volume://name=davidz%20data;uuid=1234/path/to/file.txt); uri = g_file_get_path (f); printf (path is %s, uri); will print volume://name=davidz%20data;uuid=1234/path/to/file.txt /media/disk/path/to/file.txt Its sort of neat, but just automatically doing this for all file uris will cause a lot of grief, with apps not being able to load local files etc. If we really do something like this it really has to be optional somehow to the apps. Also, I don't think this should be in libgio itself. Its really something that would be part of the unix desktop and not something that makes sense on other platforms. So, this should go into gvfs. Implementation-wise there's little to no overhead except that - g_vfs_get_file_from_uri() may block the very first time it's called with a volume:// URI since it needs to construct a GVolumeMonitor object - ditto for g_file_get_uri() I don't think these are real problems; we already block for GDaemonFile all the time IIRC. Other notes: On the contrary, this is a huge problem. GFile was very deliberately designed to be a low-overhead object. Constructing, walking and checking aspects of GFiles should *never* do I/O itself, only actual I/O operations should. It is for all means and purposes a refcounted path/uri string. Furthermore, you actually construct a GVolumeMonitor in each process. This will mean all processes start monitoring /etc/mtab (possibly even polling it if monitoring is not availible). Not only is this heavy, but there is no guarantee that it will work, as it requires much more of the app using gio than a mere sync I/O operation, such as a running mainloop, which may not be true. Take your g_local_file_get_uri_scheme() change for instance, for each call it does a stat-walk of its parents to find the mount, reads /etc/mtab and tries to look for the mountpath. Then you made g_local_file_has_uri_scheme() call this (adding an extra memory allocation on this fast path even though this call was added in addition to get_uri_scheme() just to avoid that). Now, this function is called all over nautilus to check if things are in the trash, on the desktop or whatever, and they are expected to be fast non-io operations (in nautilus *all* i/o operations should be explicitly async). This is gonna murder performance... GDaemonFile never fully resolves its mountpoints until an actual i/o operation is run, so it doesn't run in to this. Or, actually, this is not strictly true, as I had to add a single get_mount_info_sync() call to g_daemon_file_get_path to support the fuse stuff. But this is only done once per gvfs mount, on the i/o first operation (or get_path) and it never happens for local files. So while non-ideal its not as much of a problem it could be. - We probably want g_volume_monitor_get() to keep around a ref to the singleton when it's called and release that ref, say, 5 seconds later via a timeout. This is to avoid constructing and tearing down volume monitors all the time. Thoughts? There is no guarantee that a timeout will be called at all. For sync calls there might not even be a mainloop. (Think of for instance a commandline app like gvfs-ls.) You just can not use the volume monitor to implement sync I/O calls, it is designed for implementing a UI. Now, this doesn't mean the entire idea has to be given up. We just need to realize the fact that creating a volume: uri from a file: uri is an I/O operation, and we cannot hide it in the non-I/O parts of GFile. Once you've made this observation everything get much easier. No changes are necessary for the local file implementation, we just have to add a single i/o operation to create a persistant reference GFile object (g_file_make_persistant_reference()?), and implement that. Your volume: implementation is really not platform native native, and as such should live in gvfs, not libgio. This means that it has to be implemented by the gvfs loadable module, like the hal volume monitor. When handling such a volume: uri there is no need to do any I/O for construction, get_uri_scheme, get_uri, get_child, etc. All you need to do is textual path work, and then only at the time an actual I/O operation happens you resolve the uuid and either call the local file implementation (via g_vfs_get_local() or return a
Re: GIO API review
On Wed, 2007-12-12 at 16:53 +0100, Murray Cumming wrote: On Wed, 2007-12-12 at 16:37 +0100, Alexander Larsson wrote: GAsnc*- GIOAsync* G*Stream - GIOStream* GIcon - GIOIcon G*Icon- GIOIcon* GCancellable - GIOCancellable ... I strongly oppose this. I personally prefer the naming Mitch suggests. I know from the name which sub-library the API belongs to in GLib. I don't think this is something that is all that important when you actually use the API. It certainly isn't so important that its worth (methaphorically) punching you in the face every time you read or write the symbol. If these are are all about IO and/or generally meant to be used together, I would also like them to share some namespace. If glib doesn't do it then I'll probably do it when I wrap them in glibmm. But I love namespaces. If they are likely to be used separately, if they are generally meant to be self-contained then I'd be happy with just g_. They are not only about I/I really. I'd like to think of them as part of the glib module, but for technical reasons (glib doesn't link to gobject) they can't be in libglib.so. Now, some objects are clearly I/O related, but many are just peripherally related to I/O and show up in the API because they are required to express the other interfaces (like, files can have icons, so we need an icon type, but it can't go in libglib, so it must go in libgio). If we add things like GSettings to libgio (to avoid adding yet more .so's) then things look even more weird. GIOSettings? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote: Alexander Larsson wrote: On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: Hey everybody, We've been doing a GIO API review in the last couple of days and here is the list of comments and issues we've come up with: General: It seems GIO allows individual files to be included, this should be avoided like gobject does it: #if !defined (__GLIB_GIO_H_INSIDE__) !defined (GIO_COMPILATION) #error Only gio.h can be included directly. #endif Why? I know gobject does this, but I never understood why. It seems to just make build times longer. Because otherwise you get into the very same typedef and include mess we have in glib and gtk+. It makes it *very* hard to change anything type related in the future. Any addition of a new function that happens to use a new type which was not used in that header before might work fine for the library's build itdelf, but might break the build of applications that include whatever combination of headers. Clear structure of headers and types should never be traded for compile time, we also keep distinct things in distinct .c files. Why would we scatter our typedefs across our libraries, or keep certain includes in headers forever? Ok. I guess this makes sense. I'll do this. I would even argue that it makes most sense to keep all opaque typedefs in one single file and include that from gio.h and from each source file within GIO. This way you can avoid including any headers from headers at all and it makes things so *very* much easier to maintain. We changed all of GIMP to this policy a few years back and never had a single (!!!) problem related to includes ever since. I'm not sure this is all that much cleaner. But if we go with the one global header we can switch to this later as we please. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: volume:// uri support
On Thu, 13 Dec 2007 12:13:33 +0100 Alexander Larsson wrote: On Thu, 2007-12-13 at 01:17 -0500, David Zeuthen wrote: volume://name=davidz%20data;uuid=1234/path/to/file.txt /media/disk/path/to/file.txt Also, I don't think this should be in libgio itself. Its really something that would be part of the unix desktop and not something that makes sense on other platforms. So, this should go into gvfs. Not really weighing in on whether or not it should be in libgio, but I do think this is something that could make sense on other platforms. On win32 for example, say you have a computer with one hard drive partition (c:) and an optical drive (d:). You plug in a USB flash drive, and it gets mounted as e:. Then you remove that USB flash drive and plug in a different USB flash drive. It also gets mounted as e:. Then you plug in the original USB flash drive (without removing drive #2), and it gets mounted as f: this time. Any normal Windows path 'remembered' by an application for this 2nd drive is now incorrect. On Mac, you have a similar situation, though it's possible to run into it less often. MacOS X creates a folder under /Volumes/ based on the drive's volume label. You only have a problem if you have multiple drives with the same volume label. People who have more than one USB flash drive from the same manufacturer who don't change the drive label will be in trouble here, as the first drive plugged in will be /Volumes/(LABEL), and the second will be /Volumes/(LABEL)-1 and so on. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Wed, 2007-12-12 at 16:48 +0100, Mikael Hallendal wrote: 12 dec 2007 kl. 14.59 skrev Alexander Larsson: Hi, On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: A big issue is that GIO wastes namespaces massively: g_app, GAsync, g_buffered, g_cancellable, g_content, g_data, g_desktop, g_directory, g_drive, g_file, g_filename, g_filter, g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable, g_local, g_memory, g_mount, g_native, g_seekable, g_simple, g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop That's clearly too much and can be reduced. While these are not strictly namespaces (the namespace is g_), they partly clash with g_foos and g_bars we already have, or might need in the future. We stronlgy suggest to use a common g_io/GIO prefix for all functions/types in GIO. GAsnc*- GIOAsync* G*Stream - GIOStream* GIcon - GIOIcon G*Icon- GIOIcon* GCancellable - GIOCancellable ... I strongly oppose this. While gio is a separate library these are all symbols in the glib module, and while it might be a problem at times we can handle any conflict issues (since we control both libs and release them toghether). So, I don't think the problem with this is that bad. I mean, gobject doesn't call its symbols GObjectClosure, g_object_signal, GObjectValue, etc, and this has not been a problem. The big issue is that GIO wastes a lot (31) of namespaces for no purpose. While some might not make sense to put under the GIO namespace (GIOIcon might be one of these, I don't know), the main chunk of them do. The 31 number is a bit high, as a bunch of the listed things are internal only and some we could remove (as discussed in this thread, which is a good thing). Furthermore I don't think that e.g. having a GSimpleAsyncResult class grabs the whole g_simple namespace. However, it is true that there parts of the g_ namespace that are consumed by gio. However, that is true for any addition to glib or gobject too and yet we add names there. Also, even if we used a g_io_ prefix we should avoid name conflicts anyway. It would be very problematic if we had both g_icon and g_io_icon types for instance. There is no actual technical problem with using the g_ namespace in gio (as they ship in the same module we can avoid conflicts), the only danger of having the gio symbols use the g_ namespace is that we fear that this would give naming problems when we later add stuff to glib. Name conflicts would mean we would have to choose other names than what we might want, so we risk having to use worse names later. However, the proposed solution is imho far worse as it involves making all the gio names worse just to protect against the risk of having to use worse name in the future. I deeply disagree with you saying there is no purpose in using the g_ namespace for this. API design is to a very large degree about good naming. And using the g_ namespace leads to better naming: shorter names, no enforcing the io meme on types where it doesn't make sense, and a greater emphasis that these are core glib types that you should use instead of third party APIs. I think my essential problem with this is that gio is for all intents an purposes part of the abstract glib module, just as much as e.g. gobject is. The fact that technical reasons force it into a separate .so should not affect how we reason about it. The types it introduces should be thought of as core glib types. The examples you took from GObject are perfect examples of parts that are a fundamental and big part of the GObject library and got their own namespaces. I'm sure there are a bunch of those in GIO as well, however, we should really consider it several times when introducing new namespaces. Both for future and for people trying to use the library. I just picked any random symbols in gobject. No symbols in libgobject use any prefix other than g_ (all symbols are in the form of g_desciption_of_type). I think this is correct, as its part of the core API of glib, as much as I'd like to think the new libgio APIs are. Having some types in libgio have the g_io_ prefix seems even weirder, then is not even a namespace for a .so file. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Name of the utility library (Was: GIO API review)
On Thu, 2007-12-13 at 12:34 +0100, Mathias Hasselmann wrote: Am Donnerstag, den 13.12.2007, 12:17 +0100 schrieb Alexander Larsson: If we add things like GSettings to libgio (to avoid adding yet more .so's) then things look even more weird. GIOSettings? Off-topic, but random though since we couldn't find a name of the utility .so between libgobject and libgtk yet. What's about libgcore.so? I think the current plan is that the symbols would be in libgio.so, but then we can make the actual modules be separate, with their own .pc file and headers in a separate subdir. I'm not sure I like this, as I don't quite see the point of fragmenting the headers etc like that, but it does make the name of the .so an academic issue, as it hides it behind the .pc file names which is what developers see. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Name of the utility library (Was: GIO API review)
Am Donnerstag, den 13.12.2007, 12:17 +0100 schrieb Alexander Larsson: If we add things like GSettings to libgio (to avoid adding yet more .so's) then things look even more weird. GIOSettings? Off-topic, but random though since we couldn't find a name of the utility .so between libgobject and libgtk yet. What's about libgcore.so? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: volume:// uri support
On Thu, 2007-12-13 at 03:46 -0800, Brian J. Tarricone wrote: On Thu, 13 Dec 2007 12:13:33 +0100 Alexander Larsson wrote: Also, I don't think this should be in libgio itself. Its really something that would be part of the unix desktop and not something that makes sense on other platforms. So, this should go into gvfs. Not really weighing in on whether or not it should be in libgio, but I do think this is something that could make sense on other platforms. On win32 for example, say you have a computer with one hard drive partition (c:) and an optical drive (d:). You plug in a USB flash drive, and it gets mounted as e:. Then you remove that USB flash drive and plug in a different USB flash drive. It also gets mounted as e:. Then you plug in the original USB flash drive (without removing drive #2), and it gets mounted as f: this time. Any normal Windows path 'remembered' by an application for this 2nd drive is now incorrect. On Mac, you have a similar situation, though it's possible to run into it less often. MacOS X creates a folder under /Volumes/ based on the drive's volume label. You only have a problem if you have multiple drives with the same volume label. People who have more than one USB flash drive from the same manufacturer who don't change the drive label will be in trouble here, as the first drive plugged in will be /Volumes/(LABEL), and the second will be /Volumes/(LABEL)-1 and so on. What I mean is that the implementation described (using volume: uris that list the UUID and looking it up in mtab) is not really what you might want on all platforms. The idea of persistent file identifiers can be availible in the gio API, but not the modern-unix-desktop-specific implementation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMountOperation concerns
On Wed, 2007-12-12 at 12:05 -0500, David Zeuthen wrote: Hi, I've looked at the GMountOperation class today and I have some security concerns. Basically, the way I understand how it's supposed to work is that if you mount something you may need to provide credentials. Also, I understand a GtkMountOperation subclass is planned that can also fetch the credentials from gnome-keyring. That is not quite right. The gnome-keyring communication will happen in the gvfs backends. All we need from the app is to reply to some questions, like what is the user name and the password? and btw whould we save the password in the keyring?, or the ssh fingerprint changed, do you trust this new one?. This goes through a GMountOperation for two reasons: 1) We can have multiple implementations of it, for instance a console based text version and a Gtk based UI version 2) It is a way to separate out the lowlevel non-ui code from the X dependent APIs in Gtk and still be able to get good UI integration. For instance, the GtkMountOperation will know the correct parent for the authentication windows, and it can implement things like application modal password dialogs and inhibiting of cancel windows while a password is being requested. But I understand your concerns. You want a trusted path from the keyboard to the authenticating entity. I think with some work we can achieve that with the current system. Here is how it currently works: 1) App a wants to mount some gvfs volume, and the app hands gio a GtkMountOperation. 2) We wrap this mount operation in a dbus mount operation that proxies calls to/from the app mount operation to the dbus 3) We pass the object path of this wrapper to gvfs in the mount call 4) when gvfs needs to auth it calls dbus - wrapper mount op - gtk mount op - user dialog - gtk mount op - wrapper mount op - dbus - gvfs daemon The same kind of wrapper is used on the gvfs side, the backend code just sees a GMountOperation object which converts to/from dbus messages. Now, how can we extend this to add a secure channel and not change the API? One way is to make the GtkMountOperation object implement new interface like GSecureMountOperation. The gvfs mount call would notice that the passed in object implements this and call a different mount operation that somehow returns a secure channel (via fd passing or something) that gets passed into the GSecureMountOperation which spawns a setuid helper. Another alternative is to pass the channel from the GSecureMountOperation with the mount call. On the client side apps will keep doing what they used to (pass gtk_mount_operation_new() to the mount operation) and on the backend side the code would still see a GMountOperation object, it would just proxy things differently. One problem is that GSecureMountOperation probably will need to expose unix specific things (such as fd passing). But we can make this API unix-specific and since the only consumer of it is in Gtk+ and its use of it is hidden this isn't so much of a problem. So, I don't think the current API prohibits a secure authentication dialog, but it would be some work to implement. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote: Alexander Larsson wrote: It just adds new types and type relations you have to learn, and forces you to remember that you have to cast to some common class to do things like cancelling a directory monitor. It adds nothing useful to the user of the API, it just means you have to learn more and remember more. But we have casts all over the place in gobject/gtk+. And the APIs of both classes is 100% *identical*. You can't seriously argue against a common interface. In this case, having a common base class strikes me almost as a no-brainer. How would you justify having the *exactly* same API twice on two very closely related classes? I would rather argue that having to learn only *one* GMonoitor API is much more obvious and straightforward. The actual implementation details (the fact that there are subclasses at all) could be almost invisible in the public API. - two closely related classes - two identical APIs - common base class *please* :-) I don't think is so important, so sure, lets do this. However, what would the name of the base class be? GMonitor? That strikes me as a bit to generic. GFileSystemMonitor? GChangeMonitor? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Alexander Larsson wrote: On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote: Alexander Larsson wrote: It just adds new types and type relations you have to learn, and forces you to remember that you have to cast to some common class to do things like cancelling a directory monitor. It adds nothing useful to the user of the API, it just means you have to learn more and remember more. But we have casts all over the place in gobject/gtk+. And the APIs of both classes is 100% *identical*. You can't seriously argue against a common interface. In this case, having a common base class strikes me almost as a no-brainer. How would you justify having the *exactly* same API twice on two very closely related classes? I would rather argue that having to learn only *one* GMonoitor API is much more obvious and straightforward. The actual implementation details (the fact that there are subclasses at all) could be almost invisible in the public API. - two closely related classes - two identical APIs - common base class *please* :-) I don't think is so important, so sure, lets do this. However, what would the name of the base class be? GMonitor? That strikes me as a bit to generic. GFileSystemMonitor? GChangeMonitor? GFileSystemMonitor gets my vote. Unless you want to go for GIOMonitor :) -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Thu, 2007-12-13 at 14:50 +0100, Michael Natterer wrote: Alexander Larsson wrote: On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote: Alexander Larsson wrote: On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: Hey everybody, We've been doing a GIO API review in the last couple of days and here is the list of comments and issues we've come up with: General: It seems GIO allows individual files to be included, this should be avoided like gobject does it: #if !defined (__GLIB_GIO_H_INSIDE__) !defined (GIO_COMPILATION) #error Only gio.h can be included directly. #endif Why? I know gobject does this, but I never understood why. It seems to just make build times longer. Because otherwise you get into the very same typedef and include mess we have in glib and gtk+. It makes it *very* hard to change anything type related in the future. Any addition of a new function that happens to use a new type which was not used in that header before might work fine for the library's build itdelf, but might break the build of applications that include whatever combination of headers. Clear structure of headers and types should never be traded for compile time, we also keep distinct things in distinct .c files. Why would we scatter our typedefs across our libraries, or keep certain includes in headers forever? Ok. I guess this makes sense. I'll do this. Thanks :-) I forgot to mention, gobject has its common header in glib/. I'm not quite sure about this decision and I'm also not sure if saying #include glib-io.h or #include gio/gio.h is the more natural thing to do... Just for consideration. I'm for gio/gio.h. It seems more inline with all our other libraries. Only gobject does the glib-object.h thing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMountOperation concerns
On Thu, 2007-12-13 at 13:51 +0100, Alexander Larsson wrote: So, I don't think the current API prohibits a secure authentication dialog, but it would be some work to implement. Yeah, I agree. Thanks for the detailed explanation. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: volume:// uri support
On Thu, 2007-12-13 at 12:13 +0100, Alexander Larsson wrote: 1. Introduce g_file_get_stable_uri() and always make g_file_get_uri() return file:// URI's for local files Given the above, this is the only workable solution. Thanks for the detailed reply; I pretty much agree with all your points; I'll change these things and will include this in the hal patch. Btw, the volume:// URI scheme should probably be proposed on freedesktop.org too so the other VFS systems on the free desktop can benefit (with hal or udev or similar OS services available it's a walk in the park to implement). David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Hi all!, On mar, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: Hey everybody, We've been doing a GIO API review in the last couple of days and here is the list of comments and issues we've come up with: I Just wanted to raise another concern I have. Besides defining enums containing flags like GFileBlahFlags in gio, values inside these also are defined like G_FILE_BLAH_FLAGS_FOOBAR (note the _FLAGS_ in the definition) I don't think the values should specify too whether they're a flag, as the enum is already defined as a set of these, that way it'd also conform more to glib and gtk+ style. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: GFile: == g_mount_for_location should probably be g_file_mount_for_location I've changed this to g_file_mount_enclosing_volume() ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: There is no need to break the common prefix for global things: g_push_current_cancellable - g_cancellable_push_current g_pop_current_cancellable - g_cancellable_pop_current Done. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Thu, 2007-12-13 at 17:25 +0100, Carlos Garnacho wrote:
Hi all!,
On mar, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
Hey everybody,
We've been doing a GIO API review in the last couple of days and
here is the list of comments and issues we've come up with:
I Just wanted to raise another concern I have. Besides defining enums
containing flags like GFileBlahFlags in gio, values inside these also
are defined like G_FILE_BLAH_FLAGS_FOOBAR (note the _FLAGS_ in the
definition)
I don't think the values should specify too whether they're a flag, as
the enum is already defined as a set of these, that way it'd also
conform more to glib and gtk+ style.
There is actually currently some inconsistencies here:
typedef enum {
G_FILE_QUERY_INFO_FLAGS_NONE = 0,
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS = (10)
}
vs
typedef enum {
G_FILE_MONITOR_FLAGS_NONE = 0,
G_FILE_MONITOR_FLAGS_MONITOR_MOUNTS = (10)
} GFileMonitorFlags;
What do people think is the best approach here?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Test Framework Mini Tutorial
Hey All.
The following gives a mini tutorial on writing test programs for GLib
and Gtk+ with the new framework. We have a good number of example test
programs in SVN now and appreciate help from everyone in implementing
new tests.
First, we'll have a quick introduction into the main rationale on
test writing.
The main goals in writing tests are:
- In example (test) driven development (EDD or TDD), an example or test
program is written first, and then the newly used API gets implemented.
This ensures early testability and gives programmers early feedback on
their implementation.
- For untested legacy code, new tests are written to get about to be changed
code portions under automated tests to catch behavior changes as code is
changed.
- Most tests are written to ensure basic functionality checks of the code
area in change. Tests usually cannot perform comprehensive checks, but
can check for specific known to be tricky corner cases or often test a
representative subset of an API.
In general, working on code that is sufficiently under automated tests
makes programmers feel much more confident about their changes and helps
to spot errors shortly after introduction. So well tested code bases
tend to increase productivity and fun in working with the code.
The following list of steps is hopefully helpful when approaching the
implementation of a new test for GLib or Gtk+:
1) Figure a place for the test case. For this it's useful to keep in mind
that make check will traverse CWD recursively. So tests that should be
run often when glib, gdk or gtk changed should go into glib/glib/tests/,
gtk+/gtk/tests/ or gtk+/gdk/tests/. Tests more thorough or planned to
be run less frequently can go into glib/tests/ or gtk+/tests/. This is
e.g. the case for the generic object property tester in
gtk+/tests/objecttests.c. To sum up:
glib/tests/ # less frequently run GLib tests
glib/glib/tests/ # frequent GLib testing
glib/gobject/tests/ # frequent GObject testing
gtk+/tests/ # less frequently run Gdk Gtk+ tests
gtk+/gdk/tests/ # frequent Gdk testing
gtk+/gtk/tests/ # frequent Gtk+ testing
Also, not all tests need to go into an extra test binary. Building and
linking many test binaries can be quite time consuming, so linking
multiple .c files with tests into a single test binary can be advisable.
2) Write the test fixture setup and teardown code if necessary.
See e.g. ScannerFixture in glib/tests/scannerapi.c for a simple
example fixture that creates and sets up an object to be used
freshly in various different tests.
3) Implement the actual test function, possibly taking a fixture argument.
Tests should try to avoid duplicating logic or tests and often consist
of a series of calls and checks to use a component and verify its
behavior, e.g.:
string = g_string_new (first);
g_assert_cmpstr (string-str, ==, first);
g_string_append (string, last);
g_assert_cmpstr (string-str, ==, firstlast);
The current set of useful test assertions provided by GLib is:
g_assert_not_reached ();
g_assert (expression);
g_assert_cmpstr (s1, cmpop, s2);
g_assert_cmpint (n1, cmpop, n2);
g_assert_cmpuint (n1, cmpop, n2);
g_assert_cmphex (n1, cmpop, n2);
g_assert_cmpfloat(n1, cmpop, n2);
Where 'cmpop' is the compare operator, such as '==' or '='.
Of course g_error() can also be used once a test error is discovered.
Note that g_warning() will usually also abort test programs, because
tests generally run with --g-fatal-warnings enabled.
4) Verify stdout and stderr output or assert failures.
Tests can be started in a separate forked off sub process to capture
premature failure, exit status and output. Here is a sample snippet:
if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDOUT |
G_TEST_TRAP_SILENCE_STDERR))
{
g_warning (harmless warning with parameters: %d %s %#x, 42, Boo,
12345);
exit (0); // should never be triggered
}
g_test_trap_assert_failed(); // we have fatal-warnings enabled
g_test_trap_assert_stderr (*harmless warning*);
More example uses of the test_trap API can be found in:
glib/tests/testglib.c
glib/tests/scannerapi.c
glib/glib/tests/testing.c
5) Conditionalize slow or fragile tests.
While unit tests are most effective if they are fast, to allow quick
turn around times during development, slow or more thorough tests
also have their place. Test routines can be conditionalized in case
they contain fragile or slow code with the following API:
gboolean g_test_perf (); // TRUE to enable (slow) performance tests
gboolean g_test_slow (); // TRUE to execute possibly slow test code
gboolean
Re: GIO API review
13 dec 2007 kl. 12.51 skrev Alexander Larsson: Hi, On Wed, 2007-12-12 at 16:48 +0100, Mikael Hallendal wrote: 12 dec 2007 kl. 14.59 skrev Alexander Larsson: Hi, On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: A big issue is that GIO wastes namespaces massively: g_app, GAsync, g_buffered, g_cancellable, g_content, g_data, g_desktop, g_directory, g_drive, g_file, g_filename, g_filter, g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable, g_local, g_memory, g_mount, g_native, g_seekable, g_simple, g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop That's clearly too much and can be reduced. While these are not strictly namespaces (the namespace is g_), they partly clash with g_foos and g_bars we already have, or might need in the future. We stronlgy suggest to use a common g_io/GIO prefix for all functions/types in GIO. GAsnc*- GIOAsync* G*Stream - GIOStream* GIcon - GIOIcon G*Icon- GIOIcon* GCancellable - GIOCancellable ... I strongly oppose this. While gio is a separate library these are all symbols in the glib module, and while it might be a problem at times we can handle any conflict issues (since we control both libs and release them toghether). So, I don't think the problem with this is that bad. I mean, gobject doesn't call its symbols GObjectClosure, g_object_signal, GObjectValue, etc, and this has not been a problem. The big issue is that GIO wastes a lot (31) of namespaces for no purpose. While some might not make sense to put under the GIO namespace (GIOIcon might be one of these, I don't know), the main chunk of them do. The 31 number is a bit high, as a bunch of the listed things are internal only and some we could remove (as discussed in this thread, which is a good thing). Furthermore I don't think that e.g. having a GSimpleAsyncResult class grabs the whole g_simple namespace. However, it is true that there parts of the g_ namespace that are consumed by gio. However, that is true for any addition to glib or gobject too and yet we add names there. Also, even if we used a g_io_ prefix we should avoid name conflicts anyway. It would be very problematic if we had both g_icon and g_io_icon types for instance. GIcon is probably one of the examples where it makes sense to not have it under the GIO namespace. I just wanted to clarify though that it's not so much for technical reasons I suggested that we namespace a bit more carefully. For example, if we plan to never use the GAsync infrastructure for anything other than GIO there is a point to put it under the GIO namespace as it shows where it belongs and what part of GLib it is used for. It also means we can have GFooAsync later without the two getting confused with each other. The same for GCancellable and similar namespaces. Without any namespace other than g_ it gives the idea that these frameworks are used for more than one subsystem (at least to me). I don't think the shorter name argument is all that valid given that g_io_ is a very short namespace either. If that is the only reason I think we should change. Also keep in mind, I'm not suggestion that *everything* should go in under g_io_, they would have to be weighted on their own merits and GIcon which is often used as an example might be one that doesn't make sense and have use cases outside of GIO. GFile, GDrive, GVolume, GVfs are examples of namespaces that (without looking closer) strikes me as valid ones without the GIO. The namespaces themselves suggest that they have to do with the IO layer. GAsync, GCancellable, g_push, g_pop, g_loadable, g_simple are examples of namespaces that would benefit from being under the GIO name spaced as they are too generic by themselves. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Alexander Larsson wrote:
On Thu, 2007-12-13 at 17:25 +0100, Carlos Garnacho wrote:
Hi all!,
On mar, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
Hey everybody,
We've been doing a GIO API review in the last couple of days and
here is the list of comments and issues we've come up with:
I Just wanted to raise another concern I have. Besides defining enums
containing flags like GFileBlahFlags in gio, values inside these also
are defined like G_FILE_BLAH_FLAGS_FOOBAR (note the _FLAGS_ in the
definition)
I don't think the values should specify too whether they're a flag, as
the enum is already defined as a set of these, that way it'd also
conform more to glib and gtk+ style.
There is actually currently some inconsistencies here:
typedef enum {
G_FILE_QUERY_INFO_FLAGS_NONE = 0,
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS = (10)
}
vs
typedef enum {
G_FILE_MONITOR_FLAGS_NONE = 0,
G_FILE_MONITOR_FLAGS_MONITOR_MOUNTS = (10)
} GFileMonitorFlags;
What do people think is the best approach here?
I don't really see the need for adding symbols to the library to
represent 0. If there is only one flag in each of these that matters,
doesn't it make more sense to just have a boolean?
If I was writing this and used an enum to represent 0, I would use:
G_FILE_QUERY_INFO_DEFAULT
G_FILE_QUERY_INFO_DONT_FOLLOW_SYMLINKS
and
G_FILE_MONITOR_DEFAULT
G_FILE_MONITOR_MOUNTS
--
Regards,
Martyn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Mikael Hallendal wrote: I just wanted to clarify though that it's not so much for technical reasons I suggested that we namespace a bit more carefully. For example, if we plan to never use the GAsync infrastructure for anything other than GIO there is a point to put it under the GIO namespace as it shows where it belongs and what part of GLib it is used for. It also means we can have GFooAsync later without the two getting confused with each other. The same for GCancellable and similar namespaces. And in this particular example, g_async_*, there is already a clash: we have g_async_queue_* right now, which is unrelated of course. A slightly longer name to avoid confusion here would be a fairly low price to pay in terms of typing. And I don't agree that it would be harder to read code with slightly longer names, on the contrary, at least when the added part is reasonably long. If it's clear what subsystem the function is related to, the developer doesn't have to stop to think. /Richard -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk on Embedded Device Query
On Dec 13, 2007 11:18 AM, Saroj Kumar [EMAIL PROTECTED] wrote: Hi, I ported X11 and Gtk with X11 support on Embedded board(arm-linux). The problem I am facing now is setting the fontconfig. Because I have fontconfig and freetype libraries for X11 and I compiled Gtk with those libraries. The following error is produced when I tried to run gtkdemo application. *(gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-' (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d Fontconfig warning: line 32: unknown element cachedir Fontconfig warning: line 33: unknown element cachedir Fontconfig error: conf.d, line 1: no element found (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d Segmentation fault * What I am doing is correct or not. Pls. suggest some solution for this. Thanks and Regards, Saroz On Nov 30, 2007 5:54 PM, Ross Burton [EMAIL PROTECTED] wrote: On Fri, 2007-11-30 at 17:41 +0530, Saroj Kumar wrote: Now I am planning to run gtk+ on X-server. I started hunting for X-server and found TinyX. Now how to cross-compile X-server? Is there any document on it. I downloaded X-server from Xfree86 ftp site. Plz. guide me on cross-compiling. The releases on x.org are probably preferable, as they are easier to build. I really recommend that you investigate a build system such as Poky or OpenEmbedded instead of building it all by hand, which is a *world of pain*. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk on Embedded Device Query
Hi, this mailing-list is about development of GTK+. Please don't ask questions here that about developing applications with GTK+. We have gtk-app-devel-list and gtk-list for this. Thanks. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On Dec 13, 2007 1:21 PM, Martyn Russell [EMAIL PROTECTED] wrote: I don't really see the need for adding symbols to the library to represent 0. If there is only one flag in each of these that matters, doesn't it make more sense to just have a boolean? This is not adding any symbols to the library. It merely tells the compiler to recognize some more names for 0. And using meaningful names makes the code a lot more self-explanatory. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
On 13/12/2007, Martyn Russell [EMAIL PROTECTED] wrote: Alexander Larsson wrote: On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote: Alexander Larsson wrote: It just adds new types and type relations you have to learn, and forces you to remember that you have to cast to some common class to do things like cancelling a directory monitor. It adds nothing useful to the user of the API, it just means you have to learn more and remember more. But we have casts all over the place in gobject/gtk+. And the APIs of both classes is 100% *identical*. You can't seriously argue against a common interface. In this case, having a common base class strikes me almost as a no-brainer. How would you justify having the *exactly* same API twice on two very closely related classes? I would rather argue that having to learn only *one* GMonoitor API is much more obvious and straightforward. The actual implementation details (the fact that there are subclasses at all) could be almost invisible in the public API. - two closely related classes - two identical APIs - common base class *please* :-) I don't think is so important, so sure, lets do this. However, what would the name of the base class be? GMonitor? That strikes me as a bit to generic. GFileSystemMonitor? GChangeMonitor? GFileSystemMonitor gets my vote. Unless you want to go for GIOMonitor :) There is also a third monitor that has not been mentioned in this context - the volume monitor. Looking at the code I see that it is not exactly in the same spirit as the file and dir monitors, but it might be confusing that it does not have GMonitor as base class when other monitors do... Just a thought. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
nmake .. clean :
(A short note addressed to those maintaining the .msc files to build glib/gtk using MSVC): nmake ... clean also deletes the .symbols files (at least on my Windows XP system). (apologies if this is already known) Bill Meier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
