Re: Creating GObject/GTK bindings for language
On 03/01/2010 10:07 PM, Tristin Celestin wrote: > I apologize for being so terse. I was grasping at straws, trying to think > of a specific question regarding GTK binding to get me started. There > have been plenty of bindings to scripting languages in the past, so > I thought asking about them in general would be the quickest way to > get information about making binding. > > I would like bindings for GTK from Objective C. I originally started > to bind classes manually, starting with GList in GLib. While I know > that this will take time, if I use that method, I'll die before > I finish. I've been working on this on and off for close to two years now: http://git.xfce.org/bindings/glib-objc/ (Note that I'm currently working on the no-foundation-dep branch to remove the dependency on libFoundation in favor of using glib-ish types.) It's far from complete, has no documentation, and I'm still not completely happy with the design of the base GObject wrapper. I haven't yet worked on any automated tools for generating bindings. Not sure if it'd be all useful for you, but maybe it's worth a look as a starting point. I'd certainly be happy to collaborate if you think it's worthwhile. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO will link with -pthread soon
On 11/11/2009 08:10 PM, Ryan Lortie wrote: > libdbus links against libpthread. Hmm: $ ldd /usr/lib/libdbus-1.so.3.4.0 linux-vdso.so.1 => (0x7fff8ebff000) libc.so.6 => /lib/libc.so.6 (0x00350100) /lib64/ld-linux-x86-64.so.2 (0x0034ffa0) Although: $ nm /usr/lib64/libdbus-1.so.3.4.0 | grep 'U pthread' U pthread_cond_broadcast@@GLIBC_2.3.2 U pthread_cond_destroy@@GLIBC_2.3.2 U pthread_cond_init@@GLIBC_2.3.2 U pthread_cond_signal@@GLIBC_2.3.2 U pthread_cond_timedwait@@GLIBC_2.3.2 U pthread_cond_wait@@GLIBC_2.3.2 U pthread_mutex_destroy@@GLIBC_2.2.5 U pthread_mutex_init@@GLIBC_2.2.5 U pthread_mutex_lock@@GLIBC_2.2.5 U pthread_mutex_unlock@@GLIBC_2.2.5 U pthread_self@@GLIBC_2.2.5 It looks like the pthread subset libdbus uses is provided by /lib64/libc-2.9.so. I guess that's what you meant about things turning out ok on Linux with glibc? So can we avoid linking with libpthread entirely on Linux (in both libdbus and libgio)? (I don't particularly object to linking with libpthread in gio, but I'm curious...) -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Are Out-of-Tree Widgets Second-Class Citizens?
On 10/02/2009 12:27 PM, Paul Davis wrote: > On Fri, Oct 2, 2009 at 1:53 PM, Brian J. Tarricone wrote: >> On 10/02/2009 07:17 AM, Allin Cottrell wrote: > >>> These two responses (Cody's and Brian's) don't jive. Any more >>> clarification available? Thanks. >> >> Sure they do... Cody said apps will have to use public APIs instead of >> accessing struct members directly. I just pointed out that some things >> don't have accessor functions yet, which is a known issue, judging by >> other replies in the thread. > > I'm not buying it. One of responses indicated that "GTK" could use > struct members directly. Clearly, its not intended for apps to do > this. The grey zone are "out-of-tree widgets" ... are these GTK or > apps? they are surely neither, and the two descriptions conflict here. > hopefully either there is NO direct struct access, even for in-tree > widgets, or some mechanism for out-of-tree-widgets to break the seal, > so to speak. I think you missed what I (and others wrote). Personally, I don't care if gtk uses direct struct access or accessor functions or whatever internally. As long as there are *public* accessor functions for anything that a widget subclass needs to access, it's fine. If there are cases where an in-tree gtk widget is accessing private struct members directly, and it's something that an out-of-tree subclass might need to use, it should be made public through some sort of accessor function. But these things need to be found on a case by case basis. Morten's original email describes such a case that needs to be fixed. This isn't some grand conspiracy to thwart making rich out-of-tree widget subclasses. This is a transition period, and there are bound to be problems. If people find that GSEAL has blocked access to things they need to use, they should file a bug report, describe what they need, and, if possible, provide a patch that adds the desired API. -brian P.S. Of course, I don't speak for the gtk maintainers -- this is just my understanding of what's expected from lurking here for some time. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Are Out-of-Tree Widgets Second-Class Citizens?
On 10/02/2009 07:17 AM, Allin Cottrell wrote: > > On Thu, 1 Oct 2009, Cody Russell wrote: > >> On Mon, 2009-09-28 at 15:12 -0400, Morten Welinder wrote: >>> This is a consequence of the halfway G_SEALing that was done. >>> Insofar G_SEAL is a good idea, it should apply to GTK+ itself, >>> i.e., GtkLabel has no business messing with the internals of >>> GtkWidget, although obviously it should have access to its own >>> internals... >> >> This is part of the plan for 3.0. I think the original idea was >> that 2.18 or 2.90 would GSEAL everything, and 3.0 would actually >> remove those struct members. This obviously means that it won't >> have access to those members anymore and it will have to use >> either the public APIs or the members of private structs. > > Hmm. I had written earlier, > >>> I'm not sure if the solution Morten advocates -- namely, >>> applying the GSEAL principle internally -- is the best one, >>> although maybe it is. > > to which Brian Tarricone replied, > >> It's not even necessary. Gtk can access struct members directly >> if desired (for performance reasons, or whatever), but the API >> should expose them for subclasser use as well. > > These two responses (Cody's and Brian's) don't jive. Any more > clarification available? Thanks. Sure they do... Cody said apps will have to use public APIs instead of accessing struct members directly. I just pointed out that some things don't have accessor functions yet, which is a known issue, judging by other replies in the thread. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Are Out-of-Tree Widgets Second-Class Citizens?
On 09/28/2009 06:11 PM, Allin Cottrell wrote: > I'm not sure if the solution Morten advocates -- namely, applying > the GSEAL principle internally -- is the best one, although maybe > it is. It's not even necessary. Gtk can access struct members directly if desired (for performance reasons, or whatever), but the API should expose them for subclasser use as well. I doubt this was done "maliciously"; the hostility shown in this thread seems a bit silly to me. I imagine some of these missing bits just got lost in the shuffle in the effort to clean up the public interfaces. It's not like the gtk maintainers are unreasonable; I bet a patch to expose the needed functionality would be accepted. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libeggdbus v. libdbus-glib
On 09/22/2009 02:59 PM, Denys Vlasenko wrote: > I looked into the code just now. I wanted to check, maybe > I'm really horribly wrong? Maybe it's a beautifully > tight, slim and efficient code after all? > > This is an example I found in about 2 minutes: [...] > > These DBUS_TYPE_BYTE_AS_STRING are one-char strings. > You compare a dozen of them using strcmp. This is both slow > and bloaty. If you'd actually like to get a constructive response, you might consider being constructive yourself, rather than copping an attitude and being insulting. Maybe something along the lines of this: "I found this bit of code in file X, function Y, and I think there might be a better/faster way. Here's a patch showing what I mean." Otherwise it makes it look like you're just here to rant, which isn't exactly the best way of influencing people. Just some friendly unsolicited advice... -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
On 08/25/2009 06:04 PM, John Ralls wrote: > Thank you both for hashing this out for me. I'll persevere with getting > Webkit-Gtk to build with quartz, then. I'm not sure I agree that it's > "not that big": WebKit.framework clocks in at 78M. Presumably WebKit.framework includes WebCore. Would it be possible to build WebKit-gtk against the system WebCore (instead of bundling your own), and just distribute the WebKit-gtk "wrappers"? -brian ___ 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 07/31/2009 01:17 PM, Alberto Ruiz wrote:
2009/7/31 Brian J. Tarricone:
On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib
I'd say call it GCompressed{In,Out}putStream and have it either auto-detect
the compression type, or have a param in the API to specify from an enum (or
both). People can add support for other types of compression as time goes
on.
And expand the list of glib dependencies to the infinite?
I don't think I like such an idea at this level of the API.
Eh, they can be optional, or dlopen()ed at runtime. The API could be
flexible enough (using the existing 'extension points' architecture) to
allow people to add their own implementations for their own use, or some
interested party could bundle a set of them in another package... though
in that case the entire compressed stream class could be in a separate
library. Instead of using an enum to select the compression type, a
string identifier could be used instead (perhaps the mime type).
IMO optional deps aren't really a big deal. If people thought it'd be
useful to have one or two mandatory deps (say zlib and bzip2, for
example), that might be ok too, since they're pretty ubiquitous.
-brian
___
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 07/31/2009 01:59 PM, Mikkel Kamstrup Erlandsen wrote:
2009/7/31 Brian J. Tarricone:
On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib
I'd say call it GCompressed{In,Out}putStream and have it either auto-detect
the compression type, or have a param in the API to specify from an enum (or
both). People can add support for other types of compression as time goes
on.
The prime benefit of having dedicated classes over your approach is
having syntactically ensured that you are indeed working with GZipped
buffers. Personally I like that, but this is of course 100%
subjective.
Well, sure, but otherwise you can end up with classes for gzip, bzip2,
zip, 7zip, rar, etc. That alone is 10 extra classes, and I'm sure there
are other compression schemes people might want classes for. That
sounds messy to me.
Having a constructor for a generic class that takes a parameter for the
compression type would give you what you want, assuming it's set up so
it returns an error if the content you pass it doesn't appear to be of
the selected type.
I guess it doesn't really matter either way. You could even implement
GCompressedInputStream as a sort of class cluster that returns a
(private) subclass depending on the compression type, or have all
(public) classes be a subclass of a GCompressed{In,Out}putStream class,
and for all operations (except for construction) you'd call methods on
the superclass.
And I think there's a benefit to support format auto-detection if the
developer doesn't care what format the input is in. That's possibly a
little more difficult to do with explicit subclasses, though the
class-cluster method would still work and yet maintain separate classes
for each compression format.
-brian
___
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 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib
I'd say call it GCompressed{In,Out}putStream and have it either
auto-detect the compression type, or have a param in the API to specify
from an enum (or both). People can add support for other types of
compression as time goes on.
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
On 07/12/2009 01:02 PM, Frederic Peters wrote: Alexander Larsson wrote: The client-side-windows branch has now been merged into master. The http://git.gnome.org/cgit/gtk+/commit/?id=0b586a5a change to gdkdrawable.h: @@ -100,6 +100,7 @@ struct _GdkDrawableClass void (*draw_drawable) (GdkDrawable *drawable, GdkGC*gc, GdkDrawable *src, + GdkDrawable *original_src, gint xsrc, gint ysrc, gint xdest, breaks a part of the API/ABI that is (at least) used in PyGTK: gdk.c:7243: warning: passing argument 4 of ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))->draw_drawable’ makes pointer from integer without a cast gdk.c:7243: error: too few arguments to function ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))->draw_drawable’ How should this matter be resolved ? For starters, why isn't pygtk just using gdk_drawable_draw_drawable() instead of dereferencing the class pointer? Regardless, if you check out current master, it appears that change that's causing your problem isn't there anymore (instead there's a draw_drawable_with_src function pointer that's been added to GdkDrawableClass). See http://git.gnome.org/cgit/gtk+/log/gdk/gdkdrawable.h. This was fixed 11 days ago, it seems. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On 2009/07/11 11:14, John Ralls wrote: I'm concerned, though, about how committed the gtk development team is to completing and maintaining the internal parts. There are some serious holes (pasting and drag-and-drop don't work, just as a particularly egregious example). Richard told me that he hoped that some of his former Immendio colleagues would step up, but I don't see that that's happening. I get the feeling that the quartz backend will probably end up like the win32 and (even worse) directfb backends: they'll require a few committed people to maintain them.[1] As unfortunate as it is, I think it's just fact that the non-x11 backends are second-class citizens, with only the win32 backend receiving support anywhere near the level of the x11 backend. What *would* be nice is if changes to the core of gdk get applied to all backends by the person making the change, similar to how Linux kernel developers are responsible for fixing up all API usage in drivers when they change an internal subsystem API. But of course that's not feasible sometimes due to time constraints, and the non-x11 backends may not be deemed "important enough" to warrant that kind of attention. Personally, I'm interested in the quartz backend, since I run MacOS X a not-small part of the time. I've done some work on it, though it's been very minimal... I think I've submitted a grand total of two mostly-trivial patches (one of them to cairo's quartz backend). I'd be interested in helping out more, but I can't promise any kind of time commitment. Beyond that, there is a deeper problem: Mac users expect their applications to be easily relocatable (the preferred method for installing software is a self-contained application bundle which can be dragged to and launched from any folder); many, perhaps even most, of the libraries in the GTK/Gnome universe use hard-coded paths which are established at build time. Well, as for gtk, there are probably two main options: 1. App authors bundle a gtk framework inside their app bundle. 2. We have a "blessed" framework bundle containing gtk and dependencies that gets installed to /Library/Frameworks, and apps depend on that. For #2, having relocatable gtk isn't that important, of course. While Mac users are indeed used to being able to relocate applications, there's certainly a precedent for installer .pkgs that restrict the user to installing to a particular place. Since it's not an application and gtk's existence should be mostly transparent to the user, I don't see that as being a big deal. Either way, the win32 backend (which supports both #1 and #2) has facilities for locating where in the filesystem the gtk library is located at the present time, and this is used internally to allow the user to install gtk-win32 to wherever they please, and allows app authors to bundle their apps with gtk, which could also be installed anywhere. I'd suggest looking into the win32 functions for doing this, and create OS X versions. > I realize that this is a bigger problem than just GTK Right... many (most?) apps aren't relocatable themselves since they refer to resources that may be spread all over the hard drive. Unfortunately this will require sending patches upstream per application, or patching the apps yourself (for various definitions of 'your'self) before creating a distributable package. As to a possible convention to adopt, I'd suggest keeping the 'normal' layout of packages as on a Linux system, but set the prefix so that it looks in the app bundle's Resources directory. You can either use a wrapper script to set env vars and then start the app, or have the app figure things out in gtk_init(), perhaps (things like $(localedir) will need to be figured out so translations will work, for example). I recall that the metapackage project had done some work on making relocatable packages... I'm not sure if that works on MacOS X though. Perhaps if there is a better forum to discuss it someone here will > point me at it. Not sure if there is... not sure we need yet another mailing list tho :-P -brian [1] AFAIK, there's no full-time directfb maintainer; seems like people who need it to work randomly come by and do a lot of work on it, and then disappear. I believe Tor is the only win32 contributor; at least he seems to work on it vastly more than anyone else I've ever seen. (My apologies if I've forgotten anyone!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
On 06/03/2009 05:36 PM, Paul LeoNerd Evans wrote: Yes; we messed up 30 years ago and said "k" when we meant "Ki". Oops. Sorry about that. Well, no, 30 years ago there was no "Ki". So people did the logical thing and picked the prefix that represented the correct *magnitude* of the value. Lets not do it wrong for another 30, please? "Wrong" is somewhat relative here. Things can have different meanings in different contexts[1]. -brian [1] Of course, the marketing departments of some storage media companies arbitrarily decided it could have different meanings in the *same* context too. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib uses wrong prefix for base-2 units
Benjamin Drung wrote: Hello, g_format_size_for_display uses the wrong prefixes for units that are counted in power of two. The SI defines following prefixes: k = 1000 M = 1000 k G = 1000 M ... Please use the IEC standard for binary prefixes: Ki = 1024 Mi = 1024 Ki Gi = 1024 Mi ... Oh god, let the flames begin... * It is the correct usage of the standards. True, but just because there is a standard, it doesn't mean it's a good standard. * It would avoid ambiguity and consumer confusion: http://en.wikipedia.org/wiki/Binary_prefix#Consumer_confusion Arguably, using KiB etc. in the user interface could confuse the user just as much. * The users want it. E.g. look at brainstorm: http://brainstorm.ubuntu.com/idea/4114/ http://brainstorm.ubuntu.com/idea/17839/ You mean: some vocal users of a single Linux distro want it. * The Linux kernel uses it (man units). No, the Linux man-pages project, which just happens to be hosted on kernel.org, uses it. I'm not completely against this kind of change (aside from the fact that I think "kibi", "mebi", and "gibi" sound retarded), but why change now? There are previous discussions about this: http://bugzilla.gnome.org/show_bug.cgi?id=301838 http://mail.gnome.org/archives/gnome-i18n/2007-May/msg00109.html ... that resulted in favor of leaving the prefixes as they are. What has changed in the meantime (these two discussions are 4 and 2 years old, respectively) that warrants revisiting this? Has there been new rampant widespread adoption? -brian P.S. As an aside, one could also argue to dispense with the use of the powers-of-two interpretation in user interfaces entirely. If Seagate/WD/etc. sells you a 500GB hard drive (500 billion bytes), wouldn't you expect to see "500GB" in your file manager as the full capacity (well, minus filesystem overhead)? A non-technical user wouldn't expect to see 476, regardless of whether or not it's followed by "GB" or "GiB". Aside from the (mostly irrelevant, slight) speed efficiency of doing division by 1024 via bit shifts rather than division by 1000 by actual division, what use does the powers-of-two interpretation have today? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: global menubars in GTK+
On 05/25/2009 02:04 AM, Nemes Sorin wrote: global menu bar from Usability point of view ... I am a designer interested in Man - Machine interaction. Regarding global menu in Gnome, I spent a 2 weeks using globalmenubar being curious to find in which mode my workflow will be affected (Speed ? Comfort ? ...). Well after 2 full weeks - I can tell you all - when you have a huge LCD / CRT ( you are designer or DTP guy ) global menu is not an option - because you have to cross a lot of screen areas with the mouse cursor - when is not the right case. The problem with this sort of analysis is that you're only taking into account your single use-case. What percentage of the target audience for this sort of thing has a large monitor and would be affected? I'd say you're in the minority, but without an actual usability study, neither you nor I can really comment on that. For *me*, a global menu would be great. I have a laptop with a 12" screen, 1024x768 resolution. Having a menu bar on each and every window (minus the ones where I can configure the app to hide the bar) wastes so much space, and the top of the screen is always within easy reach. With widescreens even on a mac globalmenu loose it's sense. Kinda funny you specifically mention a mac -- do people in the mac community complain about having a global menu? You'd think you would see that a lot if it really was a problem, since global menu is the only option on macos. Now imagine GIMP - you can not assign all commands with shortcuts - for any filter (I have ~ 200 filters ) which is not assigned to a shortcut, you have to cross all screen again with the mouse cursor because of the global menu bar location. Try right-clicking anywhere on your image ^_~. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: global menubars in GTK+
On 05/25/2009 09:22 AM, Yu Feng wrote: On Mon, 2009-05-25 at 20:17 +0800, Davyd Madeley wrote: OTOH, if GTK+ had API for this, a backend could be written to power the gnome2-globalmenu applet from this API. However, the reason why GGM is using GtkWidgets in favor of GtkActions is that there are plenty of programs who don't build the menus with GtkActions at all. 'It's going to break applications that do not use this API.' Otherwise using GtkUIBuilder is much less effort than the current approach. I think this is actually OK and preferred. Making the global menu only work with apps that make use of GtkAction and GtkUIManager for creating menus is yet another way to push people toward using this functionality rather than creating menus by hand "the old way." If apps don't work with the global menu, they'll get bugs filed against them by users who care (well, ok, let's be honest: some users will file the bug with the global menu itself, but I think that's inevitable). If app authors care to be compatible for their users that use a global menu, that's great. Otherwise their app will just show up with a menubar per-window as usual, and that's fine too. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Native file chooser dialog on Windows
Cody Russell wrote: On Fri, 2009-05-15 at 13:51 -0400, David Cantin wrote: I don't known about this, but from an usability point of view, using native dialog should help applications users because they can use skills they have learned while they were using others applications.. Those details are always sensibles when using a foreign gui toolkit. I will look into what Tim Evans have said. If you implement a dialog using gtk+ widgets that is laid out like the native dialog, has the same accelerators, etc.. then users can take advantage of these skills as you describe and we can use features of gtk and it will look absolutely natural in the application. The problem with this is in the details, and getting them right for various versions of Windows. If we continue to use the standard gtk file chooser widget, it looks quite a bit different, but at least it's *supposed* to be different. If you create a look-alike dialog, and it's not *perfect*, people will get thrown off. Maybe the autocomplete behavior of the entry box doesn't work *exactly* the same. Maybe one of the accelerators is wrong. Maybe the icon positioning is slightly different. Maybe the dropdown list at the top works differently. There are plenty of other examples, and they all serve to be small jarring differences that possibly end up confusing the user more than having a totally different file chooser. Having said that... creating even a close-but-not-perfect copy of the Windows file chooser still sounds like a pretty attractive option. (Does the chooser look the same on all versions of Windows if you ignore theming? Win2k? WinXP? Vista? Windows 7?) This is also an issue on MacOS X... Mac users are even more crazy about all applications fitting into the (not really standard) standard platform look and feel than Windows users are. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glist manipulation and reference count
[Note that your question is probably more appropriate for gtk-app-devel-list or gtk-list; this list is for the development *of* glib/gtk itself, not about developing apps that *use* glib/gtk.] On 05/14/2009 08:47 PM, walty wrote: However, one thing that surprised me is that, when I do "g_list_append" or "g_list_prepend", it does not automatically add the reference count of the stored GObject (unlike objective-C). GList is a generic container that you can put any kind of pointer into. It doesn't know about GObjects or reference counting. In fact libglib (where GList is implemented) doesn't even link to libgobject. So do I need to explicitly add the reference count each time the GObject is inserted? and reduce the reference count when the object is removed? That seems quite cumbersome to me. That depends on how you want to use it. If you can be sure no one else will destroy the object while you're using it in the list, then no, you don't. I've used both glib/gobject and NSArray/NSDictionary/etc., and personally I don't find either approach to be better or worse. I rarely need to increase refcnts on GObjects when I store them in lists, but perhaps others have different use cases that do require this. Or can I add some function pointer to generalize this? Is there some kind of best practice on this? If you add the objects in one shot, you can do something like this after you've added all objects: g_list_foreach(list, (GFunc)g_object_ref, NULL); Of course that iterates over the entire list, so it would be a bit slow on a large list. You can always ref the objects as you insert them, e.g.: list = g_list_append(list, g_object_ref(obj)); Of course you have to do something similar with _unref() when you remove items from the list or destroy the list. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
On Thu, 7 May 2009 23:32:05 -0400 Matthias Clasen wrote: > - Find a more suitable name for GVariant, maybe. Havoc had > 'GBinaryValue' earlier... GSerializedValue? A bit long... GFlatValue? GComplexValue? (eh.) -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Alexander Larsson wrote: On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: gvfs needs a session bus, not a system bus, so you're falling back to a non-gvfs system. Thus no http support. >> OK, I suppose I can get this working on my own system, but my main point is: why does GTK include a function such as gtk_show_uri which depends on a big stack of unspecified stuff? At least this should be mentioned in the documentation. As I said before, up till very recently one has been able to rely on GTK functions "just working" so long as the compile-time dependencies are satisfied. Thats not totally true, there are optional dependencies in gtk+ before gvfs. Things like shared memory, cups backend, etc. But, all the gio calls *do* work even with gvfs totally absent. The only thing that doesn't work is things involving non-local files, and I don't understand how you expect that to ever work without depenencies. gtk_show_uri() for instance is an excellent function to use to launch the users default app to open a specific file, based on its mimetype. It just feels like you want to have a cake (non-local file i/o) and not pay for it (supply dependencies). No, he just wants a sane default implementation. If the CUPS backend isn't compiled, the print dialog still comes up, and you can at least print to a file. A dialog that presents "Operation not supported" to the user is pretty poor, IMO. As Allin suggested, it would be nice if there was at least a default fallback implementation that tries the BROWSER env var, and if that doesn't work, tries a list of known browser binary names until one succeeds. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_get_allocation
Cody Russell wrote:
On Thu, 2008-09-25 at 02:02 +0200, Christian Dywan wrote:
* gtk_widget_get_allocation
Removed in 2.14.1
The prototype of this function was not agreed upon among the core
developers. So the decision was deferred to the next Gtk version.
It had to be removed before final API freeze, otherwise it could not
have been changed anymore.
This is rather old, but it never came up again after this so I'd like to
see what thoughts are about how to implement this in C. It was in 2.13
but removed before 2.14 because of disagreement, but I can't find any
public record of the disagreement in gtk-devel-list. Can anyone comment
on what was not liked, or how a better implementation could be made?
For reference, this is the previous implementation:
GtkAllocation
gtk_widget_get_allocation (GtkWidget *widget)
{
static GtkAllocation allocation = { 0 };
g_return_val_if_fail (GTK_IS_WIDGET (widget), allocation);
return widget->allocation;
}
I assume the issue was with returning a non-primitive type by-value and
not as a pointer. For modern compilers this isn't a big deal, I don't
think (but might be inefficient on some arches), but I imagine people
want to compile gtk on all sorts of systems. An implementation like
this avoids that problem, though perhaps isn't as nice to use[1]:
void
gtk_widget_get_allocation (GtkWidget *widget,
GtkAllocation *allocation)
{
g_return_if_fail (GTK_IS_WIDGET (widget) && allocation);
memcpy (allocation, &widget->allocation, sizeof(*allocation));
}
(Could also have it return gboolean, but I tend to think it's
unnecessary to have a success/fail return value when the only reason it
would fail is if the programmer is using the function incorrectly.)
This seems to be a similar pattern to how other things like this are
done in gtk...
-brian
[1] I guess part of the motivation for the original (rejected)
implementation is so that you can do things like this:
gint width = gtk_widget_get_allocation (widget).width;
Oh well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Cross-compiling GLib 2.18 with arm-linux.
On Fri, 27 Mar 2009 13:00:52 +0200 Felipe Contreras wrote: > 2009/3/23 John Peterson : > > Hello – I’m not sure I’ve got the right mailing list for this > > question, but I thought I’d try. > > > > > > > > I have downloaded glib-2.18.0 on Linux FC4, and am trying to > > cross-compile with an arm-linux-gcc compiler. Most of the stuff > > goes smoothly until I hit the atomic_spin_trylock in the gatomic.c > > file. > > > > > > > > This function has some embedded assembly (denoted with the asm > > keyword). The particular error that I get is: > > > > > > > > /bin/sh ../libtool --tag=CC --mode=compile arm-linux-gcc > > -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\"GLib\" > > -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION > > -DPCRE_STATIC -DG_DISABLE_SINGLE_INCLUDES -pthread -mbig-endian > > -std=c99 -Wall -MT gatomic.lo -MD -MP -MF .deps/gatomic.Tpo -c -o > > gatomic.lo gatomic.c > > > > arm-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\"GLib\" > > -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION > > -DPCRE_STATIC -DG_DISABLE_SINGLE_INCLUDES -pthread -mbig-endian > > -std=c99 -Wall -MT gatomic.lo -MD -MP -MF .deps/gatomic.Tpo -c > > gatomic.c -fPIC -DPIC -o .libs/gatomic.o > > > > gatomic.c: In function `atomic_spin_trylock': > > > > gatomic.c:570: `asm' undeclared (first use in this function) > > > > gatomic.c:570: (Each undeclared identifier is reported only once > > > > gatomic.c:570: for each function it appears in.) > > > > gatomic.c:570: parse error before "volatile" > > > > > > > > I’m guessing that my arm-linux-gcc compiler is not compatible with > > the embedded assembly directive, and that’s why I’m getting the > > error. However, I thought I’d check to see if maybe there was some > > other setting that might make this work. > > Which arm compiler are you using? I've tried with codesourcery and > scratchbox2... glib builds fine. Hell, I've built glib for ARM using gcc 2.95.3 and it's worked fine. Try removing -std=c99 from your compiler command line (or replace it with -std=gnu99 if you must). Inline assembly might be a GNU extension... I don't remember, though. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
On Sat, 14 Mar 2009 20:10:32 -0400 Morten Welinder wrote: > This is crazy. > > People are actually advocating that thousands upon thousands of > applications need to be changed. If they're behaving incorrectly, yes. But I don't think most of them are. The only case where *not* doing an fsync() turns into a problem is if you have a power failure or system crash at an inopportune time. So for many applications, that risk might be acceptable (not all files have equal value). And the funny thing is: what you think is crazy is EXACTLY what's being done here. We're adding a pre-rename fsync() to gio in the read file -> write tmp file -> rename tmp over original file case. So there's app one of those alleged thousands upon thousands that just got fixed. > Yes, POSIX allows this particular idiotic behaviour. So what? It > probably also allows free() to do nothing, yet no-one in their right > mind would want that. Actually you might in some particularly weird scenarios. free() usually causes memory fragmentation, which might not be desirable. If you have a fixed amount of RAM and fixed amount of data you're operating on, a controlled memory 'leak' might be what you want for best performance. (Hey, it's a stupid example, but your example was pretty stupid too. I figure a stupid example deserves a stupid response.) > Or maybe you would be upset if the code > fragment > > const char *s = "x"; > int i = (s+1)-s; > > formatted your hard drive. Yes, the C standard really does allow that > to happen. > (C99 section 6.5.6 #9, if you really want the details.) Sorry, dude, but now you're just not making sense. I just looked up the C99 spec[1] and read that section. it doesn't say anything about formatting your hard drive. It just talks about how pointer arith must result in well-defined values inside the object the pointer points to. Nothing new there. > The mere fact that a standard allows an idiotic implementation > doesn't mean we should play ball with it. The same standard also > allows sane implementations. Well what's idiotic and sane is a matter of opinion. A risk of file corruption in certain corner cases if you don't follow the spec, in the name of better performance seems reasonable to me -- for the right kind of app and the right kind of data. > We could litter fsync() calls all over, but... > > 1. It describes a semantic that isn't really what we want. In fact, > there is no way > to get exactly the semantics we want with POSIX. We have to ask > for the please-wait-for-the-disk semantics we don't want. That's a > sure way of getting > sluggish programs. True, in some cases. > 2. Shell scripts, Makefiles, and other languages without explicit > fsync control will > kill really you. Instead of... > > foo file.new > mv file.new file > > ...you get to write... > > foo file.new > sync > mv file.new file That's a deficiency of the shell, that it doesn't provide something analogous to fsync, not of the requirement that it must be done. > Performance might be affected. Guess what? You can't have everything. Performance and reliability are often at odds, and you need to find a trade-off you're happy with. If you have a level of reliability that you can't live with, then you may have to reduce performance to get what you want. That's life. Deal with it. > 3. Auditing and changing thousands of programs? Expect bugs. Arguably, they're already buggy for expecting behavior that isn't guaranteed. > We already break the strict letter of POSIX and the C standard in > fifty different ways. Wow, this statement is pretty useless and hand-wavy. Maybe those fifty different ways are reasonable and ok, and don't risk user data. Maybe those fifty different ways don't actually exist and you're just trash-talking. > If someone shows up with an environment that doesn't behave as we > want, we say "sorry, no ball". Just add stupid file systems to the > list. Well apparently 'we' didn't do that: ext4 came out, distros started using it by default, this issue occurred, and there's pain involved. Apparently the ext4 devs have caved to pressure and will be adding a hack to the next version of the driver to order writes to avoid this specific failure case. That's all well and good... until the next filesystem comes along and does something similar. Or even something different, but with the same effect. Again: if you don't like the spec, get it changed or amended! Then, later, when this happens again, you can clearly point a finger at the FS developer and say "yes, this really is your bug." And who knows, maybe it won't happen again if there's better behavior defined in the spec. -brian [1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
On Sat, 14 Mar 2009 13:16:45 +0100 Alexander Larsson wrote: > On Fri, 2009-03-13 at 14:34 -0700, Brian J. Tarricone wrote: > I think you are conflating two issues. No, I don't think I am. I think I'm just replying to a subset of the email that's slightly off topic. Or rather, the fact that I'm only replying to someone's assertion that the filesystem is broken and that I was ignoring the issue of gio initially made my reply a bit off topic. > 1) Should glib/gio fsync at least in the really bad data loss case to > make sure users are not losing data on such filesystem Right, I think we're in perfect agreement that this is a 'yes', though we may not agree that gio should fsync quite as often (I'd advocate to do it *only* in the rename-over-existing case, and to have the default be no-fsync everywhere else). > 2) such filesystems are broken > > Clearly the answer to 1 is yes. Anything else would be a disservice to > our users data. However, that doesn't mean such filesystems aren't > broken, in the sense that I would never let a filesystem like that > near any of my data. Well, you're certainly entitled to your opinion. Personally I don't think the filesystem is broken. It's behaving within spec. You can argue that the spec is broken, or that it specifies behavior that defies common sense, but it's there, and it's been there for quite a while, so I don't quite understand why this is suddenly such a big deal. (Well, sure I do: no one decided to use a FS that behaves like this as a distro default before, I guess.) This is, btw, why I wouldn't use XFS on a partition with data I care about. XFS was designed with priorities other than data integrity in mind. I accept that, use something else, and move on. You don't see anyone declaring XFS broken (well, at least, not anyone knowledgeable), do you? So why is ext4 broken? Because it's being touted as an ext3 replacement, I guess... > For instance, any script doing sed -i s/foo/bar/ file.conf on such a > filesystem risks ending up with a zero byte file.conf. (sed uses > rename but doesn't fsync.) Is this what users except? Should that > script be rewritten in C so it can use fsync? Should sed fsync? Yes, it should! Given the spec, if it does anything less, it's risking user data. > That > kind of reasoning will lead to all apps implementing fsync-on-close > manually, and we're then worse off than if the fs just guaranteed > data-before-metadata-on-rename. Yep, probably true. But the right move here is to get the spec changed, not say "any filesystem that follows the spec but doesn't work the way *I* think it should is broken." How is that approach at all useful in the big picture? > > Yeah, I'd totally agree. But in the absence of an ability to > > change the spec, it's best to try to make things work as well as > > they can within the spec, no? It seems like some people are > > advocating "well, today everyone uses ext3, and there's no problem, > > so we shouldn't do this because it'll reduce performance there." > > And of course, a year from now (or less! obviously some already > > are), I'm sure most desktop distros will be shipping with ext4 > > default. (And I could be wrong, but it seems to me that ext3 is > > the only FS that, by coincidence will usually be immune to this > > problem, and, also coincidentally, is one of the only FSes that has > > crappy fsync() performance.) > > ext4 from the next kernel release will have patches that makes the > rename case safe, although it will be an option that can be disabled. > Not sure about btrfs. Its unsafe at the moment, but chris mason is > talking about possible fixes in the lwn thread. That sounds pretty awful, to me, to be honest. So every FS -- no, wait -- every FS that's going to be pushed as a "mainstream" FS -- is going to have to be closely monitored to make sure it doesn't have this behavior? Everyone's going to be putting little band-aids over this issue, but only in FSes we "care about?" The underlying issue, the root cause -- that the spec allows what many consider very unsafe behavior -- is just going to be ignored? Sigh. Well, I guess I'm getting even more off topic here, so I give up. I see farther down in the replies Mark argues pretty much the same thing I am, only doing a better job of it. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Alexander Larsson wrote: On Fri, 2009-03-13 at 11:11 -0700, Brian J. Tarricone wrote: Sven Neumann wrote: It seems wrong to work around broken file-systems on the application level. That only takes away pressure from the file-system developers to address the problem properly. >> How is the file system broken? Read the man page for write(). If you want to guarantee that file data will hit disk (or at least the disk's HW buffer) by a certain time, you need to call fsync() (or fdatasync(), where available). The fact that its documented doesn't make it not broken. If you read the posix specs you'll see that its per specification for the implementation of fsync() to be empty. That's not the point I'm trying to make. It may be 'stupid' behavior, but it's at least specified. Saying "the filesystem guys should fix their filesystems to be less lame" just doesn't work, as they're compliant with the spec. So either the app developer can write their save routines to be robust *in the face of the spec*, or they can 'hope' that every new FS adopts a restriction on behavior that isn't specified anywhere, and every old FS is modified and updated to follow this fantasy restriction. Doesn't that sound a bit like unreasonable wishful thinking? Now, we don't actually really need the data to be on the disk at a certain time. On the contrary, its really fine if its delayed. But, what we want is either the old file in place, or the new file in place, not the old file deleted, the metadata for the new file and the new file being empty. Thats what is broken, even if its allowed by POSIX. Sure, but that's just a special case. So you (as the app developer) recognise this, understand how the spec interacts with your use-case, and write robust code accordingly. Or, you take the "the spec/kernel/FS is broken" approach, and try to get a guarantee specified for the special case, something like "in the case where a file is renamed over top of an existing file, the source file must be flushed to disk before the rename takes place." And then the app developer doesn't have to worry about it, because the implementation should do the right thing. Your patch to gio takes the first approach, which is fine, I think, if unfortunate in the sense that it forces behavior that may not be desired. A user of g_file_set_contents() may be writing a temp file or something that they don't care all that much about, and doing so arguably reduces performance. Of course, g_file_set_contents() is a decently high-level abstraction, so one could argue that people who want finer control over how the file gets written should use gio or open/write/close directly. This isn't a Linux idiosyncrasy, even. POSIX specifies this. The only thing that's actually broken IIRC is ext3, in that a fsync() effectively acts as a full-FS sync() (see the Firefox 3.0/sqlite fiasco[1]), which is ridiculous. If anything should be fixed, *that* should be... as well as naive applications that think that open() -> write() -> close() is sufficient to get data to disk in a known amount of time. Broken is a wider concept than you think. Things that are fully up to some well documented spec can also be broken from the point of view of common sense. Yeah, I'd totally agree. But in the absence of an ability to change the spec, it's best to try to make things work as well as they can within the spec, no? It seems like some people are advocating "well, today everyone uses ext3, and there's no problem, so we shouldn't do this because it'll reduce performance there." And of course, a year from now (or less! obviously some already are), I'm sure most desktop distros will be shipping with ext4 default. (And I could be wrong, but it seems to me that ext3 is the only FS that, by coincidence will usually be immune to this problem, and, also coincidentally, is one of the only FSes that has crappy fsync() performance.) I dunno... my vote/opinion would be to have a _SYNC flag, leave async as the default, and force _SYNC for g_file_set_contents() (maybe?) and for cases in gio where we know a rename is going to overwrite an existing file (if it's possible to know that without a perf hit). -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Sven Neumann wrote: It seems wrong to work around broken file-systems on the application level. That only takes away pressure from the file-system developers to address the problem properly. How is the file system broken? Read the man page for write(). If you want to guarantee that file data will hit disk (or at least the disk's HW buffer) by a certain time, you need to call fsync() (or fdatasync(), where available). This isn't a Linux idiosyncrasy, even. POSIX specifies this. The only thing that's actually broken IIRC is ext3, in that a fsync() effectively acts as a full-FS sync() (see the Firefox 3.0/sqlite fiasco[1]), which is ridiculous. If anything should be fixed, *that* should be... as well as naive applications that think that open() -> write() -> close() is sufficient to get data to disk in a known amount of time. (Of course, ext3 won't ever be fixed, so... I guess we wait for ext4 use to become more widespread, and for btrfs to go stable.) -brian [1] http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject Introspection as part of the GNOME platform
Johan Dahlin wrote: In my opinion, supporting cross-compilation shouldn't be a blocker for integration into glib proper. It's more of a 'nice feature' to support. As long as that means "glib will still cross-compile, just the introspection stuff gets disabled," I'm ok with that. Otherwise... yuck, that's awful. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
On Tue, 03 Mar 2009 10:55:33 +0100 Alexander Larsson wrote: > On Mon, 2009-03-02 at 22:26 +, Rob Taylor wrote: > > Brian J. Tarricone wrote: > > > Whether or not the object is local (in-process) or not is > > > irrelevant. Whether or not the method call is sync or async is > > > also irrelevant. It's a method call, pure and simple. DBus > > > itself even calls them method calls. All you're doing by > > > avoiding that in the IDL is making us learn and remember yet > > > another confusing and incompatible syntax. > > > > Wow. No. > > > > That was the main insanity of CORBA. Hiding that something is IPC > > results in you thinking things are working one way when in fact > > they're working completely differently and subject to a load of > > unexpected failure modes. > > > > Other things to consider here is that hiding IPC can also result in > > hugely inefficient IPC because you end up designing a pretty API > > rather than efficient IPC. > > > > I could rant at length here about the various benefits of CORBA vs > > message bus. But suffice to say hiding that there's a message bus > > means you end up with CORBA again and all the attendant problems. > > I very very much agree. And I had to fight these CORBA problems for > many years maintaining a bonobo based application. Please learn from > history and don't fuck up our platform again. > > This should be required reading for everyone that ever touches IPC: > http://research.sun.com/techrep/1994/abstract-29.html Ok, I'm convinced. Sorry for the noise. (That's an excellent read: short and clear, but still very thorough.) However, I'm still not convinced that the IDL for this should be some weird C-like syntax that makes everything look like messages rather than method calls. In fact, that paper you reference even notes that interfaces can still be defined using a 'normal' IDL, and then the parser would generate implementation based on whether or not the access model is intended to be local or remote, tailored for that access model. And if we still absolutely must use a weird message-like syntax, then why use a C-like syntax at all? Seems like it would be less confusing just to invent something new, or reuse something that already exists as to describe message-passing interfaces. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
Mark Doffman wrote: I understand that there is no difference on-the-wire between a function-call and message passing. The difference is in peoples perceptions and expectations. When I read CORBA IDL and see: int AFunction (int, int); Because of the connotations provided to me by years of procedural languages I expect this function call to be synchronous. I hope to break these perceptions by providing a message-based IDL. I don't have this perception; I think you're mistaking your own perceptions for the majority's. One of the huge benefits of this entire exercise is to "hide" dbus calls and make them look like methods on an object. If you're going to avoid calling dbus methods "methods," then I fail to see the point. Whether or not the object is local (in-process) or not is irrelevant. Whether or not the method call is sync or async is also irrelevant. It's a method call, pure and simple. DBus itself even calls them method calls. All you're doing by avoiding that in the IDL is making us learn and remember yet another confusing and incompatible syntax. I ask you to *please* reconsider not using some normal method-call syntax for the IDL. There's really no reason to do otherwise. If there really is a perception problem, people need to fix that on their own. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Federico Mena Quintero wrote: openSUSE has a patch that changes the invisible-char to "●" (Unicode 0x25CF BLACK CIRCLE). What happens when the current font is missing that character? Will it try to find another font that has it, or will there be a manual fallback that uses '*' instead? The square-with-hex-numbers isn't a great fallback :-/ . * The circle is fatter. We should have a no-discrimination policy against Unicode glyphs with an above-average body mass index, I mean, the ink-to-area ratio. However, there are some who believe (as a result of meticulous research) that a larger ink-to-area ratio increases the risk of certain health problems. I don't think we want our users to suddenly start dropping from their chairs due to heart attacks. * The circle is BIGGER. Size does matter, you know. [insert self-deprecation here], you insensitive clod! -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?
On Sat, 10 Jan 2009 13:42:31 +0200 Andrew W. Nosenko wrote: > First at all, could you provide any real-world example, where min/max > restriction on GParamSpec could be usefull? The reason is simple: > when validation fails, the application has no way to know about it > and, therefore, to do anything usefull. There just no interface for > such things, like "validation-fails-callback". As consequence, any > validation should be done at the application level, before bringing > GObject/GParamSpec/GValue/etc machinery into game. Hence, I hard to > imagine any usefull example of using restrcted GParamSpecs... Then you really just aren't imagining hard enough. If you look at the gdk/gtk sources, there are quite a few GObject properties that use GParamSpecDouble that restricts the min/max value a property can have. For example, think of a progress bar that uses a double to indicate the percent full: 0.0 is 0%, 1.0 is 100%. Any value outside that range is invalid. But I don't disagree that NaN or +/- inf should be allowed, assuming a restriction such as the above isn't in place for the particular instance of GParamSpecDouble. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Top-level include files
Cosimo Cecchi wrote: On Wed, 2008-12-17 at 09:17 -0500, Morten Welinder wrote: So: what header files are meant to be included by applications? Where is this information documented? AFAIK it's not clearly documented anywhere, but in addition to the toplevel headers, you should always include , , and if the function contained in these headers are required by the application/library including them. I don't know the reason why these are not included in the toplevel header though I believe gi18n.h and gi18n-lib.h are mutually exclusive and shouldn't both be included. I think a couple headers (maybe gstrfuncs.h and gstdio.h) require the app developer to (possibly) include some system headers, like string.h or fcntl.h, so they aren't included in the main glib.h header. -brian (and I'm also not sure whether there are more headers that should be included separately). Cheers, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: handling of keyboard under darwin (quartz)
Arnaud Charlet wrote: Hello, The current code in gdk/quartz/gdkkeys-quartz.c uses a deprecated (since 10.5) API to handle keyboard layout on darwin, which is not available to x86-64 applications. Here is a possible patch that uses the new TIS API. Is the TIS API available in 10.4? If not, I'd be sad, as I still have a powerbook with 10.4 on it, with no plans to upgrade. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing EMail Addresses in GLib/Gtk+ bugzilla components
Johan Dahlin wrote: b) We *always* use a @gnome.bugs alias as the "Default Assignee" for all Gtk+ components, using a standard, for instance: [EMAIL PROTECTED] Then what happens when someone takes the bug and assigns it to him/herself? Not allowing that seems pretty annoying... -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theming API hackfest: last call
On Wed, 15 Oct 2008 13:48:47 +0200 Robert Staudinger wrote:
> Relatedly I am thinking of a sane way to import styling into CSS
> blocks to aid widget mimicking. Imagine you want to mimick a GtkButton
> with your own wonderful implementation "FooButton", but unrelated in
> the GType hierarchy (not inheriting from GtkButton). Something like
> this might aid to apply GtkButton styling:
>
> FooButton {
> ccss: import(GtkButton);
> }
Here's an example that's not contrived at all that I just had to hack
around in xfdesktop (Xfce's desktop manager). The desktop's icon view
doesn't derive from GtkIconView (let's ignore why for now). I wanted
the selection-box-color and selection-box-alpha style properties from
GtkIconView, though, so I have to actually create a temporary
GtkIconView in my style-set handler to retrieve these properties.
So yes, there's definitely a use case for something like this.
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_utf8_validate() and NUL characters
Behdad Esfahbod wrote: Havoc Pennington wrote: On Mon, Oct 6, 2008 at 4:42 PM, coda <[EMAIL PROTECTED]> wrote: Is there any reason not to support NUL/U+ in strings? >> The point of not allowing nul in g_utf8_validate() I think is that nul is not valid text. It may be valid unicode in some technical sense, but it isn't text, in the same sense that malformed utf8 isn't text. What's so weird about NUL bytes Havoc? There is text, and there is nul-terminated text. In the former, a NUL byte is as valid as any other valid UTF-8 character. I think what he really meant (or if not, here's my take on it) was that NUL bytes aren't *printable* text... like you'd say of low-value ASCII data. Sure, it's technically "text," but most of it isn't something you can represent visually in a useful manner. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2008-09-23
Alexander Larsson wrote: On Thu, 2008-09-25 at 11:38 -0500, Mike Kestner wrote: If the motivation for removing the types is that, "things aren't as beautiful as they could be" then that argument doesn't really outweigh the pain of porting existing code. Especially when the cost of supporting existing code is so low. I think the general problem is that if you have a box type that can change orientation on the fly, what type is it? A HBox or a Vbox? This isn't about new code; this is about supporting old code -- old code doesn't try to flip h/vboxes. If an app developer needs a flippable box and is currently using GTK(H|V)Boxes, they're going to switch to the new flippable GtkBox. If not, they probably won't go to the effort to port their code to the new API, so there's no change. Ignoring the deprecation warnings and continuing to use Gtk(H|V)Box, AND trying to make them flippable seems like it would be a rare practice, and people who try to do that deserve what they get. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Ghee Teo wrote: Patryk Zawadzki wrote: Can we get a precise list of affected applications? I only tripped over Inkscape so far but that's not part of GNOME and we'll likely patch it up downstream if there's no upstream fix. The list of applications affected were listed by Kjartan and Vincent on this thread previously. The list of *GNOME applications* affected were listed. I'm afraid the world of gtk apps is quite a bit larger than those hosted on svn.gnome.org... -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
On Fri, 19 Sep 2008 10:39:29 +0200 Vincent Untz wrote: > Le jeudi 18 septembre 2008, à 22:25 -0400, Matthias Clasen a écrit : > > On Thu, Sep 18, 2008 at 4:36 AM, Sebastien Bacher > > <[EMAIL PROTECTED]> wrote: > > > > > > > > Would it be possible to reconsider this change? That's somewhat a > > > compatibility breakage and will create issues in lot of softwares. > > > If the change is right it would be nice to let a cycle for > > > applications to be updated to the new behaviour before using it, > > > there is thousand of GTK applications around and reviewing those > > > for incorrect adjustement usages is going to take a while. > > > > > > > I've put this on the agenda for the next gtk team meeting on Sept > > 23. > > Note that discussing this on Sept 23 means the decision will be too > late for GNOME 2.24.0. > > If this is a major issue, we should either reach consensus that GTK+ > should revert this ASAP or decide to fix all our .glade/.ui files now. > The latter won't help with applications we don't maintain, though. I'd definitely be in favor of this getting reverted as well. We (Xfce) have enough things to polish for our 4.6 release, and I'd rather not add what essentially amounts to ABI breakage to the list of things to fix. Can we remove the hard failure and just add a g_critical() or something? -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: When to call g_thread_init(), again...
Havoc Pennington wrote:
If the init function does have arguments, then you end up with a
requirement that all libraries and modules calling it must call it
with the same args ... which isn't possible ... so init functions with
arguments are broken unless the *app* and never a library will always
call the init function.
... which, if you can't avoid an init function, is what I'd advocate,
because...
All the gthread functions seem to check g_thread_supported() anyway
which is just the variable g_threads_got_initialized, so they could as
easily do "if (!g_threads_got_initialized) { g_thread_init(NULL); }"
This breaks for libraries that require locking in threaded programs but
(obviously) not in non-threaded programs. You can get into a situation
where you call a lock() without threads initialised, then something
somewhere (whether in glib or a 3rd party lib) goes and calls
g_threads_init() because it thinks it needs it (even if it doesn't,
because the program isn't threaded), and then you call unlock(), and it
breaks. This is the example tml brought up with GtkHtml.
Init functions suck, sure, I'll agree. But it appears we're stuck with
one in gthread, so I'd advocate tightening up the library (or any
libraries that use gthread) so it actually enforces what the docs say,
even if some existing apps get semi-broken as a result. Cuz, arguably,
they're already broken and just waiting for a hard-to-find error to pop up.
Now I'll go fix one of my libraries that behaves contrary to what I just
described... *hangs head in shame*
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: When to call g_thread_init(), again...
On Fri, 15 Aug 2008 10:58:59 +0300 Tor Lillqvist wrote: > The documentation for g_thread_init() says (in the stable branch): > > "You must call g_thread_init() before executing any other GLib >functions in a threaded GLib program." [..] > The real use case reported on gtk-list looked much more innocent, > though. Its main() started with: > > gtk_init (&argc, &args); > > html = gtk_html_new_from_string (html_source, -1); > > How can the poor application programmer know that > gtk_html_new_from_string() will cause g_thread_init() to be called > deep in the bowels of libORBit2? What should be fixed? Should gtkhtml > be fixed to call g_thread_init() itself, from functions that might > conceivably be the first ones that user code calls? But still that > wouldn't help strictly speaking, as gtk_init() of course also calls > lots of GLib functions, so it is too late to call g_thread_init() > somewhere in libgtkhtml in this case. Should ORBit2 g_error() out if > it notices that it wants to use threads but g_thread_init() has not > been called, instead of calling it itself? Yes to that last bit. If it really truly does matter that g_thread_init() be called before other glib functions, then no *library* should *ever* call g_thread_init(). If a library needs it, it should check g_thread_supported(), and g_error() with a useful error message if it fails. That way, the programmer of the app knows the first time they test-run their app that they've done it wrong. > So, should the requirement for g_thread_init() being called before any > other GLib API, if it is called at all, be removed? (After all, > failing it apparently is harmless anyway, on Linux. I don't remember the specifics (or even the generalities), but a few years ago I ran into a situation with a *very* hard-to-track memory corruption bug on Linux... the solution was of course to call g_thread_init() before anything else. I don't know if the situation has improved since then, but it seems safer just to err on the side of bailing out rather than hoping things will be ok. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: G_DEFINE_ARRAY, G_DEFINE_LIST
Mathias Hasselmann wrote:
GList has similar problems:
* It doesn't know the type of its elements, which makes
re-factoring of of GList code quite a pain. It's really easy to
change the element type of some list at one place and to forget
it at some other place.
Well, I'm not really sure how you'd implement this sanely without either
a) having a mess of macros, or b) having to specify the type every time
you change the list -- and even then, all you can do is check to make
sure the sizes match (not very useful for storing pointer).
Alternatively, there could be a GObject-ified list type that only allows
you to put GTypes in... in that case, sure, you get type checking for
'free'. Of course, then you couldn't store pointers to structs in this
list type without boxing them, which is kinda annoying.
* Since GList doesn't know its element type, elements have to be
released manually which forces you to repeat this code sequences
over and over again:
g_list_foreach (l, (GFunc) g_free, NULL);
g_list_free (l);
Yeah, that's a bit of annoying, but could just add a define to glib for
this:
#define g_list_destroy(list, freefunc) G_STMT_START{ \
g_list_foreach((list), (GFunc)(freefunc), NULL); \
g_list_free((list)); \
} G_STMT_END
Since you will always have to tell GList how to free its elements
(whether on list creation or destruction), this seems reasonable to me.
Again, with a GObject-ified list type, this wouldn't be necessary; it
would of course always know how to free itself.
Not sure if you're suggesting deprecating GList, but given the massive
amount of code in the wild that uses it, that seems foolish to me.
One of the things I've found lacking in glib/gobject (ever since I
started doing Mac Cocoa development) is a set of data structures that
take refcounted objects. NSArray, NSDictionary, etc. are often much
nicer to use simply because you don't have to worry much about the
memory management of the objects you stick in them. ... But this might
be a bit out of the scope of what you're suggesting here (or maybe not?).
(I think your array suggestions are pretty nice, though I don't have the
time to comment atm. A little concerned about more magic macros, though.)
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GHashTable and const
BJörn Lindqvist wrote:
On Thu, Jul 3, 2008 at 3:49 PM, Alberto Mardegan
<[EMAIL PROTECTED]> wrote:
ext Havoc Pennington wrote:
Whether you agree or not, the GLib types don't use const in their API,
so if you try to use const yourself on these types you're just signing
up for pain. It won't work well or do anything useful. (If _all_ the
methods on an object are non-const, all the const keyword does is make
you do a bunch of casts.)
While I tend to agree that const in C is of limited use, I find it a nice
way to tell the users of an API not to modify/free certain data.
So, when I am the owner of a GHashTable and I'd like to have others access
it in read-only mode, I'd use a const modifier on it.
On your past mail, you write that const is not useful in C, but on the other
hand you don't write that it's harmful either.
It is line-noise. It contributes nothing to the clarity of the code,
because it is already obvious enough that g_hash_table_size and
similar functions doesn't modify the hash table. It makes the API more
annoying to use as you'll get more "discards qualifiers from pointer
target type" unless you add non-const casts when you use const
variables. If you compile some GNOME projects you'll find that that
warning is one of the most common ones.
I'd doubt this would be an issue. You're talking about the reverse
problem. If 'const' qualifiers were added to current glib API
functions, there would be no new warnings. passing a non-const pointer
to a function that accepts a const pointer does not generate a warning.
The reverse (passing a const pointer as a non-const function
parameter) does cause a warning, but that wouldn't be the problem caused
by adding const to some glib functions.
Now, that's for C. For C++ passing a const pointer to a function
expecting a non-const pointer actually a hard *error*[1]. So the API
couldn't be changed in this way without likely breaking any C++
application that uses these glib data structures.
It is just a lot of work and annoyance for a (until someone profiles
the API with and without const modifiers) totally imaginary speed
benefit.
To put some more meat into the discussion, I point out that GValue's APIs
make heavy use of the const modifier, and from the user point of view that's
very helpful.
In what way?
Personally, I mainly see it as a hint to the programmer so I can tell at
a glance that the function doesn't modify the parameter (const) or may
modify the parameter (non-const). I'd agree that any speed benefits are
probably very small (if nonexistent), so the burden would be on someone
to benchmark to prove otherwise. If the API were being designed from
scratch, I'd say sure, use const as a semantic identifier. But at this
point it's just too late to do it without breaking C++ programs that use
glib.
-brian
[1]
$ cat foo.cpp
static void foo(char *bar) { }
int main(int argc, char **argv)
{
const char *moo = 0;
foo(moo);
return 0;
}
$ g++ -c foo.cpp
foo.cpp: In function 'int main(int, char**)':
foo.cpp:6: error: invalid conversion from 'const char*' to 'char*'
foo.cpp:6: error: initializing argument 1 of 'void foo(char*)'
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
Jean-Yves Lefort wrote: > On Wed, 04 Jun 2008 15:18:45 -0400 > Paul Davis <[EMAIL PROTECTED]> wrote: > >> On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote: >> >>> Rather than calling my suggestions silly, why don't you actually try >>> to explain how the non-preprocessed, dynamic-only GLib property design >>> is superior to the Qt design (or at least not inferior), or describe >>> these specific reasons that you are talking about? >> because i really don't give a damn. i don't use GTK+, i use gtkmm, and >> there is no feature of Qt that i ever find lacking. although Qt has >> closed the gap, for a long time it was the poor cousin of gtkmm when it >> came to type-safety, integration with the STL and more. i'm really not >> all that interested in what happens at the GObject level, other than >> that it maps into a decently performing layer by the time i interact >> with it at the C++ level. i also don't want to see glib/gobject >> developers wasting time trying to do what C++ plus a preprocessor does >> in plain C or C plus Yet Another PreProcessor. > > You didn't get the point. As explained in my initial message, a > preprocessor would be used to fix the performance of the property > system. I wouldn't think that this is worth it. As Tim mentioned elsewhere, for properties that need to be read/written in a time-critical fashion, it's best to add specific getters/setters. GTK already does this in many places (often for convenience, not for performance reasons), so I don't see how this is a huge burden. Regardless, have you done any benchmarking? You might find the performance issues to be negligible. And you might not. But throwing around statements like "it's definitely much slower" is meaningless without numbers. > Ease of use is not the main goal, it's only a secondary > benefit. As you might know, Qt is implemented in plain C++, and > nevertheless uses a preprocessor (moc). If it needs a preprocessor, it's not "plain C++". -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Use autopoint for GLib
Bastien Nocera wrote: > On Tue, 2008-05-06 at 19:41 -0400, Havoc Pennington wrote: >> Hi, >> >> On Tue, May 6, 2008 at 4:15 PM, Felipe Contreras >> <[EMAIL PROTECTED]> wrote: >>> Is there any reason? >>> >> I don't know. If I had to guess, it probably wasn't seen as worth >> maintaining. After all none of the other features of GLib have random >> --disable-feature options. Searching in bugzilla might find related >> bug discussion. > > And also because glib provides i18n for applications and libraries above > it, and convenience functions for UTF-8, etc. that wouldn't be available > on Unix systems without NLS support. Disabling NLS support might be quite useful for people on embedded systems and/or people who are using glib for only a part of their application and use a different translation framework. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
Ghee Teo wrote: > Cody Russell wrote: >> I was thinking that it would be nice if there was an integrated print >> preview widget in GTK+, that would be available cross-platform and >> wanted to check with people here before I commit much time to this. >> Right now we're spawning another process to do this, and I think an >> integrated widget would be much nicer. >> >> Thoughts? >> >Will be most interested in your idea to achieve cross-platform (which > I presume are > windows, MacOS, Linux/Unix), though the latter are pretty much based on > a layer > above X. > Definitely a+1 here. Hooking this up on MacOS X would be easy -- all apps I've used there that have a print preview just generate a pdf (or ps?) and open it with Preview.app. Basically the same as just launching evince on Linux, but of course you're more or less guaranteed to have Preview.app available on MacOS; not so much with evince on Linux. I'd love to see an integrated print preview on Linux, though, that doesn't have external dependencies. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Bug?] GtkStatusIcon bad default size when used with GtkIconFactory
Milan wrote: > I'm trying to use the GtkIconFactory system to set the icon used by > GtkStatusIcon. Once I've created the GtkIconSet for my icons (I have SVg > and PNG versions of the same icon), I use > gtk_status_icon_set_from_stock. Everything goes right, except that the > created icon is 20x20 px by default (i.e. when the GNOME panel is set to > a size of 24 px), when it should be (like every app does) 22x22. Not 100% sure, but I think this might be a bug in your code. See below: > Here's for reference a part of the code that I use, if you like (it's in > gnunet-gtk from the GNUnet project): > > char *instDir; > char *iconPath; > GtkStatusIcon *trayIcon; > GtkIconSet *iconSet; > GtkIconSource *iconSource; > (...) > > > iconSet = gtk_icon_set_new (); > iconSource = gtk_icon_source_new (); > iconPath = > g_build_filename (instDir, "..", "gnunet-gtk", > "gnunet-gtk-status-connected.svg", NULL); > gtk_icon_source_set_filename (iconSource, iconPath); > g_free (iconPath); > gtk_icon_set_add_source (iconSet, iconSource); What happens when you create a new GtkIconSource here for the PNG icon? E.g.: iconSource = gtk_icon_source_new(); I'm not sure, but gtk probably doesn't make a copy of the GtkIconSource you add via gtk_icon_set_add_source(). So when you set the PNG filename a couple lines down from here, you actually overwrite the entry for the SVG icon above. Again, not completely sure here, as I don't have time to read the docs atm, but give it a try. > iconPath = > g_build_filename (instDir, "..", "gnunet-gtk", > "gnunet-gtk-status-connected.png", NULL); > gtk_icon_source_set_filename (iconSource, iconPath); > g_free (iconPath); > gtk_icon_source_set_size_wildcarded (iconSource, FALSE); > gtk_icon_set_add_source (iconSet, iconSource); > > gtk_icon_factory_add (GNUNET_GTK_get_iconFactory(), > "gnunet-gtk-status-connected", > iconSet); > gtk_icon_set_unref (iconSet); > gtk_icon_source_free (iconSource); > gtk_status_icon_set_from_stock (trayIcon, > "gnunet-gtk-status-connected"); -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Moving "Open with" to the platform
Alexander Larsson wrote: > > I think having a dbus api for nautilus is an excellent idea. Suitable > operations include things like: > > * list open windows and locations > * open a window > * reload windows showing a location > * modify selection in a window > * modify nautilus metadata like notes and emblems We already have something like this in Thunar: http://svn.xfce.org/svn/xfce/thunar/trunk/thunar/thunar-dbus-service-infos.xml Might be useful for inspiration. Might be worth turning this into some kind of standard? Still, I think I'd be in favor of putting something like the app chooser into gtk, but I'm not 100% sold on the idea. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Hubert Figuiere wrote: > On Tue, 2008-03-18 at 16:03 -0700, Brian J. Tarricone wrote: >> "You may opt to apply the terms of the ordinary GNU General Public >> License instead of this License to a given copy of the Library. [...] >> (If a newer version than version 2 of the ordinary GNU General Public >> License has appeared, then you can specify that version instead if >> you >> wish.)" >> >> Personally I think this clause is kinda ridiculous, but it's there, >> nonetheless. > > It is there because implicitely LGPL code linked with GPL code becomes > GPL as a whole[1], just because LGPL allow setting restriction that the > GPL does not allow (hence the "Lesser-" part in the name). > > Similarly how the v2+ is compatible with v3+ via the upgrade part of the > licence. > > Hub > > [1] Where are talking about a whole software as it is being > redistributed. Getting a little OT, but... the issue I have is that, unless I'm reading it wrong, if I release something under LGPLv2.1-only (i.e., NO "or any later version" wording), then someone can still relicense my code under GPLv3, or even GPLv2-or-later. (But, strangely, one couldn't relicense as LGPLv3.) I'm not terribly concerned about being able to relicense LGPL to GPL *of the same version*, but discarding my wishes to stay with the same (L)GPL version is not ok (to me, anyway). -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Yevgen Muntyan wrote: > Alexander Shaduri wrote: >> Hi all, >> >> Having studied the FSF licenses and their restrictions, I think >> it would be reasonable to re-license GTK+ under the LGPLv3 >> (or later) + GPLv2 linking exception (or, alternatively, simply >> multi-license it under LGPLv3 / GPLv2). >> > > But you can't do that. Gtk is *LGPL*-2, so you can't > make it GPL-2 (unless you convince all contributors, > including aliens and dead). Yes, you can. Quoth the LGPLv2.1: "You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. [...] (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.)" Personally I think this clause is kinda ridiculous, but it's there, nonetheless. Any LGPLv#-covered program can be relicensed as a GPLv#-or-later program as well. Interestingly, my reading of this shows that, even if you license under "LGPLv2.1-only", someone can relicense as GPLv2-or-later, or GPLv3-or-later, or even GPLv3-only. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Alexander Shaduri wrote: > Hi all, > > Having studied the FSF licenses and their restrictions, I think > it would be reasonable to re-license GTK+ under the LGPLv3 > (or later) + GPLv2 linking exception (or, alternatively, simply > multi-license it under LGPLv3 / GPLv2). Hmm, there's a nifty idea. All GPLv2-compatible projects could still use gtk without any changes, and, as you say, all closed proprietary apps would be forced to follow the terms of the LGPLv3 for gtk. Open question: are there any weird legal side-effects of dual-licensing? I recall a big deal in the *BSD community not to long ago where some people didn't believe that dual-licensing was even legal (or something like that). Aside from that, would there be any downsides to any existing open source apps that use gtk? -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Lieven van der Heide wrote: > Ok, according to the matrix on > > http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility > > it's indeed not allowed, although I don't really understand why. Mathias pointed out exactly why. It's not that linking GPLv2-only to LGPLv3 violates the LGPLv3 license of the library. Linking a GPLv2-only app to a LGPLv3 library actually violates the app's its own license. The GPL in general doesn't allow linking to libraries with more restrictive licenses[1], and the LGPLv3 is more restrictive than GPLv2-only. -brian [1] The exception being for supposed "platform" libraries; e.g., you can link to Microsoft's C runtime even though it's closed source because it's a standard interface that can be considered part of the OS. I believe Sven quoted the exact bit from the GPL in another post. > > On 3/18/08, Lieven van der Heide <[EMAIL PROTECTED]> wrote: >> Does that really apply for the code you link to? Afaik, if a GPL >> program uses an LGPL library, it doesn't relicense that library under >> GPL too, it merely links to it, and leaves it up to the user to make >> sure the library is available. If this would be the case, than it >> wouldn't be possible for GPL code to use something like the Windows >> API or DirectX either. >> >> I think the restriction from the link you posted only apply to GPL >> libraries, but not LGPL. >> >> >> On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote: >> > >> > Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann: >> > >> > > I am really wondering what's the reason for FSF claiming, that >> > > programs >> > > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 >> > > allows non-free, proprietary programs to use LGPL-3 libraries, but >> > > excludes free software, licensed GPL-2 only? This sounds absurd to me! >> > > >> > > Is the FSF spreading FUD with their license matrix? Why doesn't the >> > > matrix have footnotes explaining that absurd conflict? >> > >> > >> > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes >> > additional restrictions not found in the GPLv2. So it isn't the LGPLv3 >> > that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is >> > the GPLv2 which forbids to linking against libraries more restrictive >> > than itself. >> > >> > See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility >> > for details. >> > >> > In theory LGPLv3 allows addition of exceptions, but they have to be >> > approved by all copyright holders. Doubt this will happen. So only >> > chance for upgrading to a new version of the LGPL is waiting for an FSF >> > approved version of the LGPL, which drops those additional restrictions >> > for GPLv2-only programs. >> > >> > Total insanity... >> > >> > >> > Ciao, >> > Mathias >> > -- >> > Mathias Hasselmann <[EMAIL PROTECTED]> >> > Openismus GmbH: http://www.openismus.com/ >> > Personal Site: http://taschenorakel.de/ >> > >> >>> ___ >> > gtk-devel-list mailing list >> > gtk-devel-list@gnome.org >> > http://mail.gnome.org/mailman/listinfo/gtk-devel-list >> > >> > >> > >> > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder bug?
Pavel Syomin wrote: > Hi, all! > > I had been experimenting with GtkBuilder using Gtk+ 2.12.5 from Fedora > 8. I have found, that if there is reference to unknown type in UI-file, > then application crashes. Is it a GtkBuilder bug? > > Test program: [snip] > > Gtk-ERROR **: Invalid type: Unknown > aborting... > Segmentation fault I'm guessing that's intentional. g_error() causes the program to abort, so it looks like whoever did the parsing code in GtkBuilder intended the app to abort if the UI description has errors. It's debatable as to whether or not this is the correct behavior, but one could argue that, if your UI is corrupt, you can't really rely on your program to work properly, and it could also cause harm to user data -- basically you have no idea what will happen and your program's behavior is undefined. It could also be seen as a way to increase the quality of GtkBuilder UI description files that end up out in the wild. App developers will do a much better job of making sure their UI files are correct if incorrect files cause the app to abort. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
Michael L Torrie (sorta) wrote: > I'm always amused by people who have big, hires screens and want to > maximize windows. In my opinion, on a 20" wide screen, I want > layouts to be narrow enough to be in a nice tall window that's narrow > enough to allow easy reading. It's funny that you use the phrases "I want" and "In my opinion," and then go on to assert that opinion as fact: > Letting the text spread out wide is not readable. If you had appended to that the following: "... for me, although others may have different preferences and abilities and may find wide text rows perfectly easy -- and preferable -- to read." ... then, your statements would have made sense. Why people still design based on a single fixed width for the browser window is beyond me (aside from simple laziness, with which I can sympathize). -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
(This is a bit better suited to gtk-app-devel-list, but...)
Brian Lu wrote:
> Thanks a lot for your explanation. But look at following snippet from
> firefox latest code base:
> void InitWidget() {
> mWidget = gtk_invisible_new();
> gtk_object_ref(GTK_OBJECT(mWidget));
> gtk_object_sink(GTK_OBJECT(mWidget));
> gtk_widget_ensure_style(mWidget);
> mStyle = gtk_widget_get_style(mWidget);
> }
> see
> http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.h#77
> and
> nsLookAndFeel::~nsLookAndFeel()
> {
> // gtk_widget_destroy(mWidget);
> gtk_widget_unref(mWidget);
> }
> see
> http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.cpp#78
Don't use Firefox as an example of how to best use gtk. They do some
rather arcane things to implement their gtk backend that should never be
done in normal gtk-only applications.
In most normal apps, you never need to _ref() or _unref() widgets. You
just create them, add them to a container, and call gtk_widget_destroy()
on the toplevel container when you want to get rid of them all.
You'd only use ref/unref if you want to keep widgets alive while
reparenting them (that is, removing them from one container and then
adding them to another).
Because of how gtk's memory management policy was designed, when you
create a widget, you don't own a reference to it. There's a so-called
'floating reference' that no one owns. When you add a widget to a
container, the container takes ownership of the widget and removes the
floating reference. Calling _unref() yourself would be releasing a
reference that isn't yours to release.
-brian
>
> I find mWidget is leaked (detected by using libumem.so provided by solaris).
>
> I don't understand why calling gtk_object_ref() to increase mWidget
> reference count.
> This causes mWidget's reference count to be 2 and gtk_widget_unref() in
> deconstructor decreases it to 1.
>
> Thanks
>
> Brian
>
>
>
> Markku Vire wrote:
>> Hi,
>>
>> The caller doesn't own the returned reference in case of any gtk_*_new
>> functions, but the results are floating references (they are removed
>> once somebody calls gtk_object_sink). This is different from normal
>> GObjects. So, unreffing the returned value causes practically a double
>> free.
>>
>> gtk_widget_destroy in turn runs dispose, ie. asks widget to drop
>> references to other widgets. Dropping external references usually causes
>> somebody else to drop the last reference to your widget, so it
>> efectively gets destroyed. In case of toplevels some global window list
>> is holding the reference.
>>
>> Calling gtk_widget_destroy without taking ownership a a widget is
>> usually a bug that causes a memory leak, but this is not the case here,
>> since we are talking about a toplevel.
>>
>> Cheers,
>>
>> -Markku-
>>
>> On Wed, 2008-01-09 at 17:39 +0800, Brian Lu wrote:
>>
>>> Hi, experts,
>>>
>>> I found following codes will crash in gnome 2.21 environment:
>>>
>>> ...
>>> GtkWidget *foo = gtk_invisible_new();
>>> gtk_widget_unref(foo);
>>> ...
>>>
>>> But it works well if gtk_widget_unref() is replaced with
>>> gtk_widget_destroy().
>>>
>>> Does that mean that we can't use gtk_widget_unref() on such object and
>>> we can only
>>> use gtk_widget_destroy() to release it?
>>>
>>> Thanks
>>>
>>> Brian
>>> ___
>>> gtk-devel-list mailing list
>>> gtk-devel-list@gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>>
>>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
David Zeuthen wrote: > Ideally this one needs to take another parameter indicating whether you > want 1kb = 1000 bytes or 1kb = 1024 bytes. > > The reason is that we want to generate nice display names in the volume > monitor; for ordinary media you want 1000 (to match the label on the > media); for optical discs you normally want 1024. gnome-vfs has this > terrible bug where it uses 1024 so you get the label "61.2 MB" media > even when the media itself says 64MB. This is kinda like punching the > user right in the face. It's not a mistake we should make for the new > shiny gvfs stuff. Mistake? That's correct behavior. It's not our fault the storage companies lie and use base-10 kB/MB/GB when everyone else uses base-2, and in fact they've been successfully sued in the US for doing this. Reporting the *actual* size of the media in base-2 units is the right way to go everywhere. Whether to use traditional kB/MB/GB or the (IMO somewhat ridiculous) SI KiB(which breaks the normal lowercase k = kilo convention for no reason)/MiB/GiB is another discussion. (I'd vote no in that discussion, at any rate.) -brian ___ 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: What's about the efficiency of using c to OOP compare to the c++'s abstraction?
Clemens Eisserer wrote: > Last but not least search for "performance problem" on the GTK list's > and the same for the QT lists. It may be that QT just has way less > developers and such search results are stupid in general, but to some > degree numbers talk for themself. (By the way you can also search on > nvidia's linux forums ;) ) There are many other far more probable reasons for performance problems than the choice of language. Especially with languages with such similar performance characteristics as similar as C and C++ (as opposed to, say, C and Ruby). -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why isn't GAsyncQueue derived from GObject?
Phil Lello wrote: > Hi All, > > I'm learning my way around GLib/GObject/GTK+ at the moment, and I've > written a GtkWidget derived widget that wants a GAsyncQueue as a property. > > I can implement that easily enough using g_param_spec_pointer(), however > it looks like I can't do type-checking, as GAsyncQueue doesn't seem to > have any type-related functions/macros. Indeed, if it did, I'd use > g_param_spec_object, with a type of G_TYPE_ASYNC_QUEUE. > > Is there a reason that GAsyncQueue doesn't derive from GObject? Because GAsyncQueue is provided in libglib (or is it libgthread?), which does not depend on libgobject. That is, it's assumed that people might have a use for GAsyncQueue but not want to pull in GObject and friends. > If so, I can easily enough write my own wrapper. If not, I can look into > writing a patch to change this. No need to write a wrapper. You can implement a GBoxed type for GAsyncQueue, and use g_param_spec_boxed(). Actually, there might already be one in libgobject; I suggest you check there first; if not, that's the patch that's more likely to be accepted. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: using dbus in the platform
{Whoops, re-send. I brain-farted and addressed to the wrong mailing list!}
Alp Toker wrote:
>
> I think you might have joined this discussion from the wrong angle.
> There is no real debate that using D-Bus makes sense for traditional
> desktop environments. NDesk, another GTK+ desktop environment,
> implements dozens of Freedestkop standards, including several fdo D-Bus
> specs.
Ah ok, I see -- I think I'd picked up on that a bit, but I didn't
realise that that was the central issue/argument at hand.
> The issue is that Havoc is proposing to use libdbus, his own D-Bus
> implementation, directly in GTK+. This means that desktop environments
> like NDesk which use their own D-Bus library will incur the overhead of
> multiple connections and conceptual breakage of two D-Bus
> implementations in one process.
I believe Havoc said that there's a potential solution to the problem of
multiple connections. Can this be done, or does that only work in the
case where you have multiple connections open that all use the same
low-level library?
The code size/data size overhead of having two implementations of the
same thing in the same process is unfortunate, of course.
> The problem is not unique to NDesk. Some half a dozen GNOME applications
> also use NDesk.DBus or dependent libraries. Dozens of third party
> applications that are neither part of NDesk or GNOME also use
> alternative D-Bus libraries and will be affected by any decision to use
> libdbus in GTK+ proper.
>
> There is no reason why the proposed libdbus-specific functionality can't
> be provided by some "libdesktop" library to be used by GNOME, XFCE and
> traditional desktops. This has the added benefit that such functionalty
> can simply be avoided by, say, GTK+ applications running on DirectFB, on
> deeply embedded custom OSs etc.
Well, I guess that depends on where you think the functionality that
requires dbus (or whatever other IPC mechanism) belongs in the toolkit
stack. D-Bus is an implementation detail of that functionality. The
same functionality could be implemented using CORBA/orbit, a custom
protocol on top of XShm, yet another custom protocol over a unix socket,
etc. What matters is the functionality: regardless of implementation,
where does GtkUnique, GtkHelp, GtkUrl, etc. belong? I'd be very
skeptical of the suitability of an API designed based on its low-level
implementation details, details which could change drastically at any
point in the future.
So, where does it belong? With the current trend/belief that gtk should
contain higher-level app-building primitives, I'd say these
dbus-requiring things belong in gtk, and not in a 'libgtkdesktop' or
whatever.
As for multiple implementations, why can't gtk have a simple pluggable
IPC module, sorta like the IM modules or GtkFileSystem? I know, I know,
it's one more layer of potentially-unneeded abstraction, one more API
that needs to be carefully designed since it can't really be changed
later, etc... But it would make it possible for ndesk (for example) to
provide its own IPC backend (a thin wrapper around the ndesk dbus
library, in this case) and avoid using libdbus at all.
Or is there another way to solve this problem without creating Yet
Another Platform Library[tm]?
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: let g_warn_if_fail replace g_assert
Armin Burgmeier wrote: > I think the proposal is that g_warn_if_fail() shall return (in contrast > to g_assert(), which most of the time aborts the program), but it shall > not return from the function calling it. g_warn_if_fail() is supposed to > do exactly what its name implies: Just print a warning if a condition is > not met. Ah, gotcha, I interpreted 'returning' as making the calling function return. Still, though, if g_warn_if_fail() prints a g_critical(), it makes more sense to me to call it g_critical_if_fail(). -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: using dbus in the platform
Havoc Pennington wrote: [a lot of intelligent stuff about using dbus in our stack] As an Xfce developer, I'm usually one of the first to be wary and skeptical when large new bits of functionality are added to glib and gtk (we try to use lightweight libraries with as few dependencies as possible), but at this point, I must say Havoc is right, and this is the correct way to go. We started using dbus in Xfce about a year ago, albeit in a limited fashion, and mainly for desktop/file manager integration. For our next major release (due sometime eventually whenever and stuff ^_~), we're planning on using dbus a lot more -- in our configuration system, for starters, and most modules (desktop, panel, etc.) will have some kind of dbus remote control interface, which should help solve several problems our users have -- picking a random image from a script and setting it as the desktop wallpaper every hour, to name one example -- problems/desires that we don't necessarily want to solve directly in our software, but we'd like to give users (and perhaps other developers) the flexibility to do this on their own outside of Xfce. Now, I know what's being proposed isn't "add dbus to gtk" -- the parts of gtk that use dbus will neatly hide dbus. My point is that a standard, flexible, lightweight, easy-to-use form of IPC is starting to become (or maybe already is) essential to an integrated desktop environment, not just to present a unified look, but to make extendability and flexibility easy and within reach to your average non-programmer power user. D-Bus was designed to be this IPC mechanism, and IMHO it does a pretty damned good job of it, certainly better than tossing around length-limited XClientMessages or re-inventing a custom unix socket protocol for every single app. The use cases described seem valid and worthwhile to me; currently our method of ensuring single-instance is to grab an X selection on startup. While that works, it's not portable, and is a departure from the high-level nature of gtk. I consider it a failure in the stack whenever I have to use xlib for anything that isn't truly x11-specific. I could go on, but... you get the idea. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: let g_warn_if_fail replace g_assert
Marco Barisione wrote: > Il giorno mer, 17/10/2007 alle 11.56 +0200, Tim Janik ha scritto: >> - add g_warn_if_fail (condition); which produces a critical >>warning about failing assertions but contrary to g_assert >>returns. > > If it's called g_warn_if_fail() I would expect a g_warning() not a > g_critical(). Agreed -- and of course g_return_if_fail() does a g_warning(), so doing a g_warning() on g_warn_if_fail() is kinda redundant. How about g_critical_if_fail()? It's a shame tho that we can't encode the "it returns if it fails" behavior in the name as well -- g_return_if_fail() is very clear what it does (IMO, the fact that it also does a g_warning() is a debugging-related bonus, not its primary purpose). g_critical_if_fail() sorta sounds like all it does is do a g_critical() if the condition fails, and then continues on from that point. I suppose g_critical_return_if_fail() is a bit verbose (esp. when you consider g_critical_return_val_if_fail() is even longer). But I guess good API docs will suffice ^_^. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Tim Janik wrote:
> hey All.
>
> i'd like to propose to turn g_assert and friends like g_assert_not_reached
> into warnings instead of errors. i'll give a bit of background before the
> details though.
Like Mathias, I was in a bit of "hell no!" mode when I first read this.
After reading your rationale, I'm less opposed, but... well, still
opposed.
> the main reasons we use g_return_if_fail massively throughout the glib and
> gtk+ code base is that it catches API misuses verbosely and gives programmers
> a chance to fix their code. this could be achieved with either a g_warning
> (mourn on stderr) or a g_error (mourn and abort).
>
> the reasons for the default behavior to use g_warning:
> a) a warning usually fullfills its purpose, the programmer knows there's
> something to fix and can start to trace the root cause.
> b) for easy tracing in gdb with backtraces, programmers can use
> --g-fatal-warnings to force abort behavior.
> c) programs that aren't 100% bug free could possibly trigger these warnings
> during production. aborting would take all the end user data with it,
> created/modified images, text documents, etc.
> issuing just a warnig preserves the possibility to still save crucial
> data if the application logic state still permits (which is most often
> the case in practice).
This is reasonable, and pretty much covers why I use g_return_if_fail()
and friends.
> in a recent discussion, i figured that (c) perfectly applies to g_assert
> and g_assert_if_reached() also.
Sorry, but I just don't buy it. When I use g_assert(), my thinking is:
"this is something that's a pretty bad bug on my part, and if the
assertion fails, I'm almost 100% sure that the program is going to crash
very very soon, and possibly in unpredictable ways."
> for a few reasons:
> 1) allow users to save their data if still possible; i.e. (c) from above.
If I think it's possible for users to still do something meaningful with
the program, I'll use a g_return_if_fail() or a custom if(foo) {
g_warning(); do_something(); } type thing. That's why we have the
separate macros in the first place! g_return*() are for cases where the
programmer thinks recovery might be possible, and g_assert*() is where
it isn't possible.
> 3) assertions can help to document programmer intentions and frequent (but
> regulated) use as we have it with g_return_if_fail can significantly
> reduce debugging time. i have so far been fairly strict about not adding
> assertions to the glib/gtk+ core though, because they also tend to make
> the code and end-user experiences more brittle, especially an
> occasional wrong assertions that'd have to be revoked upon closer
> inspection.
And that's the right approach, IMO: use assertions sparingly. Sometimes
one might be a mistake, and you fix it.
> conditionalizing the abort removes the brittleness and allows for
> adding more helpful assertion statements.
No, it doesn't. Changing a g_assert*() to a g_return*() when you
realise aborting is unnecessary is the way to go.
> note that in practice, this shouldn't change anything for programmers
> (except for the ability to write better code ;)
> because of G_DISABLE_ASSERT, programmers can already not rely on
> failing assertions to abort their programs (only g_error will reliably
> do that).
... which I think is pretty broken. You shouldn't be able to disable
asserts and pre-condition checks (G_DISABLE_CHECKS) at compile time.
They were put there for a reason.
> it should however take down programs in end user scenarios less often,
> and code review can be more lax about adding assertions.
No -- instructing programmers to make *proper* use of g_assert*() (and
to use g_return*() otherwise) will bring programs down less often. Or
maybe not -- maybe everyone uses it "properly" and this problem you just
doesn't exist.
Also... The documentation tells us what g_return*() and g_assert*() do.
If you change this, you're essentially changing the API of glib.
That's... not cool. You can argue that G_DISABLE_CHECKS and
G_DISABLE_ASSERT will do this anyway, but that's a choice on the person
who builds the code (and again, I'd argue that the existence of those
defines is a *really* bad idea). IMO, if you build with
G_DISABLE_(CHECKS|ASSERTS), you get to keep the pieces when things break.
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_show_help and gtk_show_url
Shaun McCance wrote: > - What about other GTK+-using desktops, like XFCE [...] At present we don't really have a help system. We generate HTML from our docbook docs, and then launch the default web browser to read them. I don't think we have any plans to move to a more "formal" help system like yelp, but we haven't really thought or talked about it. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib+OS X=Disaster
Hunter Freyer wrote: > My name is Hunter Freyer, and I'm an employee at Red Hat. I'm currently > working on some software for OS X that uses a library depending on GLib. I > decided the best way to work with this is to make a framework bundle for > GLib. I've been fixing the little errors that come up for a while now when > I got this: > > /Users/hjfreyer/GLib/Source/gthread/gthread-posix.c:97:3: error: #error This > should not happen. Contact the GLib team. Are you using the latest version of glib? Older versions may not have the required OS X configure logic. Last time I tried (in the past couple months), glib compiled just fine on OS X, without patches. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuildable type resolver
On Tue, 05 Jun 2007 12:44:55 -0400 Owen Taylor wrote:
>On Tue, 2007-06-05 at 11:23 -0400, Owen Taylor wrote:
>>
>> NAME := INITIAL_WORD WORD+
>> INITIAL_WORD := [A-Z][a-z0-9]*
>> WORD := [A_Z]{2,} | [A-Z][a-z0-9]+
>
>As I said, "something like" ... to correct myself:
>
> WORD := [A-Z]{1,2}[a-z0-9]+ | [A_Z]{2,}
^ presumably you also mean [A-Z] here?
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuildable type resolver
On Tue, 05 Jun 2007 11:23:36 -0400 Owen Taylor wrote:
>Actually, GtkIMContext fits the standard naming rules we have for
>mixed-case names:
>
>They are something like:
>
> NAME := INITIAL_WORD WORD+
> INITIAL_WORD := [A-Z][a-z0-9]*
> WORD := [A_Z]{2,} | [A-Z][a-z0-9]+
>
>So:
>
> GString => g_string
> GtkCTree => gtk_ctree
> GtkIMContext => gtk_im_context
> GdkRGB => gtk_rgb
On a possibly-related note, glib-mkenums doesn't work properly with this
scheme. It always treats consecutive capitals as separate 'words' in
the enum names.
My application is called 'Airconfig', and I use the 'ac_' prefix for
function names. GObject names look like 'ACPreferredNetwork'. But, if
I call an enum 'ACSecurityType', this happens:
$ cat test.h
typedef enum
{
AC_SECURITY_TYPE_FOO
} ACSecurityType;
$ glib-mkenums --eprod '@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]'
test.h
/* Generated data (by glib-mkenums) */
ACSecurityType
a_csecurity_type
A_CSECURITY_TYPE
/* Generated data ends here */
Obviously, what I want here is ac_security_type and AC_SECURITY_TYPE.
As a workaround, I use a different convention for enums, e.g.,
'AcSecurityType', but it would be nice not to have to do this.
Is this a bug (and should I file a bug report), or is this intended (or
unavoidable) behavior?
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sudden Tango changes in trunk
On Wed, 28 Mar 2007 12:49:44 +0200 Jakub Steiner wrote: > >To be honest I don't want to bother with all this work to provide an >'alternative' icon theme. The unique gnome 2.0 style make gtk apps on >platforms such as MS Windows or Mac OS X totally out of place. I'm >quite sad to see you hold on to that. I don't think the correct solution here is to try to make a one-size-fits-all default stock icon theme. Why would we even *want* the default icon theme to be tailored to MS Windows or MacOS X[1]? I think it makes more sense for someone (doesn't have to be you, Jakub, but if you wanted to, that's great) to create a theme that fits in well on MS Windows, and another that fits in well on OS X, and these can be distributed in installers/bundles for those OSes as the default there (and bundled separately as just an icon theme tarball for people on other OSes who like them). For Linux, etc. (X11), I'd say keep the current default. Most people are probably using their favorite non-default icon theme (whether it's Tango, or Industrial, or whatever), so it seems silly to spend time coming up with a new default that may or may not be used by a decently large amount of people. People who *aren't* using a custom icon theme are presumably happy with the current default. If you want to make a new icon theme for the stock icons, why not just distribute it as a normal icon theme that a user can select? -brian [1] On Mac, to fit in, you'd want to disable all button/menu icons anyway. The only visible icons on Mac that I can think of would be toolbar icons and MIME icons (the latter of which aren't provided by gtk). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multimedia widgets in GTK+?
On Thu, 01 Mar 2007 23:12:53 + Bastien Nocera wrote: >On Thu, 2007-03-01 at 11:06 -0800, Brian J. Tarricone wrote: >> On Thu, 01 Mar 2007 18:29:50 + Bastien Nocera wrote: >> >> >Heya, >> > >> >There are a few widgets in use in multimedia applications. The first >> >one is: >> >- BaconVolumeWidget, living in the libbacon module in SVN. It's >> >currently used by a large number of applications, cut'n'pasted >> >(Totem, Rhythmbox, LastExit, Banshee, Muine, Sound-Juicer, possibly >> >others). >> >> I feel like this is a bit special-purpose and heavy for a GUI >> toolkit, no? What kind of dependencies would it add to gtk? >> Obviously the widget isn't very useful without an A/V framework >> backend, and I wouldn't want to see gtk depend on gstreamer, >> xine-lib, etc. >> >> Or maybe it could be done similar to theme engines or file system >> backends: let A/V backends be installable separately without being a >> hard dependency of gtk (obviously the video widget wouldn't do >> much/anything without a backend installed). > >It doesn't depend on any A/V framework. I'm not sure what's heavy duty >about: >$ wc -l bacon-volume.[ch] > 846 bacon-volume.c > 57 bacon-volume.h > 903 total > >900 lines of code. Yeah, I'm an idiot. I somehow read 'BaconVideoWidget' where you typed 'BaconVolumeWidget'. I'll go wash my eyes out now and look again. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multimedia widgets in GTK+?
On Thu, 01 Mar 2007 18:29:50 + Bastien Nocera wrote: >Heya, > >There are a few widgets in use in multimedia applications. The first >one is: >- BaconVolumeWidget, living in the libbacon module in SVN. It's >currently used by a large number of applications, cut'n'pasted (Totem, >Rhythmbox, LastExit, Banshee, Muine, Sound-Juicer, possibly others). I feel like this is a bit special-purpose and heavy for a GUI toolkit, no? What kind of dependencies would it add to gtk? Obviously the widget isn't very useful without an A/V framework backend, and I wouldn't want to see gtk depend on gstreamer, xine-lib, etc. Or maybe it could be done similar to theme engines or file system backends: let A/V backends be installable separately without being a hard dependency of gtk (obviously the video widget wouldn't do much/anything without a backend installed). >- HildonSeekbar[1], which would need quite a bit of reworking to be >added to GTK+. The main differences with the default GtkScale widgets >is that clicking on the through would seek directly to the place >clicked, not progressively get closer to the point clicked. Can this be implemented in GtkScale as extra API instead of adding a new widget? >The other >difference is the ability to mark a "fraction", ie. the amount of data >already downloaded, and available for seeking. I can see Rhythmbox, >Totem, Banshee, and any other apps dealing with streaming media using >it. You mean sorta how YouTube does the seek bar with the little red indicator that moves to the right as more data gets downloaded? Yeah, that could be pretty useful, maybe in things other than multimedia apps. But again, could this be implemented via extra API in an existing widget? -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: undefined reference to `g_sequence_*'
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Stefan Kost wrote: > > I said from *svn*. I've build glib, pango and gtk from svn - all of today But are you actually *linking* the new svn pango and gtk to the new svn glib? It might be linking to the system glib, which is clearly not what you want. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iD8DBQFFz5yB6XyW6VEeAnsRAzkfAKCpsEEzkQNuFnbfgxOs+wLCn+zIpACgjDrw Qt8L2evmLJBm/HALd1c14Vg= =KC53 -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: undefined reference to `g_sequence_*'
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Stefan Kost wrote: > when building glib/gtk+ (into a local dir) from svn I get: > ../../gtk/.libs/libgtk-x11-2.0.so: undefined reference to `g_sequence_free' [...] IIRC GSequence was added to glib recently; are you using the most recent glib svn as well? And are you linking to the right library? -brian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iD8DBQFFz5NH6XyW6VEeAnsRAxpFAJ45eQWQ8UNfkjuUsTKfTrhFa4hF7ACbBsAf 8M6n0QpEe4ZCyj+xZSnbGXU= =RzvU -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder report
Tristan Van Berkom wrote: > On Tue, 2007-01-23 at 13:14 -0800, Brian J. Tarricone wrote: > [...] >> As Tristan also mentioned for this specific case in another email, an >> abort() in the GtkBuilder parser is ridiculously useless to the >> developer: if there's an error in one spot in a several-hundred/thousand >> line file, what's needed is information as to where in the file the >> error is. Sure, you'll notice it, but GtkBuilder's poor error-reporting >> API design makes it that much harder to track down the actual problem. > > Just so that people dont start getting scared, I'd just like to clarify > that this is not a restriction caused by the GtkBuilder design. > > The original write-up doesnt include contextual error reports > for every case of a parse failure, IMO that is simply a bug, > that doesnt mean that things need to be redisigned or anything > to correct it, just some patchwork to be done - no big deal. That's true: for development purposes, it's probably ok to just spit out a "GtkBuilder parse error: file %s on line %d: expected before "-type error to stderr. So perhaps for this particular case I was a bit overzealous, and for that, I apologise. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder report
Emmanuele Bassi wrote: > hi Brian; > > On Tue, 2007-01-23 at 11:03 -0800, Brian J. Tarricone wrote: > >>> Not really a blocker IMO. >>> It's easier to add error handling code when you find broken glade files or >>> are adopting an existing program to output something GtkBuilder can parse. >>> libglade does well here, so we should definitely improve this at some point. >> >> IMO, this is *definitely* a blocker. assert()/abort() statements have >> no place in a shared library[1]. > > you arrive a little late: GLib and GTK+ already use assertion failures > to check for the internal state of the library. Then I'd consider that a bug. Though, grepping through glib's sources, it seems that most of them are related to catching programming errors: i.e., maybe it's better to abort() there and be able to get a useful backtrace to figure out the source of the problem rather than just crash randomly later and have no idea where to look. Those are areas where providing error feedback isn't feasible; I'm not expecting every single glib function to provide a GError to report bugs in glib itself. So I guess I'd consider that to be sorta OK. However, if there are any assert() statements in a path where external data is being validated -- which is what we're talking about with GtkBuilder -- that's definitely a bug. >> As an application developer -- >> especially a _GUI_ application developer -- I expect that the libraries >> I use will not terminate my application, ever. If something Very >> Bad[tm] happens inside the library (even if it's my fault), I want to be >> able to inform the user via a popup dialog box and then quit my >> application gracefully. > > and how do you propose to gracefully recover from the absence of the > whole user interface definition? 1. Display a GUI error message to the user (probably most common). 2. Send an email somewhere reporting the error. 3. Write something useful to a log file. 4. Run a fallback or helper program that might allow the user to accomplish their task another way. That's just after about 10 seconds of thinking; I'm sure I (or others) could come up with more. How is "making the application window disappear without warning and giving no information" a good user experience? > if such a thing happens in production > if means you've screwed up the installation of the application so badly > that you can't really trust anything to be working correctly - hence an > abort() is the Right Thing(tm) to do No, it's not at all; that's laziness. The Right Thing[tm] to do is provide an error through the library's API and allow the application programmer to do something with it. If the app programmer decides to do nothing with it, at least it's his/her choice to be lazy. > if this happens during a > development cycle, then you'll be monitoring the standard error anyway, This is clearly not the case I care about. > so whether gracefully presented to you or not, you're going to notice > the error. As Tristan also mentioned for this specific case in another email, an abort() in the GtkBuilder parser is ridiculously useless to the developer: if there's an error in one spot in a several-hundred/thousand line file, what's needed is information as to where in the file the error is. Sure, you'll notice it, but GtkBuilder's poor error-reporting API design makes it that much harder to track down the actual problem. >> The *only* time I will accept assert()s in a library is the unlikely >> scenario where there really is no way to recover, and continuing along >> with any kind of error-handling attempt presents a real risk of data >> loss (or some other catastrophic thing). > > and, pray tell, why the failure to find the definition of the whole UI > of you application does not fall into this category? I don't define "recover" as "continue on and be able to do your work as if nothing bad happened." Of course that's not always possible. I define "recover" as "provide a graceful path (which may or may not include exiting to the application) after giving a useful error message to the user." That's by definition impossible when abort()ing. Who are you or I to say you know exactly why and how people will use GtkBuilder X years down the road? Maybe a failure to parse a UI definition isn't fatal to some applications; it might just make some features unavailable. Maybe an app developer won't want to use GtkBuilder for the entire interface, but just for particular portions where typing out the raw gtk would be very tedious. Why should the use cases of GtkBuilder be artificially limited due to what appears to
Re: GtkBuilder report
Johan Dahlin wrote: > Tristan Van Berkom wrote: >> - Parse errors should be reported nicely; currently if your glade file >> is malformed - you'll get some assertion failure like "assertion >> object_info != NULL failed". >> >> Some work has been done already to improve this - by looking at the >> error_missing_attribute() function in gtkbuilderparser.c - looks >> like these assertions can at least be replaced with some more >> informative output. > > Not really a blocker IMO. > It's easier to add error handling code when you find broken glade files or > are adopting an existing program to output something GtkBuilder can parse. > libglade does well here, so we should definitely improve this at some point. IMO, this is *definitely* a blocker. assert()/abort() statements have no place in a shared library[1]. As an application developer -- especially a _GUI_ application developer -- I expect that the libraries I use will not terminate my application, ever. If something Very Bad[tm] happens inside the library (even if it's my fault), I want to be able to inform the user via a popup dialog box and then quit my application gracefully. The *only* time I will accept assert()s in a library is the unlikely scenario where there really is no way to recover, and continuing along with any kind of error-handling attempt presents a real risk of data loss (or some other catastrophic thing). >> - abort()ing on bad glade files >> >> In my opinion, we shouldnt abort just because a glade file was >> malformed (we dont abort on corrupt jpegs afaik) - so what is >> the alternative ? >> >> How about printing an error message about the parse failure/reason >> and then destroying the hierarchy that was "created thus far" ? > > Isn't GError prefered? This is exactly what I'd like to see: a GError propagated all the way up to the application. -brian [1] I still cringe a bit over how glib's memory routines abort() on OOM conditions. Fortunately (or unfortunately, depending on your point of view), Linux in its default configuration will never return NULL from malloc() (of course this says nothing of other platforms where glib is supported). OOM conditions on a desktop are pretty rare anyway, I would think. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Call to GDK_THREADS_ENTER in gtk_main
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Padraig O'Briain wrote:
> The function gtk_main contains the code.
>
> if (g_main_loop_is_running (main_loops->data))
> {
> GDK_THREADS_LEAVE ();
> g_main_loop_run (loop);
> GDK_THREADS_ENTER ();
> gdk_flush ();
> }
>
> When GDK_THREADS_LEAVE is called do we expect the mutex to be locked?
>
> If yes, what code locks it?
>
> If no, should GDK_THREADS_ENTER be called previously so that the
> mutex_unlock call does not fail?
If the thread system hasn't been initialised (i.e., you haven't called
g_thread_init() and gdk_threads_init() before gtk_init()), then
GDK_THREADS_LEAVE() and GDK_THREADS_ENTER() won't do anything. If you
have, then you're expected to have called gdk_threads_enter() before
calling gtk_main(). Read the gtk/gdk threading docs for more info.
(Might this question be better suited to gtk-app-devel-list?)
-brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.1 (GNU/Linux)
iD8DBQFFtIx06XyW6VEeAnsRA16zAKCu7IlKma6D0y1gZ3hdb/A6nZnF0ACgvjjs
5kKeFnVmwHqulYAql78sHzI=
=l3m9
-END PGP SIGNATURE-
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Warnings/Errors during Threaded Execution
(Please move this discussion over to gtk-app-devel-list. gtk-devel-list
is for the development of gtk itself.)
Christopher Bland wrote:
> Brian J. Tarricone wrote:
>
>>> Clicking the first button fires the 'clicked' event where I make the
>>> following calls:
>>>
>>> g_thread_init(NULL);
>>> gdk_threads_init();
>
>> Looks like you didn't read the docs well enough then. Those two calls
>> *must* come *before* your gtk_init() call. Then, as another poster
>> suggested, you need to surround the call to gtk_main() like so:
>
> Right on... I did miss that part. I'm obviously new to GTK but not to
> threading and I'm having a hard time wrapping my brain around this for
> some reason.
>
> I cleared up the warning messages, however I am still hung up; I've
> pasted a sample below. When I click the 'Start' button it freezes and
> I'm not using threads, although I think it should be set up to run
> them. I'm unfortunately the only developer in my shop so I can't get
> another pair of eyes to look at this and I've been driving myself crazy
> all day. Any suggestions would be appreciated.
That's cuz you missed one of the other things I said above: gtk signal
callbacks are run with the gdk lock held, so you must not call
gdk_threads_enter() in a signal callback. Your beginScan() callback
calls setStatus(), which does just that.
(On a side note, I'd suggest you replace:
> while (g_main_context_iteration(NULL, FALSE));
with:
while(gtk_events_pending())
gtk_main_iteration();
-brian
>
>
> [code]
> #include
> #include
>
>
> GtkWidget *statusbar;
> static guint context_id;
>
> int setStatus (char*, char*);
>
>
> static void beginScan (GtkWidget *widget, gpointer data)
> {
> printf("Hello World!\n");
> setStatus("0.0", "Working...");
> }
>
>
> /* Callback function to set the progress bar from other functions */
> int setStatus (char *fraction, char *text)
> {
>
> gdk_threads_enter();
> gtk_statusbar_push(GTK_STATUSBAR(statusbar), context_id, text);
> while (g_main_context_iteration(NULL, FALSE));
> gdk_threads_leave();
>
> return 0;
> }
>
>
> /* Callback to do some cleanup if a delete_event is called */
> static gboolean delete_event (GtkWidget *widget, GdkEvent *event,
> gpointer data )
> {
> /* TODO: Need to put some cleanup stuff here... */
> return FALSE;
> }
>
>
> /* Callback to destroy the window and all of its widgets */
> static void destroy (GtkWidget *widget, gpointer data)
> {
> gtk_main_quit ();
> }
>
>
> int main(int argc, char *argv[])
> {
> GtkWidget *window, *button1;
> GtkWidget *vbox1, *info_frame;
>
> g_thread_init(NULL);
> gdk_threads_init();
>
> gtk_init (&argc, &argv);
>
> /* create a new window */
> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> gtk_window_set_title(GTK_WINDOW(window), "Aurora Hard Drive
> Forensics");
> gtk_window_set_default_size(GTK_WINDOW(window), 200, 125);
> gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER_ALWAYS);
> gtk_container_set_border_width (GTK_CONTAINER(window), 3);
>
> g_signal_connect (G_OBJECT(window), "delete_event",
> G_CALLBACK(delete_event), NULL);
> g_signal_connect (G_OBJECT(window), "destroy", G_CALLBACK(destroy),
> NULL);
>
> /* Create the vertical packing box and the two frames */
> vbox1 = gtk_vbox_new(FALSE, 0);
> info_frame = gtk_frame_new("Information");
>
> button1 = gtk_button_new_with_label("Start Scan");
> g_signal_connect(G_OBJECT(button1), "clicked",
> G_CALLBACK(beginScan), NULL);
> gtk_container_add(GTK_CONTAINER(info_frame), button1);
>
> /* Create the status bar */
> statusbar = gtk_statusbar_new();
> gtk_statusbar_set_has_resize_grip(GTK_STATUSBAR(statusbar), FALSE);
> context_id = gtk_statusbar_get_context_id(GTK_STATUSBAR(statusbar),
> "Statusbar");
> gtk_statusbar_push(GTK_STATUSBAR(statusbar), context_id, "Idle");
>
>
> /*/
> /* Start packing the boxes and frames into the window */
> gtk_box_pack_start(GTK_BOX(vbox1), info_frame, TRUE, TRUE, 0);
> gtk_box_pack_start(GTK_BOX(vbox1), statusbar, FALSE, TRUE, 0);
> gtk_container_add(GTK_CONTAINER(window), vbox1);
>
>
> /
Re: GRegex
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/24/2006 10:17 AM, Dominic Lachowicz wrote: > Hi Marco, > > Please take my review with a grain of salt. I've been wanting a > convenience API on top of PCRE for a while now, and it would be great > if we could get something like GRegex into Glib proper. [...] > 2) I noticed that there are g_regex_ref/unref() methods. Why did you > choose to do this, rather than subclass GObject? You would also then > have easy GObject-style accessors for the regex's "pattern" and > "match_options". In that case, GRegex couldn't be included in libglib proper. It would have to be in libgobject, or in a separate (libgregex?) library that depends on libgobject. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFFPmxp6XyW6VEeAnsRAvniAKCL71koL8aWDduD1Xn+wnRVvgTI9QCfb2OP NEvfq3v8t1K+EJ4PUiIh8z8= =IL7u -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dominic Lachowicz wrote: > I'm sorry for what may be a stupid question. Why do we need a bridge > API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) > if we're already putting the onus on developers to: > > 1) Modify their menus to conform to MacOS style guidelines, including > putting entries into special menus (e.g. the "Apple" menu), which > don't have a GTK+ equivalent I really don't think many (if any) developers will actually consider OS X when creating their menus. It's just not practical to assume they will, and my unsubstantiated assumption is that the vast majority of GTK developers will be targetting X11. (FYI, the Apple menu is not modifiable on OS X by users or app developers. The "application name menu", however, is.) > 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar But who's going to actually do this? Most developers will only use an API if it seems to have an effect on their testing. If they're not testing on OS X, it just doesn't seem likely. > 3) Call #2 at appropriate times when different windows get focus (e.g. the > Gimp) This sounds somewhat kludgy, but I like it the best. The GTK app developer doesn't have to do anything, and the toolkit tries to do what's right for the environment. > Wouldn't it be preferable for the developers to just use the Cocoa > menu-creation APIs directly? Not really. Who's going to actually do it? > If we were talking about some shim that > automatically takes any focussed window's GtkMenuBar and injects it > into the OSX menu bar, that might be different. This is kinda sorta what I'm talking about. My guess is that no one will actually accept it because it's error-prone and a bit of a hack. It doesn't solve all our problems: we won't have a 'Preferences' or 'Quit' menu item in the application name menu, as is normal for OS X apps, and there's of course no guarantee the menu layout will conform to Apple's standards (which I'm not all that worried about). But I think it's a good start, since there's no "real" way to make a GTK app more OS X-like without introducing some backend-specific APIs that no one is going to use. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKjZg6XyW6VEeAnsRAqOiAJ46MhU+kOHRz1JQjcVF0L61I4MAIQCgldsO Z0y86zrCFYuo6Q+XOmzcq2Q= =8FzB -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Mac OS X state of the union
Anders Carlsson wrote: Hello, For the last three months I've been working on making the GTK+ Mac OS X port in a somewhat feature-complete state so we can slap a "1.0" tag on it. The progress (as well as the remaining items) can be found on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Roadmap The most challenging task remaining now is to make GTK+ use the built-in double-buffering features that exist in Mac OS X; I have sort of an idea on how to do this and I'll send off a proposal shortly to the list, since this most certainly changes some of the low-level parts of GDK) We at Imendio always welcome help, there's a list of things to do availabe on http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Things_to_do with varying degrees of difficulty. Looking good so far; I just got it all compiled. gtk-demo runs, though with a bunch of visual glitches (BG of many windows is black, BG of parts of scrollbars is black, etc.). If I have some more time, I'd love to try and tackle a few items on the TODO list. I have a question though about menu bars. I'm sure this is a bit tricky to handle, but might there be a way to designate that a particular GtkMenuBar attached to a particular window is the "main" menubar, and somehow merge its contents into the OS X top-of-screen menubar? I'm a little stumped as to the best way to do this, since technically you can pack as many menubars as you want into a single window. Thoughts? -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 5:31 PM, Yevgen Muntyan wrote: > I agree. Can we please get entry in FileChooser? Try ctrl+L. Assuming that's what you mean. >> As a random example, a piece of software I maintain had an option for >> whether or not to show application icons in a menu for over a year >> before I discovered the global gtk-menu-images setting. >> > Err, and? It sounds rather like an argument against gtk-menu-images > setting. Exactly. Or, more general, an argument against having a large number of global settings -- for any purpose -- including the one you want to introduce. > Or like an example of why people should read api docs ;) I do. Almost daily. But why would I expect there to be a global setting for whether or not to display icons in menus? Especially when no DE I've used (disclaimer: I haven't used GNOME since 2.2, so this may have been added) includes a global preference for this in a user-visible location? By the same token, why would I, as a hypothetical text entry widget author, expect there to be a global preference dealing with selection handling? You probably would, because you seem to care a great deal about it. But why would someone -- especially someone who is happy with the current behavior -- think about it? -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEENpr6XyW6VEeAnsRAnNJAJ9KhB3vfUuPq8V8XashTVmi4xcYpQCgxFAL OIijf8SwfYZ/ywx0Y1V4Rew= =ftvJ -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 3:51 PM, Yevgen Muntyan wrote: > Brian J. Tarricone wrote: > >>> mozilla allows user having multiple selections, and it doesn't >>> clear selection when you select something else. It's not buggy, >>> it's correct (not for everyone, of course). >>> >> >> Not according to accepted practice. At the very least (not even talking >> about any kind of spec), one could argue that, since moz/ffx uses gtk, >> it should emulate gtk's behavior. >> >> > "Accepted" here is what we currently have. I claim that mozilla > is right, and it correctly does not emulate wrong gtk behavior. > (right and wrong for many people, not for everybody, etc., etc.) Well, we're arguing over what boils down to a personal opinion/aesthetics, which is useless. No agreement can be made here, so let's just drop it. >>> The document you posted link to tells about what X selection is >>> and what happens when you select text/do whatever. Question >>> is not what gtk does, we know that. >>> Question is "why am I not allowed to have multiple selections?" >>> "Because of X" is not the right answer. >>> >> >> Unfortunately it *is* the answer, regardless of whether it's "right" or >> not. You can only have one PRIMARY selection at one time. De-selecting >> all other selected text serves as visual indication of which text will >> get pasted from PRIMARY. It's of course a matter of opinion as to >> whether or not that visual indication is useful and necessary, or >> counter-productive and annoying. > Exactly. In my opinion it is wrong that I have this indicator. > I care more about selection in the editor more than about fact > that if I see selected text, then middle button click will paste > this text. Again, personal opinion. >> Adding a pref to accomodate that >> sounds like an consistency-breaking kludge[1]. >> >> > Well, see your footnote :) Why make matters more confusing and inconsistent? > About consistency, should we use bash/tcsh/eamcs/vi shortcuts > in GtkEntry? I believe it's same kind of question. I disagree. The issue at hand is text selection behavior regarding copy/paste across GUI applications of different toolkits (and sometimes the same toolkit). You're bringing up specific features of certain applications. (On a side note, emacs keyboard shortcuts are supported in gtk if you use a different keytheme. I imagine you could support vi as well.) >> Maybe some people don't care about the PRIMARY selection. Fine. But in >> a sense, you kinda have to if you want to get the most out of X's >> somewhat unique (and IMHO very useful) copy/paste semantics. > Err, what exactly? Middle-button-click would still work. Do I miss > something or you mean that seeing not more than one selection > is "most of X copy/paste semantics"? No, you just misquoted me. Re-read it. I'm actually for some reason not talking about text-selection at all here. Just that if you want to get the most out of X copy/paste (i.e., being able to intelligently use *both* the CLIPBOARD and PRIMARY selections), there's a slight learning curve involved. It's a tangent topic, so feel free to ignore it. >> For people >> who are content to do the Windows-like CLIPBOARD method and totally >> ignore PRIMARY, I can understand why losing selected text would be >> annoying. But why should we dumb down the interface for the lowest >> common denominator? > > Because we are doing it all the time maybe? Terrible, terrible justification. > Anyway, I do not totally ignore PRIMARY nor I want to disable > it; still, I want to have multiple selections. Again, personal opinion. >> Sure, sure, it's a pref, and the default behavior >> can stay the same. Whatever. Yay pref-bloat! >> > No option and half of people happy is better than letting > them choose? Who said half of people like it your way? Who said half of people like it my way? In lieu of a real usability study, you go with what the developers prefer. >> "Fixing" gtk in this sense is not a magic bullet, either. What about >> custom text-entry implementations? The GtkIMHtml WYSIWYG entry widget >> in Gaim comes to mind. > > Made of GtkTextView? Just because it derives from GtkTextView doesn't mean it behaves the same way. I haven't checked it in a while, though. >> They'd have to implement support for your pref. >> What about custom icon view cell-editing widgets (I believe Thunar[1] >> has or will have one)? That
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 3:05 PM, Yevgen Muntyan wrote: > Brian J. Tarricone wrote: > >> It's not really gtk that's in the wrong here - IMHO mozilla/firefox is >> buggy. > > mozilla allows user having multiple selections, and it doesn't > clear selection when you select something else. It's not buggy, > it's correct (not for everyone, of course). Not according to accepted practice. At the very least (not even talking about any kind of spec), one could argue that, since moz/ffx uses gtk, it should emulate gtk's behavior. > The document you posted link to tells about what X selection is > and what happens when you select text/do whatever. Question > is not what gtk does, we know that. > Question is "why am I not allowed to have multiple selections?" > "Because of X" is not the right answer. Unfortunately it *is* the answer, regardless of whether it's "right" or not. You can only have one PRIMARY selection at one time. De-selecting all other selected text serves as visual indication of which text will get pasted from PRIMARY. It's of course a matter of opinion as to whether or not that visual indication is useful and necessary, or counter-productive and annoying. Adding a pref to accomodate that sounds like an consistency-breaking kludge[1]. > Some people believe there should be not more than one piece > of selected text and they know about X selections and stuff, and > are happy with that; another people believe that they should be > able to have as many selections as they wish, like they select text > to highlight it or use Ctrl-C to copy it to clipboard. > These two points of view are both valid, this is why I am proposing > a choice. Maybe some people don't care about the PRIMARY selection. Fine. But in a sense, you kinda have to if you want to get the most out of X's somewhat unique (and IMHO very useful) copy/paste semantics. For people who are content to do the Windows-like CLIPBOARD method and totally ignore PRIMARY, I can understand why losing selected text would be annoying. But why should we dumb down the interface for the lowest common denominator? Sure, sure, it's a pref, and the default behavior can stay the same. Whatever. Yay pref-bloat! "Fixing" gtk in this sense is not a magic bullet, either. What about custom text-entry implementations? The GtkIMHtml WYSIWYG entry widget in Gaim comes to mind. They'd have to implement support for your pref. What about custom icon view cell-editing widgets (I believe Thunar[1] has or will have one)? That would have to support your pref as well. I'd bet there are others. -brian [1] Of course, one could (correctly) argue that consistency in this matter is generally broken already across many apps on the X desktop, unless you only use applications written using a single toolkit. Even then, consistency isn't guaranteed (Firefox, some versions of Anjuta, IIRC). [2] http://thunar.xfce.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEELo56XyW6VEeAnsRAqXfAJ0csVytOL7yGtyLFyerXN3I/stGFACdFAMu i6oT8ltIJyzhx6O8I2oB5vc= =z+NT -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/9/2006 11:38 AM, Yevgen Muntyan wrote: > Hello everybody, > > I opened a bug http://bugzilla.gnome.org/show_bug.cgi?id=334060 , > about "selected text == PRIMARY" gtk thing. > What do people think about enabling people use gtk in 'mozilla-like' > mode, when losing PRIMARY doesn't mean unselecting text? Please read: http://www.jwz.org/doc/x-cut-and-paste.html I believe there's a more formal document on fd.o about how the clipboard/primary selections should behave, but that's a nice easy-to-read document that does a good job explaining. It's not really gtk that's in the wrong here - IMHO mozilla/firefox is buggy. (I didn't really read the bug you pointed to, so this may have already been discussed. Seems like you're asking for an "unbreak my setup" configuration option, which is IMO a waste of time and the absolute wrong way to approach the problem.) -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFEELAI6XyW6VEeAnsRAtXsAJ4jLt10VJWJ/GvCIfdxfsB+CQgwJgCg6dPi nODFlT3kwBHZCSccXMZlhzs= =XdxZ -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_intern_static_string() and modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Federico Mena Quintero wrote: > Hi, > > Currently, we explicitly disallow the gtkfilesystemgnomevfs module from > being unloaded because some dumb part of libgnomeui assumes that it is > always in memory. I don't remember the exact problem right now, but > finding it in the ChangeLog is left as an exercise for the reader. > > My question in particular is about g_intern_static_string(). If I'm > a .so that is sometimes linked in, and sometimes dlopen()ed, how can I > know whether I should use g_intern_static_string() or g_intern_string()? > If I'm dlopen()ed, I can't intern a static string because it will cause > trouble when I'm dlclose()d. > > The more general question, of course, is how to know when a library was > loaded at runtime so that this problem can be avoided. This may not be exactly what you're going for, and is not the most elegant of solutions, but... If you can safely assume that everyone is going to use the g_module_*() set of functions to load the module, you could set a global flag in your g_module_check_init()[1] function, which will get called after the library is successfully g_module_open()ed. Then check the value of this flag when deciding whether to use g_intern_string() or g_intern_static_string(). I'm not sure if there's a similar bit of functionality with straight dlopen(). The manpage doesn't seem to indicate anything aside from _init() (which is listed as obsolete and not recommended), but I thought that was called for a normal dynamic link/load as well. (?) -brian [1]http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modules.html#GModuleCheckInit -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/9E06XyW6VEeAnsRAluzAKDiKu0hWtPMsG18IPxkoi1OFLbRGACgqMcs K2pOaRp/FpE/UpDjPrvNaXY= =ZrM3 -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME CVS: gtk+ matthiasc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/25/2006 8:01 AM, Jonathan Blandford wrote: > On Mon, 2006-01-23 at 22:35 -0500, Matthias Clasen wrote: > >> 2006-01-23 Matthias Clasen <[EMAIL PROTECTED]> >> >> Add GtkLinkButton, a port of GnomeHRef. (#314808, Emmanuele Bassi) >> >> * gtk/gtklinkbutton.h: >> * gtk/gtklinkbutton.c: New files. >> >> * gtk/gtk.h: >> * gtk/gtk.symbols: >> * gtk/Makefile.am: Glue. >> >> * gtk/gtkaboutdialog.c: Use GtkLinkButton. > > Hi Matthias, > > I really like the fact that we now have GtkLinkButton. It's a neat > little widget. I don't like the fact that every instance of every > clicked button has to handle the 'clicked' signal itself. > > We can add a call like gtk_about_dialog_set_url_hook() to the link > button to set it globally for all link buttons, but I'd like to do > better than that. The user's browser preferences exist in GConf; lets > try to get it out of there. > > We'd traditionally try to do this with gnome_program_init in libgnome. > However, we're trying to deprecate those libs precisely because people > didn't like adding an additional library just to get desktop support. > Here are a couple other approaches we could take here: > > 1. Make GTK+ depend on GConf >PROS: Makes this (and a lot of other similar problems) very easy >CONS: Doesn't work with OSX/Windows; likely to be very controversial Please don't consider this approach. There are many users of GTK who do not need a large configuration backend, or who use different configuration mechanisms (like us over at Xfce, for example). I generally dislike the term "bloat", but this is a fine example of it, plain and simple. Most (maybe even all) of the GTK team probably also works on GNOME, but please recognise that many non-GNOME developers have invested a lot of time into using GTK for their projects, and don't need or want a GUI toolkit that tries to cater to the needs of a desktop environment above all else. The simpler, flexible -- though less integrated -- solution is to provide API hooks in GTK for setting external sources for desktop-related settings, similar to gtk_about_dialog_set_url_hook(), but more GTK-global. The core GNOME libraries can set these up on app initialisation. So we could have something like: typedef (*GtkUrlHandlerFunc)(const gchar *url, gpointer user_data); gtk_set_default_url_handler(const gchar *scheme, GtkUrlHandlerFunc handler, gpointer user_data); That's incredibly flexible: you can set different handlers for http, mailto, even something like aim, or a fallback by passing NULL as scheme. If GNOME wants to store these settings in gconf, that's fine, but let GNOME bridge gconf and GTK. Maybe there are some issues with this approach, but I'm sure they can be fleshed out and solved given some thought and some people genuinely interested in doing the right thing for *all* of GTK's users, and not just the GNOME crowd. If it's notably better that GTK itself stores these settings, then why not use a simple keyfile in the user's home directory? It seems to work fine for ~/.gtk-bookmarks. Someone else in the thread mentioned this would be "very 1991", but what's wrong with that? Complexity != better. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFD19dM6XyW6VEeAnsRArwXAJ0f9b40H6jVJNSYh0B4gTtgthu10ACfb+SZ BP4eEPFM6nqUUpeOOoLWqs4= =ojst -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Conflicting recommendations about using GTK_BIN(widget)->child in Gtk+ documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kalle Vahlman wrote: > Hi all. > > I noticed that there is a conflict in what GtkBin docs say: > > http://developer.gnome.org/doc/API/2.0/gtk/GtkBin.html#GtkBin-struct > " > The GtkBin-struct struct contains the following fields. (These fields > should be considered read-only. They should never be set by an > application.) > > GtkWidget *child; the child widget. > " > > and what the GtkComboBoxEntry docs say: > > http://developer.gnome.org/doc/API/2.0/gtk/GtkComboBoxEntry.html#gtk-combo-box-entry-new-with-model > " > You can get the GtkEntry from a GtkComboBoxEntry using GTK_ENTRY > (GTK_BIN (combo_box_entry)->child). > " > > So either the GtkBin or GtkComboBoxEntry docs needs to be changed in > this regard. I'm not really seeing how these disagree. The GtkBin docs say you can access the child via the struct, but to consider it read-only. The GtkComboBoxEntry docs say you can access its GtkEntry by getting the child of the GtkBin via the struct, which doesn't IMO contradict the GtkBin documentation. > Considerations: > > 1) GTK_BIN(widget)->child is officially available as > gtk_bin_get_child(), so it's not like it would be required to retrieve > the entry from a GtkComboBoxEntry. gtk_bin_get_child(), however, survives changes in implementation that would make GTK_BIN(widget)->child possibly not behave as intended. Not that I can see something like that happening in the 2.x series, but it's true in the general case. > 2) GTK_BIN(widget)->child is insanely more pleasant to use in code, > and a little more object oriented than gtk_bin_get_child() (which is > in my books always a good thing :) I think the opposite is true: good OO practices (as I understand them, anyway) seem to indicate using getter and setter methods to access member variables instead of accessing the variables directly, so gtk_bin_get_child() makes a bit more sense here. I do agree that GTK_BIN(widget)->child is easier to use in code, however. > 3) Use of public widget struct members are used succesfully with > GtkDialog (->vbox and ->action_area), so it's not like doing something > new. True, but just because it's done elsewhere doesn't mean it's good practice. Some of this stuff was probably left over from gtk 1.x to ease porting. > 4) Given the GtkComboBoxEntry docs recommendation and personal > observations, GTK_BIN(widget)->child is a common trait so it can't > really be considered as a contender for change in any way without > breaking a multitude of code. No point in trying to hide it instead of > embracing it, right?-) I'm not sure why this is even a consideration: no one's advocating removing the GTK_BIN(widget)->child functionality, and the GtkComboBoxEntry docs don't contradict GtkBin's warning that the child struct member is read-only. There doesn't appear to be any effort to hide it, either. > So my score is on the side of admitting GtkBin->child as a public > member in the docs, what's yours? It *is* considered a public member (albeit read-only) in the docs, so I don't see the problem. Cheers, Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuljG6XyW6VEeAnsRAt9NAKCcci8YFfrVHTtaGeMgUMzE8XbetgCg1QO6 RUqqS5Fx7ZqU58VfIy6mEtc= =J+52 -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/8/2005 6:08 AM, Kristian Rietveld wrote: > I assume that there isn't much code out there using the GtkFileSystem API. > In order to not have that kind of code crash and burn on a system with a newer > GTK+, we need to build in some kind of protection. Does anyone have > suggestions on this one? Why not keep the current API and invent a new one for async operation? Use gtk_file_system_async_foo() and the like, and just deprecate the current API. If you install a header file to a public system location, no matter what you say, it's a public interface. If you want to change that API incompatibly, you're obligated to increment gtk's major version. IM(NS)HO, of course. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDcQNp6XyW6VEeAnsRAmEyAJ0d22ACUMDUufb23jtNxO94l+PGtACfSxj8 yPxEUoo1NclyaA/JNRd/7n4= =EMPS -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
