Re: GTK+ 2.24.0
On Sun, 2011-01-30 at 01:21 -0500, Matthias Clasen wrote: GTK+ 2.24.0 is now available for download at: http://download.gnome.org/sources/gtk+/2.24/ ftp://ftp.gtk.org/pub/gtk/2.24/ http://www.gtk.org/ still has the GTK+ 2.20 release as the latest news entry. Perhaps it would be a good idea to add the GTK+ 2.24 release announcement? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Hi all, With recent developments I've found that GtkWrapBox in the end is not what was needed to meet the requirements of Glom (hence the writeup of the different container... coming in another mail). Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). GIMP is still using the horizontal wrap-box in two other places. But at least one place (GimpContainerGridView) should really be rewritten. So I don't think we have a strong interest in having wrap-box functionality in GTK+. But we would like to see a grid widget that we can use for showing things like brushes in a grid-view. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Refactoring out old code, missing things for debug builds
On Mon, 2010-09-27 at 14:43 +0900, Tristan Van Berkom wrote: Guys, I'm just raising this because it's been the third time now that I have to fix people's refactor commits locally just to get through a build. Today it was: gdkvisual-x11.c: In function ‘_gdk_visual_init’: gdkvisual-x11.c:283: error: ‘GdkVisual’ has no member named ‘visual’ gdkvisual-x11.c:283: error: ‘GdkVisual’ has no member named ‘visual’ Due to some code inside #ifdef G_ENABLE_DEBUG Please; when doing mass commits to GTK+ that change API, please make sure you have configured with --enable-debug. cppcheck is also quite good at catching such errors. It makes sure that code in #ifdef branches will at least compile. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Tue, 2010-09-07 at 14:21 -0400, Colin Walters wrote: I think it makes sense to put gtk-doc.m4 inside glib (and the same for introspection.m4). Shouldn't you be able to get away with the same hack that we use in GIMP ? http://git.gnome.org/browse/gimp/commit/?id=4f14da539118f7a4017c271b202c6c6ea304672b Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk DirectFB backend (again...)
On Sun, 2010-09-05 at 15:37 +0100, Emmanuele Bassi wrote: On Sat, 2010-09-04 at 19:47 +0200, Lionel Landwerlin wrote: Last week, I have seen that GTK+ 3.0 has drop the DirectFB backend because no maintainer was carrying it (which I wasn't aware of). that's frankly odd, since the backend has been known to be broken since the 2.14 release, which happened two years ago. And it was fixed by me during the 2.14 release cycle. Honestly I don't have the time though to keep it working on a regular basis. That's why I asked Lionel to step up as the maintainer of the backend. That said, let's see how the work on the backend in Lionel's git repository evolves... Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] Gtk DirectFB backend
On Wed, 2010-08-25 at 21:49 +0200, Lionel Landwerlin wrote: Hi, There is a bug report for this : https://bugzilla.gnome.org/show_bug.cgi?id=619468 I've always told you guys on the DirectFB list that you should notify me about fixes for the DirectFB backend. I don't have the time to actually work on this code, but I have worked on GTK+ and this backend in particular and I have commit access. If I had known about these patches, then I would have committed them. So what do we do now? Can we get these patches included in the current development branch so that work can continue to resurrect full functionality of the DirectFB backend? Can Lionel get commit access himself? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]
On Wed, 2010-08-04 at 16:33 -0400, Havoc Pennington wrote: Hi, Given this I'm not sure why nobody has ever replaced libtool while keeping automake. For me it's probably 1) automake is written in perl which I just don't speak and 2) suspicion that automake upstream wouldn't take the patch. I am completely happy with automake (especially when used nonrecursively). But libtool is too anti-productivity to live. If automake could just build a frickin' shared library instead of .la-hell, it would be a big upgrade. Or if someone could fix libtool so it isn't slow, and doesn't create annoying .la files on platforms that don't require them, that would be great too. What about http://dolt.freedesktop.org/ ? The approach taken here sounds quite reasonable and has the potential to cut down compile time significantly while keeping the portability of libtool without having to reimplement it. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkRange API is incomplete
On Tue, 2010-07-27 at 17:15 +0200, Krzysztof Kosiński wrote: Hello Here is my use use case (in Inkscape). I have a set of sliders (GtkScale) that control some values in the document. I want to update the view of the document in real time, but only push the change on the undo stack when the drag is finished. But the only signal I can connect to is value-changed. When I connect to it, I have only two choices: 1. Update policy GTK_UPDATE_DISCONTINUOUS. This will give me correct undo behavior but won't update the display in real time. 2. Update policy GTK_UPDATE_CONTINUOUS. This will update the display correctly but will flood the undo stack with partial changes. You could implement undo compression as we do in GIMP. Multiple consecutive position changes are compressed into a single undo step. This can be easily implemented by looking at the top-most step on the undo stack and checking if it is of the same type as the step you are pushing. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On Mon, 2010-03-15 at 21:14 +, jcup...@gmail.com wrote: But it seems to me that we have a more immediate need: gthread has a threadpools, but no way to pick a reasonable size for a pool. Feel free to use the implementation in GIMP as a starting point: http://git.gnome.org/browse/gimp/tree/app/base/base-utils.c#n54 Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
On Sat, 2010-01-02 at 14:40 +1100, Erik de Castro Lopo wrote: I'm having trouble differentiating between memory leaks in my code and apparent leaks in GTK when using valgrind. Even the minimal hello world program from the GTK tutorial: http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD when run as follows (suppression file from http://live.gnome.org/Valgrind): export G_SLICE=always-malloc export G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high \ --num-callers=50 --show-reachable=yes --suppressions=gtk.suppression \ helloworld helloworld-vg.txt 21 on Ubuntu 9.10 reports this: ==22566== LEAK SUMMARY: ==22566==definitely lost: 1,449 bytes in 8 blocks ==22566==indirectly lost: 3,716 bytes in 189 blocks ==22566== possibly lost: 4,428 bytes in 107 blocks ==22566==still reachable: 380,505 bytes in 7,898 blocks ==22566== suppressed: 35,873 bytes in 182 blocks If the leak summary of a 100 line demo program shows over 8000 definitely lost, indirectly lost, possibly lost and and still reachable blocks, how am I supposed to find the blocks of memory leaking from my code which is 3 lines? I agree that it would help a lot if we could in one way or another get rid of false positives. But my experience shows that you get pretty much the same valgrind warnings no matter how large your GTK+ application is. Your 100 line demo program will produce the same set of warnings as your 3 lines application (provided that your code doesn't have leaks). But still it would make everyone's life easier if one wouldn't have to differentiate between false and real positives manually. Perhaps valgrind suppression files maintained and shipped with the libraries would indeed be a good idea. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Improve detection of input device source type
Hi, On Mon, 2009-09-28 at 02:00 -0400, Thomas Jaeger wrote: - if (!strcmp (tmp_name, pointer)) -gdkdev-info.source = GDK_SOURCE_MOUSE; - else if (!strcmp (tmp_name, wacom) || - !strcmp (tmp_name, pen)) -gdkdev-info.source = GDK_SOURCE_PEN; - else if (!strcmp (tmp_name, eraser)) + if (g_strrstr (tmp_name, eraser)) gdkdev-info.source = GDK_SOURCE_ERASER; - else if (!strcmp (tmp_name, cursor)) + else if (g_strrstr (tmp_name, cursor)) gdkdev-info.source = GDK_SOURCE_CURSOR; - else + else if (g_strrstr (tmp_name, wacom) || + g_strrstr (tmp_name, pen)) gdkdev-info.source = GDK_SOURCE_PEN; + else +gdkdev-info.source = GDK_SOURCE_MOUSE; Is there a particular reason that your code is using g_strrstr()? It doesn't look as if you are interested in the last occurrence of the the searched string. Since you are looking for the needle anywhere in the hay, you should better use strstr(). Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [patch] constify g_simple_async_result_set_from_error
On Wed, 2009-09-02 at 14:28 -0400, David Zeuthen wrote: Mmmm, wouldn't this break the API? E.g. cause compilation of existing apps to spew warnings. If so, we can't do it. How is the introduction of a compiler warning an API break? Every gcc update introduces some more compiler warnings in code that used to compile cleanly before. I don't think that the possibility of introducing a compiler warning should keep us from introducing const where appropriate. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: generating documentation in a printable format...
Hi, guys, your thread is impressing. Just look at the last post and enjoy how the quotation level raises to its maximum in the middle of this mail where the author replies to himself for the third time in a row, always quoting the full previous post. Brilliant. Thanks for this wonderful work. It will make a perfect example for bad quoting behavior on public mailing-lists. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Make GCancellable subclassable?
Hi, On Fri, 2009-06-19 at 10:29 +0100, Richard Hughes wrote: It would be really great to wrap GCancellable in another object, in my case PkCancellable and add the extra functionality there. Unfortunately _GCancellable is private and not public, and thus can't be subclassed. I've attached a patch to make it public, and use a _GCancellablePrivate struct, which solves my problem nicely. Very nice. I have frequently hit the problem that objects in GTK+ and GLib are hard, if not impossible, to subclass. +1 from me for your patch. I'd also welcome if GCancellable and GInitable could be moved to GObject. They are potentially useful outside GIO. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Hi, On Wed, 2009-06-03 at 14:25 +0800, Davyd Madeley wrote: I was experimenting with using GtkOrientable today and came across what might be an oversight when using it with GtkBox'like objects. I wanted to turn a hbox into a vbox, which is fine. However the buttons in the box are then clearly in the reverse order to the one that makes sense. What order are they? What order would you suggest makes more sense? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Hi, On Wed, 2009-06-03 at 19:03 +0800, Davyd Madeley wrote: It's not really related to GtkOrientable per se, but it's specifically that when you change the runtime orientation you might also wish to reverse the packing order (I guess think about wishing to do a -90 degree rotation rather than a +90 degree rotation). Previously because you couldn't change the orientation, this was never something that came up. Does this clear up what I mean? Sure. But it would probably help to come up with a use case for this. I can not think of any good use case for changing the box orientation at run-time. And without such a use case, it becomes even harder to imagine that one would also want to reverse the packing order. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Hi, On Wed, 2009-06-03 at 13:32 -0400, Freddie Unpenstein wrote: From: Tristan Van Berkom, Date: 04/06/2009 00:13, Wrote: In general though, GtkOrientable already exists. People are bound to use it. An example use case of this would be a custom toolbar that could be placed optionally on top or on the side of the workspace where the tool ordering is relevant, but thats not really the point right, aren't we more after making sure the use cases we haven't thought of yet are still valid ? ;-) I have had a use case... Wasn't critical, just a two-pane window, and wanted to allow the two halves to be swapped. Since the thing was loaded from a glade file, it was a pain to do it manually, and I ended up just ditching the idea in favour or more useful functionality. what's so painful about: GList *list = gtk_container_get_children (GTK_CONTAINER (box)); gint pos = g_list_length (list) - 1; for (; list; list = list-next, pos--) gtk_box_reorder_child (GTK_BOX (box), list-data, pos); I haven't tried this, but unless I am mistaken this should reverse the order of children in a box. Seems easy enough to do and avoids the need to introduce yet another special case in the GtkBox code. Perhaps if this solution is not obvious enough, this should be turned into a utility function gtk_box_reverse_children_order() ? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ print preview
Hi, On Mon, 2009-05-18 at 15:06 +0200, Carlos Garcia Campos wrote: I've realized that print preview doesn't work as I thought, and I'm bit confused. An application open the print dialog by using GtkPrintOperation, then the user clicks on preview and a pdf file is generated to be used by a previewer. Such a file is passed to evince together with the print settings needed to print the file. The print dialog is closed, so we need to be able to print the document from the previewer. I don't understand why the previewer should be used to print the document. You may be right that this is what the authors of the GTK+ print dialog intended, but it is certainly an odd concept. I find it very confusing that the Print dialog closes when I hit the Preview button. Wouldn't it be better if it stayed open so that I can make adjustments if the preview turns out wrong and hit the Print button when I am satisfied with the preview? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
Hi, On Sat, 2009-05-16 at 20:36 -0400, Morten Welinder wrote: IMO this is now pretty much of a non-issue, since the current GTK file selection dialog is sufficiently like Windows (but nicer!). I'm not sure what planet you're living on. The current gtk+ file chooser absolutely stinks! It fails miserably in its primary task: showing the user what files are there in order to let the user pick one. In particular is it very, very bad at managing its screen real estate. See http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/ http://blogs.gnome.org/mortenw/2009/02/23/the-gtk-file-chooser-dialog-take-ii/ (The first is mostly for context. SuSE shipped with a bad bug.) What you are showing there are applications using the file-chooser incorrectly. In particular they don't set the window size large enough (or they forget to remember the user-chosen size). OK, that could probably be improved in the size requisition of the file-chooser dialog. But I wouldn't say it's a fundamental problem and it doesn't make the current file-chooser dialog stink. Of course there is always room for more improvements. But even though the file-chooser did really stink in the beginning, it has over the last years evolved into a dialog that I enjoy to use. Sven ___ 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
Hi, On Fri, 2009-05-15 at 22:28 +0200, Jernej Simončič wrote: For the values of nicer that match much slower, worse autocomplete behaviour than the native dialog, less useful Places list and confusing gradual display of network locations (the first time I tried opening something from my fileserver I thought some of my directories went missing because the GTK+ dialog displayed about a tenth of all folders at first, and then very slowly added the rest in about 15-second intervals; That sounds like a severe performance problem of GIO on the Win32 platform. Have you reported this as a bug? Can you assist in getting this fixed? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The GTK+ file chooser
Hi, On Sun, 2009-05-17 at 11:52 -0400, Morten Welinder wrote: What you are showing there are applications using the file-chooser incorrectly. In particular they don't set the window size large enough (or they forget to remember the user-chosen size). Add a preview: no space left for files. Add a filter: no space left for files. Add file format selector: no space left for files. Solution? Blame the applications. Fixing the size-request method is only the beginning. Right now anything you add canibalizes internal space instead of requesting more. Fixing that is a start, but then you would quickly end up with a dialog bigger than the screen. GIMP uses a GTK+ file-chooser with preview and format selector and an extra widget. I admit it is not a small dialog, but it still fits on the screen we design the application for. For netbooks or similar hardware with smaller screens, it would certainly make sense to squeeze out some pixels. This could be done using style properties (and perhaps can already be done). Places is wasting acres of real estate right now and it cannot even be squeezed: side divider can extend it, but not shrink it. For my typical use of the file-chooser, Places is very important. I use it all the time. But surely there are a few pixels there that could be saved. Not sure if it would be a good idea to allow the user to collapse it. Sven ___ 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
Hi, On Thu, 2009-05-14 at 20:47 -0700, 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). It would be nice to have some container implementations in GObject that deal with reference counting automatically. The classes found in libgee http://live.gnome.org/Libgee could serve as a starting point. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] RFC: adding a #define G_VALUE_INIT for initializing GValue on the stack
Hi,
On Fri, 2009-03-27 at 15:45 -0400, Andrew Paprocki wrote:
On Fri, Mar 27, 2009 at 1:47 PM, Andrew Paprocki and...@ishiboo.com wrote:
I checked gvalue.h and I don't see a #define in there containing the
proper initializer list for a GValue to prevent gcc warnings. Rather
than duplicating GValue v = {0, {{0}}}; everywhere, I'd like the
following to be added:
#define G_VALUE_INIT {0,{{0}}}
Sounds like a good idea to me.
I've attached a patch for easy reference.
I suggest you open an enhancement request for this at bugzilla.gnome.org
and attach your patch there.
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Hi, On Mon, 2009-03-16 at 17:04 +0100, Alexander Larsson wrote: I commited something like this limited patch to svn. However, I didn't add the public API parts yet. I've also turned in and accepted that using fsync() is needed at least when replacing a file. I've done a similar change for GIMP in libgimpconfig/gimpconfigwriter.c. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Hi, On Fri, 2009-03-13 at 14:11 +0100, Mathias Hasselmann wrote: I think you don't understand the problem. That might very well be the case. I had a look at the presentation that Alex linked to in the initial post in this thread. But I would have preferred a document that doesn't look at the issue from a database developer point of view. Other file systems but ext3 in order=data mode are that brain dead and broken, that they lose __both__ the old and new document on power loss! This is __not__ acceptable, in no way. But ext3 is what everyone uses. And as far as I understand the next generation Linux file-system btrfs is going to provide similar functionality: http://btrfs.wiki.kernel.org/index.php/FAQ#Does_Btrfs_have_data.3Dordered_mode_like_Ext3.3F 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. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: WebKit on webkit.gtk.org
Hi, On Sun, 2009-03-08 at 19:45 -0300, Gustavo Noronha wrote: On Sun, 2009-03-08 at 15:46 +0100, Sven Neumann wrote: PS: What is the state of WebkitGTK on the Windows platform? It would totally rock if we could finally ship the GIMP help browser with the GIMP installer for Windows. Besides the usage of mmap/unmap, which I added to our soup/gio backend not knowing it was a (already solved in glib) porting problem, the rest should work. I'll try to prepare a patch to clear that up this week, would be nice to have someone testing, though =). Sorry, I won't be able to test this. But if there was a binary package available (like what's offered at http://www.gtk.org/download-windows.html), I could ask the people who maintain the Windows build of GIMP to try to compile the help browser against that and test it. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: regarding animated mng support in gtk for directfb
Hi,
On Sat, 2009-03-07 at 10:37 +0530, Monil Parmar wrote:
I am using GTK-2.12.12.
I have compiled mng lib from http://sourceforge.net/projects/libmng/ .
The test application, I have used for X11 with linux.mng is at
libmng-1.0.10/contrib/gcc/gtm-mng-view .
gtk-mng-view is a sample gtk based application to view mng.
I could able to see linux.mng with animation effect.
But when I try to run the same source code(gtk-mng-view) for
GTK/DirectFB only 1st frame it shows.
I've had a look at this and the problem is clearly in the gtk-mng-view
code. The example code there draws outside the expose handler. This is
something that you should never do. It may work for GTK-X11 if you are
lucky, but it's not supported and it definitely does not work if you
using the DirectFB backend. Simply replace the function
mng_refresh_callback() in gtk-mng-view.c with the following code and it
will work just fine:
static mng_bool
mng_refresh_callback (mng_handle mng_h,
mng_uint32 x,
mng_uint32 y,
mng_uint32 width,
mng_uint32 height)
{
gtk_widget_queue_draw_area (GTK_WIDGET (mng_get_userdata (mng_h)),
x, y, width, height);
return MNG_TRUE;
}
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: WebKit on webkit.gtk.org
Hi, On Thu, 2009-02-19 at 21:00 +0100, Christian Dywan wrote: I'm one of the WebKitGtk fellows and one thing we are missing currently is a place on the web, where you can find releases, docs and whatnot. Indeed. I have found it very difficult to locate information about WebKitGtk. So we had the idea, webkit.gtk.org would be a good domain. Sounds like a very good idea to me. Given that no one disagreed, you should probably just try to get in contact with Shawn Amundson. He has always been very helpful and should at least be able to install a DNS entry for you. Sven PS: What is the state of WebkitGTK on the Windows platform? It would totally rock if we could finally ship the GIMP help browser with the GIMP installer for Windows. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: regarding animated mng support in gtk for directfb
Hi, On Wed, 2009-03-04 at 21:12 +0530, Monil Parmar wrote: Iam trying to give support for animated mng on gtk-directfb. Animated mng file is working fine with gtk-x11 background but with gtk-directfb background it loads only one frame of mng file. Can you help me regarding this. or Do you have any more information which you can share. If you could provide the code together with a test case, I might find time to check if I can reproduce your problem and perhaps find out what's going wrong. What version of GTK+ are you using? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkEntry memory vtable (to use non-pageable memory for passwords)
Hi, On Sun, 2009-03-01 at 01:01 +, Stef wrote: This leads me to wonder if perhaps the password entry control in GTK+ might fare better as a separate widget. There's an insane amount of if (entry-visible) in the code and alternate code paths for password entry. I definitely think so. GtkEntry is getting more and more complex recently and it seems like a bad idea to use such complex code for sensitive stuff like a password entry. IMO it would make sense to create a dedicated widget for this. Perhaps it is possible to share a common base class, but we should try to keep all the complex stuff that is not needed in a password entry out of it. So perhaps as a start, try to make a list of the features that are needed, or might be useful, in a password entry? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkEntry memory vtable (to use non-pageable memory for passwords)
Hi, On Sun, 2009-03-01 at 14:47 -0500, Matthias Clasen wrote: Some of the recently added new features are specifically for password entries, like the caps lock warning. Great, so if we had a GtkPasswordEntry, these features would not have to live in GtkEntry. That's even better. A password entry looks just like a regular entry, and people expect to be able to use the features they know from other entries. I really don't think using a 'dumbed down' GtkEntry for passwords is the way forward (which is what started this discussion in the first place...). Finally, it seems a bit silly to use a memory locked entry for your keyring password, when all the other passwords you enter (login screen, lock dialog, your online banking website) don't. Why couldn't all password entries use the GtkPasswordEntry eventually? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_hash_table_new with size parameter
Hi, On Sat, 2009-02-21 at 21:42 +0300, Кутейников Дмитрий wrote: Can you make function like g_hash_table_new, but with size parameter? It would be great if GLib could allocate certain piece of memory when creating hash table, because I know average elements count which my program will keep in it. Can you show us any profiling / benchmarks that indicate that such an API would make a noticeable difference in a real-world application? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
status of the DirectFB target in GTK+
Hi, I have committed a couple of patches to gtk+ trunk today and merged all of them to the gtk-2-14 branch. These commits resurrect basic functionality of the DirectFB GTK+ backend. There are still issues, quite a few things don't work correctly. But so far I haven't seen any crashes in the few tests I did. I'd very much appreciate more people testing this and reporting problems at bugzilla.gnome.org. Most appreciated are of course patches that fix the remaining issues. I won't be able to deal with these problems myself. But I can help to get your patches committed. You can get an overview of the commits in the ChangeLog: http://svn.gnome.org/viewvc/gtk%2B/trunk/ChangeLog?view=markup If you want to test this, I suggest that you checkout the gtk-2-14 branch as it is less demanding in its dependencies compared to trunk: svn checkout http://svn.gnome.org/svn/gtk+/branches/gtk-2-14 Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Hi, On Mon, 2008-12-22 at 16:44 +0100, Alberto Garcia wrote: However, there is a performance problem with private attributes (if you use g_type_class_add_private()) that don't exist in other languages, as GObject's g_type_instance_get_private() can be noticeably slow. That can easily be optimized away by keeping an opaque pointer to the private struct in your public object struct. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ on DirectFb (sample example fails with DirectFb/Fbdev Caught Signal 11)
Hi, On Fri, 2008-12-19 at 16:54 +0100, Christian Dywan wrote: The latest Gtk+ for DirectFB is broken because nobody who uses DirectFB stepped up to bring it back in shape. I've seen countless attempts at using it but nobody who was up to fix it. As far as I know there's a set of patches from Denis Oliver Kropp, the main DirectFB developer, that are waiting to be merged to trunk. Denis sent his patches to this list on 16 Feb 2008. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gio-standalone fails to build 'G_GNUC_PRETTY_FUNCTION'
Hi, On Sat, 2008-09-27 at 11:27 +0200, comicinker wrote: I'm trying to build the svn version of gio-standalone (Rev 761) on a Ubuntu Hardy machine. I receive following error message: make[3]: Entering directory `/home/comic/zzz_unindexed/gio-standalone/trunk/gio' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -DGIO_MODULE_DIR= \/usr/local/lib/gio/modules\ -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_LOG_DOMAIN=\GIO\ -DG_DISABLE_DEPRECATED -DDBUS_API_SUBJECT_TO_CHANGE-Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith-Wcast-align -Wsign-compare -g -Od.a2 -Wno-strict-aliasing -Wno-sign-compare -MT test-streams.o -MD -MP -MF .deps/test-streams.Tpo -c -o test-streams.o test-streams.c test-streams.c: In function 'test_memory_input_stream': test-streams.c:74: error: 'G_GNUC_PRETTY_FUNCTION' undeclared (first use in this function) G_GNUC_PRETTY_FUNCTION is deprecated since GLib 2.16 and you are compiling with G_DISABLE_DEPRECATED. The code should be changed to use G_STRFUNC instead. And the configure script should have a check for the GLib version and not use G_DISABLE_DEPRECATED for newer versions of GLib. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 52, Issue 27
Hi, On Sun, 2008-08-17 at 13:54 -0300, Henrique Carvalho Alves wrote: The problem here is that Quick brown fox... doesn't make sense in any language. Lorem ipsum... also doesn't make sense for someone who doesn't know it's a dummy text. A common user would just popup the dialog and say What means that? I can't read english/latim/whatever!. Some users might even get offended. So I tough using the font name and size is random enough to provide a preview with glyphs, spacing and numerals; is a short text; makes sense inside the context; makes sense for international users; is visually informative, as displays meta-information (the font you selected in the font itself). Do you know any case were displaying with the font name would be a problem? Imagine you are working in a western locale and selecting a font to write text in arabic. The font you are looking for does most likely not even provide the glyphs to render its name (as the font name will be shown in your current locale). Another example is a symbol font. It typically doesn't include any letters. Using the font name for preview does not work. You could try to add some heuristics that select a reasonable text depending on font coverage. But that is likely going to fail in some corner cases. So whatever you end up doing, you should give the user a way to change the text used for preview. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Justifying the GTK+ 3.0 ABI break
Hi, On Tue, 2008-07-15 at 20:22 -0400, Morten Welinder wrote: It really is the elaborate deprecation (as opposed to simply dropping in a comment and not maintaining the code any more) that is causing the burden. That's what the log say -- assuming gtkclist is representative -- which I would guess it is. It is not representative. GtkCList is long deprecated, and there's a working replacement for it. It is basically just kept around for backward compatibility. What is really a burden is how difficult it is to add new features to widgets that are still being used. And that's because forward compatibility has not always been considered well enough in the past. From what I understand the GTK+ developers are now trying to eliminate that mistake. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: change font size on *with_label
Hi, this mailing-list is about developing GTK+, not about developing applications with GTK+. If you have questions on how to use GTK+, please ask them on gtk-list or gtk-app-devel-list. Thanks. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
Hi, On Wed, 2008-04-16 at 11:23 -0700, Brian J. Tarricone wrote: 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. Which is exactly what the current GTK+ Print preview code on Mac OS X does by default (if you are using the native build), see bug #518624. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkclipboard.c
Hi, On Mon, 2008-03-31 at 00:49 -0400, Yu Feng wrote: In order to make a blocked operation, the main thread(thread 0) spawns a new thread(saying, thread 1) to wait for the callback. There are no threads being spawned here. g_main_loop_new() doesn't spawn a thread. Of course I may have missed something, but the code looks perfectly safe to me. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Query regarding drawing gtk_draw_rectangle API
Hi, this list is about development of GTK+, not about developing applications using GTK+. Please ask such questions on gtk-list. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: hardware mouse acceleration
Hi, On Thu, 2008-03-27 at 16:17 +0300, Alexander Vasiliev wrote: Our embedded board can draw mouse pointer. So graphic library don't have to draw it and should only inform about position and image. Is there any posibility to use hardware accelerated mouse in gtk+ with directfb? Please consider to ask this on the directfb-users list instead: http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Hi, On Mon, 2008-03-17 at 12:42 +0200, Tor Lillqvist wrote: GIMP will continue to link in libpng, libjpeg, and etc., so that won't be affected by this regression. Yep. GIMP needs all the information it can get, especially for JPEG, where it needs to actually have a look at the quantization tables from the image file. This change would still break the thumbnailing system built into libgimpthumb. This code uses the PNG module from gdk-pixbuf to load and save thumbnails and it relies on the ability to read PNG text chunks from PNG images and to set the PNG text chunk when creating PNG files. So if you are taking away this functionality from the PNG module on the Windows platform, then this would be a major regression. It's also important to support the JPEG quality option on the JPEG save module. How is that handled in the GDI code? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: exporting _gtk_selection_request for selection manager use
Hi, On Tue, 2008-03-18 at 17:50 +0100, Alexander Larsson wrote: Load large spreadsheet, click select all, watch your eager clipboard manager suck down lots and lots of data, probably in duplicates converted to all possible data types the spreadsheet can convert to. And this may happen even for in-process cutpaste, greatly slowing it down and causing it to serialize all data. This is exactly what happens (or at least used to happen) when people run klipper or glipper and use GIMP. You are working on a large image and want to duplicate a layer, Ctrl-C, Ctrl-V. Within GIMP this is a copy-on-write operation and happens almost immidiately, even for large layers. If you have one of those misbehaving clipboard managers running, it will ask GIMP for this data in various formats and GIMP will be busy for several minutes dealing with this request. This is absolutely pointless as GIMP is a nice application and pushes the contents of the clipboard to the clipboard manager when it exits. All we really need is an implementation of the clipboard manager spec. And as far as I know gnome-settings-daemon does this. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: simple widget to draw on ?
Hi, On Tue, 2008-03-04 at 20:36 +0100, Sven Neumann wrote: Even if this is classified as a theme bug, it would still be nice to provide a simple way to draw without introducing an extra output window. If the patch attached to bug #519317 is accepted, GtkDrawingArea could serve this purpose. Xan Lopez added a comment to this bug-report asking that API should be added to get and set the NO_WINDOW mode like in GtkFixed. I don't think this is necessary as it would only duplicate GTK_WIDGET_SET_FLAGS(). But I would like to get another opinion on this... Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: simple widget to draw on ?
Hi, On Wed, 2008-03-05 at 07:20 -0500, Owen Taylor wrote: GTK_WIDGET_SET_FLAGS is protected API; also there is no way a GUI builder would know what widgets you could toggle into no-window mode, and no way to express set the NO_WINDOW flag in GtkBuilder. And no notification or handling of it when the widget is already realized. OK, I see your point and will change the patch accordingly. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: simple widget to draw on ?
Hi, On Sun, 2008-03-02 at 13:33 -0500, Havoc Pennington wrote: I would maybe not add a new widget for this, but instead make GtkDrawingArea have a no-window mode. If you look at the GtkFixed source, it has conditional branches in realize() and size_allocate() depending on whether NO_WINDOW is set. DrawingArea could work the same way, seems like it would be a trivial patch. That's a very nice idea. I have added a patch along these lines to bug #519317. (Though, I also wonder if there's a bug in either the use of DrawingArea or the theme shown in your screenshot; looking at the gtk code, the drawing area's background should be set on theme change and on realize, so maybe someone is painting over the theme background in the expose handler, or the theme just fails to handle drawing area, or something.) I think the theme draws the notebook page in a lighter background color. The background of the drawing area is drawn in the default background color though. Even if this is classified as a theme bug, it would still be nice to provide a simple way to draw without introducing an extra output window. If the patch attached to bug #519317 is accepted, GtkDrawingArea could serve this purpose. It would have to be documented, but I can take care of that. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
simple widget to draw on ?
Hi, I have come across this several times in the past and I am wonderding if GTK+ is missing a simple widget that does nothing else providing a space to draw on in an expose-event callback. Look for example at bug #519317: http://bugzilla.gnome.org/show_bug.cgi?id=519317 The Print dialog wants to draw an image using Cairo. It does this currently using a GtkDrawingArea. This has the disadvantage that GtkDrawingArea has its own output window. So the patch I attached to this bug-report changes the code to use a GtkEventBox. Somewhat better as the drawing will now be done on the background window. A GtkEventBox does however have an input window which is completely unnecessary here. Shouldn't GTK+ provide a really simple output widget for this use case? I would just instantiate a GtkWidget, but GtkWidget is abstract. Am I missing something obvious? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Proposal] Helper functions in GTK+ for showing help and URIs
Hi, On Tue, 2008-02-19 at 23:06 +0100, Jaap A. Haitsma wrote: Thanks for your comments. I've incorporated them (see attachment) If there is consensus that these functions should be incorporated in GTK+, I can add documentation and prepare a patch for GTK+ trunk Will these functions do the right thing on Windows and Mac OS X ? If they are only going to work correctly on Linux or even on a GNOME desktop, then they should not be added until this has been figured out. If the functionality is reasonably well supported on the major platforms, then I am all for adding this API. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: More patches
Hi, On Thu, 2008-01-31 at 06:06 +0100, Denis Oliver Kropp wrote: gdk-directfb-cleanups.patch Applied. gdk-directfb-copy-to-image.patch Applied. gtk-add-glib-libs-to-executables.patch This was a scary build issue. I installed glib, pango and gtk, but kept using my system's atk. When gtk-query-immodules-2.0 was built it failed to link as it missed a lot of new functions in the glib, e.g. glib_checksum_new(). I found out that it somehow tried to link against my system's glib, though using pkg-config the correct new glib was returned. Not sure if it's libstuhl or just the order on the linker command line, but adding $(GLIB_LIBS) explicitly did the trick. I did not apply this one as it affects other backends as well. Will leave it up to the GTK+ developers to decide if this is the right thing to do or not... Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Patch
Hi, On Wed, 2008-01-30 at 00:31 +0100, Denis Oliver Kropp wrote: this is the first of more patches coming up these days. I have applied this patch to SVN on your behalf. Will look at your other patch next... Mike was asking for someone to take over the project recently, wasn't he? After seven years of more and more abandoning it, I'd be happy to have it back and make it something great(er) :) I guess you should get SVN commit access then. You have my approval for that, but we will need someone from the core GTK+ development team to back this. Too bad noone could tell me about the simpler Quartz implementation so far. It seems a lot of the recursion with invalidation, clipping, lots of paint events etc. could be avoided. As far as I know the Quartz backend is not fully functional yet. Please keep that in mind. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTKDFB Debugging Patch
Hi Dok, On Wed, 2008-01-30 at 03:11 +0100, Denis Oliver Kropp wrote: here's another patch. It adds debug messages using DirectFB's debugging system I have applied this to trunk as well. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] example for gtk-demo demonstrating offscreen-rendered widgets with reflection-effect
Hi, On Sat, 2007-12-22 at 21:22 +0100, Mirco Müller wrote: + color[0] = (gdouble) style-bg[GTK_STATE_NORMAL].red; + color[1] = (gdouble) style-bg[GTK_STATE_NORMAL].green; + color[2] = (gdouble) style-bg[GTK_STATE_NORMAL].blue; + color[0] /= (gdouble) 0x; + color[1] /= (gdouble) 0x; + color[2] /= (gdouble) 0x; + cairo_set_source_rgb (cr, color[0], color[1], color[2]); You probably want to use gdk_cairo_set_source_color() instead. Sven ___ 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()
Hi, On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm Sven ___ 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()
Hi, On Tue, 2007-12-18 at 17:14 -0600, Federico Mena Quintero wrote: char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. No, because then you'll have applications using either, and then someone will want to make them consistent and we'll get an option in the control center an an XSETTING, which is yet another thing we'll have to port over when moving from GConf to DConf, and it's just a big fat mess. Yes, because this is a choice that the application developer needs to make, not the user. So this is never going to become am option in the control center or an XSETTING. We just need to make sure that the API docs give the application developer the information they need to make the right choice. Back to my original question: should this function be called g_format_size_for_display()? It's not for files only. Yes, we all seem to agree that this function is useful for other things than file sizes. But we should try to get it right. Otherwise it is simply not going to be used and we force application developers to invent their own function. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk on Embedded Device Query
Hi, this mailing-list is about development of GTK+. Please don't ask questions here that about developing applications with GTK+. We have gtk-app-devel-list and gtk-list for this. Thanks. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Hi, On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: We stronlgy suggest to use a common g_io/GIO prefix for all functions/types in GIO. GAsnc*- GIOAsync* G*Stream - GIOStream* GIcon - GIOIcon G*Icon- GIOIcon* GCancellable - GIOCancellable I strongly agree with Mitch here. Having a common prefix would help a lot to keep the GLib API structured. Also, subclasses should probably append their name, not prepend it: GFilterOutputStream - GIOOutputStreamFilter GUnixOutputStream - GIOOutputStreamUnix Yes please. This is perhaps not close to the human language, but we are talking about an API here. I really like to see all output stream classes listed together and this naming convention achieves this automatically. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: PLS HELP-URGENT...Error in running GTK application on MIPS board using GTK+ over DirectFB
Hi, these questions are better asked on the directfb-user list. They are not really specific to GTK+ and you are more likely going to get an answer there. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] GDK-DirectFB Patches
Hi, On Thu, 2007-12-06 at 13:15 +0530, RENY PAUL wrote: Thanks for the patch. I have applied all the patches including the hacks. Could you please back out the hacks again? Denis asked you explicitely not to apply them and if the hacks are causing problems in gtk-demo, as you said, then they should definitely not go in. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk on Embedded Device Query
Hi, On Thu, 2007-11-29 at 19:44 +0530, Saroj Kumar wrote: Anyhow I have to use this system for my application. I agree that this system is having slow processor speed. But lower than this configuration, processors running on mobile devices performing well in terms of GUI. So, I thought gtk+ (gtk-directfb) will help me in this. GTK+-DirectFB is only a solution if the graphics chips you are using is supported by DirectFB. DirectFB has software fallbacks that allow it to run on all kind of hardware, but if you want to use it on an embedded device than you first need to make sure that the graphics hardware is fully supported by DirectFB. If it isn't, and you don't have the resources to develop a graphics driver for it, then you might have more luck with other backends such as X11. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Tue, 2007-09-25 at 08:16 -0400, Jody Goldberg wrote: Undo comes with Redo, which is sufficient information to make a replay a modification from a known state. Not necessarily. A common approach to Undo/Redo is to store the information before the operation on the undo stack. Then, when the user decides to undo, you push the information at this point to the redo stack and undo by going back to the saved state. This allows you to Undo and Redo, but it is not sufficient information to replay a modification from a known state. Not unless you actually reached this point by undo operations. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Mon, 2007-09-24 at 09:23 -0400, Jody Goldberg wrote: The 'transaction' refered to a mechanism for persisting the details of each operation to a file. 1) The options could be re-played in the case of failure. 2) The data would provide useful hooks for auditing and validation. This would certainly be useful but it is something different than an Undo system. An undo system stores information on how to undo an operation. This typically involves storing data and state information from before the operation is performed. This information allows you to undo the operation, but it typically doesn't allow you to replay it. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote: I've had an undo framework in Marlin for years now, but recently people have been using it in other things (notably Ross in Tasks - ok, actually, he's the only one) and we discussed suggesting this for inclusion in GTK at some point in the future. Please consider to add the basic parts to GLib. Otherwise applications with a strict separation of functionality and user interface will be unable to use your undo framework. The basics should go into GLib. UI code such as GtkActions built from undo objects can go into GTK+. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
Hi, On Fri, 2007-09-21 at 17:51 +0100, Iain * wrote: The basic concepts are that there is an UndoManager object. When you start an operation that can be undone you call undo_manger_context_begin and this returns a UndoContext. Each part of your operation then creates an Undoable setting the functions that undo, redo and destroy it and set some userdata which contains enough information to undo/redo it. These Undoables are then added to the UndoContext. When the operation is finished you call undo_manager_context_end which adds the operation to the undo/redo stack. This sounds similar to the undo system that we use in GIMP. I haven't looked at your code, but it appears to me that your system is somewhat less flexible. Do you allow nested undo groups? This is rather important if you want to compose actions from smaller actions and still allow scripts or other higher levels to combine these into a single undo step. We make heavy use of nested undo groups in GIMP. I am not trying to argue that the GIMP undo system would be suitable for use anywhere outside GIMP. But we might want to adopt a more general undo framework if it is provided by GLib/GTK+ and allows us to implement everything that our current undo system allows us to do. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Hi, On Fri, 2007-06-22 at 10:27 +0200, Tim Janik wrote: so far, my take on the issue is that PyGtk should adapt to that change by not using tooltips-tips_data_list I have attached a patch to http://bugzilla.gnome.org/show_bug.cgi?id=449318 that removes access to private GtkTooltips struct members from the pygtk bindings. I can't tell if this will break any PyGTK apps but I guess that these bindings have only been added for the sake of completeness. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Menu groups vs. use of separators
Hi, On Thu, 2007-06-14 at 03:26 +0100, Alex Jones wrote: I've been looking at how Rhythmbox allows plugins to manipulate menus (via UI manager magic), and it dawned on me that there is no way to separate these out visually, other than to attempt to guess whether there should be a separator placed above and/or below what you're trying to insert. Of course, what I really want GTK to do is to insert separators *between* groups of menu items. Having this kind of ability would greatly simplify much goofy logic that is currently in place in a lot of applications to decide where separators should be placed. You can already do that using GtkUIManager. Your application should add placeholders for the groups that you described. Then add separators between the placeholders. Plug-ins can then register in the placeholder items. The smart separators will only be shown when needed. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk frame printing
Hi, this list is about development of GTK+, not about using GTK+ to develop applications. Please ask your question on gtk-list. Thanks. Sven PS: Have a look at gdk_pixbuf_get_from_drawable(). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: how to constrain the cursor in just one screen.
Hi, this mailing-list is about development of GTK+. Please ask your question on gtk-list or gtk-app-devel-list. Thanks. Sven PS: Take a look at the confine_to parameter of gdk_pointer_grab(). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Newbie needs help: gtk_entry's stopped accepting key stroke entires
Hi,
On Tue, 2007-05-08 at 10:46 -0700, crazyluke wrote:
This code was working as a key event handler:
static int key_pressed3(GtkWidget* w, GdkEventKey* event, gpointer data) {
if (event-keyval == 65293)
actionOptions(w, data);
return true;
}
Your code returns TRUE from the event handler. This stops signal
emission and keeps other handlers from being invoked. Check the
documentation of GtkWidget::key-press-event (or any other event signal
handler).
BTW, this would have been more appropriate to ask on gtk-list or
gtk-app-devel-list as this list is about development of GTK+, not about
development using GTK+.
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
Hi, On Wed, 2007-05-09 at 14:06 +0200, Kristian Rietveld wrote: Currently this behavior is inconsistent in GTK+, as the GtkListStore and GtkTreeStore still emit row-deleted *after* deleting a node. For the sake of consistency I would like to modify both models to also emit row-deleted before deleting a node. This will also allow for other applications to release their references to objects in a model row before a row is really deleted. It does however change the behavior if you are iterating through the model, the row in the process of being deleted will still be visible, where it was invisible before. Wouldn't it make more sense to introduce a new signal row-delete and use that instead of changing the semantics of row-deleted? If that would have been done in the first place, then you wouldn't have said inconsistency now. But then I have to admit that I probably just don't know enough about the internals. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
Hi, On Tue, 2007-03-13 at 07:52 +, Ross Burton wrote: As the arguments are a list of (PangoAttrType, value) tuples would it makes sense to terminate with PANGO_ATTR_INVALID (which is 0), rather than -1? The current implementation allows both 0 and -1 to terminate the list. I don't have a strong opinion which one should be preferred but it would be nice if both could be accepted since that would make it easier for us to deprecate the gimp variant at some point. Behdad is probably right that this code should be in Pango. But it would still be convenient if GTK+ could wrap the call to pango_attr_list_new_something() into gtk_label_set_attr_list() or similar. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: convenience API for applying PangoAttributes to a GtkLabel
Hi, On Mon, 2007-03-12 at 18:44 -0400, Behdad Esfahbod wrote: Feel free to file a bug. I have filed bug #41 against Pango. I might want to file another bug against GTK+ later and let it depend on the Pango bug. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
convenience API for applying PangoAttributes to a GtkLabel
Hi, libgimpwidgets includes an API for conveniently apply PangoAttributes to a GtkLabel and I wonder if I should propose it for inclusion in GTK+: http://developer.gimp.org/api/2.0/libgimpwidgets/libgimpwidgets-GimpWidgets.html#gimp-label-set-attributes It is IMO more convenient than using g_strdup_printf() to embed a string into PangoMarkup. Here's a short example to make a label large and bold: gimp_label_set_attributes (GTK_LABEL (label), PANGO_ATTR_SCALE, PANGO_SCALE_LARGE, PANGO_ATTR_WEIGHT, PANGO_WEIGHT_BOLD, -1); The implementation can be reviewed in http://svn.gnome.org/viewcvs/gimp/trunk/libgimpwidgets/gimpwidgets.c?view=markup Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why file system abstraction layer in GTK+ is only private stuff?
Hi, On Tue, 2007-02-13 at 23:39 +0100, Tomasz Jankowski wrote: Maybe you should think about public support fre some file system and add it in one future releases? I know, that file system support is quite far from GUI, so maybe it can be good idea to move it to GLib or even create independent library? Maybe you should search the mailing-list archives before posting? There has been a very detailed thread about this topic only a few months ago. Look for Plans for gnome-vfs replacement. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: directx gdk backend?
Hi, On Sat, 2007-02-10 at 06:35 -0600, Michael Lawrence wrote: Since MS is putting all of its efforts into DirectX now, would it make sense to move to that for drawing? Does it even make sense to still look at GDK drawing performance when most (or at least more and more) drawing is done via Cairo nowadays? It occurs to me that it would make more sense to put that effort into optimizing Cairo on the target platform. But first of all one should do some benchmarking and profiling to find out what operations are actually slowing down real-world applications. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What is the proper way of markig translations of static array initializers
Hi, On Wed, 2007-02-07 at 01:06 +0200, Alexander Shopov wrote: Hi guys, The docs: http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html state that N_() Marks a string for translation, gets replaced with the untranslated string at runtime. This is useful in situations where the translated strings can't be directly used, e.g. in string array initializers. How to add the addorning prefix in similar cases? (Like using Q_()). This message would have better been asked on gtk-list or even gnome-i18n. This list is about development of GTK+, not development using GTK+. Short answer: Use N_() to mark the string (with context) and use g_strip_context() in combination with gettext() to translate the string where it is being used. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: alternative button order: Why don't we auto-guess the alternative order by default if appropriate?
Hi, On Fri, 2007-01-05 at 14:25 +0100, Christian Neumair wrote: I'm mainly asking because in 99% of the cases one wants the alternative order to be reverse from the original order I haven't found a definitive source for this, but as far as I know, your assumption breaks as soon as a third button is added. Then the typical alternative order is not the reverse of the original one. See this example: standard: [Reset] [Cancel] [OK] alternative: [Reset] [OK] [Cancel] I might be totally wrong here, but that's how we are arranging the buttons based on feedback from Windows users. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Depth related assertion in gdk_drawable_set_colormap()
Hi, On Thu, 2006-12-14 at 11:10 +0530, Karunakaran A wrote: We are getting some depth related assertions at time of running mozilla over gtkDFB port. The assertion is coming for the following functions: -- pixmap = gdk_pixmap_new(NULL,x,y, gdk_rgb_get_visual()); gdk_drawable_set_colormap(pixmap, gdk_rgb_get_colormap()); -- It says the depth of drawable is not equal with the depth of colormap. any suggestions or any example code through which we can solve it?? What about using a debugger, setting a breakpoint or using --g-fatal-warnings, locating the problem, fixing it and submitting a patch (if it turns out that the problem is in gdk-directfb)? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk_gc_set_foreground(): not working over DirectFB
Hi, On Mon, 2006-11-13 at 14:40 +0530, Prasanna Kumar K wrote: + GdkColor color; + + color.pixel = 0x; + gdk_gc_set_foreground (widget-style-fg_gc[GTK_WIDGET_STATE (widget)], color); You are using an unallocated color here. There's gdk_gc_set_rgb_fg_color() for that purpose. Kalle already outlined other issues with this code in another mail so I am not going to comment on the fact that it is a bad idea to access the widget's style directly. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Color problem on GTK-DFB applications
Hi, On Tue, 2006-11-14 at 11:03 +0530, Prasanna Kumar K wrote: + color.pixel=0x; If I remember correctly, the DirectFB GDK backend doesn't care about the pixel member of GdkColor. It requires you to fill in the red, green and blue members of the GdkColor. The pixel member is an implementation detail of the X backend. As far as I know it is considered wrong to use it directly as you are then making assumptions about the X visual. Leave it up to the color allocation routines to fill in the pixel value and your code will also work on DirectFB. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reloading keymap under DirectFB
Hi, On Thu, 2006-08-31 at 11:35 +0200, Attilio Fiandrotti wrote: With the DFB backend i recently experienced the need to force reload of keymap and i did it by calling directly a DFB function from my GTK app code. Mike Emmel suggested to add something like gdk_directfb_reload_keymap() to the GDKDFB backend, as this seems to be a generic problem. Any suggestion about other ways keymap reloading could be done? Why is reloading the keymap needed in the first place? I suggest that this is fixed in DirectFB instead of adding an API for the sole purpose of working around what appears to be a bug in DirectFB. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Looking beyond 2.10
Hi, On Thu, 2006-06-22 at 15:28 +0100, Joachim Noreiko wrote: I feel like I'm talking to myself here, but please could someone look at adding a help button to the fileselector. GIMP has done that for quite a while already, so there's nothing that would keep an application from adding a Help button to the file-chooser. What's the point of adding one by default? By default it won't be connected to anything useful and what good is a help button that does nothing when the user clicks it? Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Question about GdkColor
Hi, yeajchao [EMAIL PROTECTED] writes: In general,the RGB color mode ,the red or green or blue's value is from 0 to 255 But ,the GdkColor ,the value is from 0 to 65535 My question is ,how to map (0--255) to (0--65535) r = ((r 8) | r); g = ((g 8) | g); b = ((b 8) | b); Sven ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Recently Used Files Proposal
Hi, Emmanuele Bassi [EMAIL PROTECTED] writes: That's it. Very simple, very common. Currently, I can open one menu (Places-Recent Documents) and 'solve' that user problem. What if you have more than one document with the same name? The menu item should have a tooltip with the full filename. What if one is a copy you keep on a network share? What's the problem? What if you want to open a document you edited some time ago (but not too long), and it went out of the menu? The menu should feature an item at the bottom that allows the user to open the GtkRecentChooserDialog that you suggested. That gives access to not so recently used items w/o taking away the possibility to access very recently used items as quickly as possible. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Gimp-developer] Compiling a gimp plugin for Windows
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: How, exactly? Because the procedure for person doing a release would be a few steps longer? Or because people would wonder why each other version is missing when looking at some version history or ftp server directory list? How are people supposed to know about this versioning scheme? Not all packages will use it; so how is a user supposed to know that even is stable, odd is some cvs snapshot? What about using something like gimp-2.2.8-cvs-20050523.zip for cvs snapshots? Well, for Win32 distributions of GIMP stuff, where such files are handled manually, and/or people have out-of-band knowledge that 2.2.8 wasn't released yet at 2005-05-23, that presumably is clear enough. But if one considers various Unix/Linux package management software, do they understand that for some packages 2.2.8-cvs-20050523 is earlier than 2.2.8, but on the other hand, for some other package, 1.2.3-cvs-20050523 would be later than 1.2.3 ? Well, then don't include a version number at all. That's how CVS snapshots are typically labelled, by nothing but the date. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common Save Confirmation Dialogue
Hi, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] writes: Even SDI applications usually support multiple windows served by the same process, where File-Exit quits the application by closing all windows. Since each window contains one document, on File-Exit you may have to confirm saving multiple documents. And it's annoying to have to confirm saving documents several times in sequence. True. But still I doubt that you can come up with a widget that works for all applications. If I look at the code of the Quit dialog in GIMP, it is highly GIMP specific. The Save confirmation dialog however that is shown if a single image window is closed, could very well be provided by GTK+. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common Save Confirmation Dialogue
Hi, Marc O'Morain [EMAIL PROTECTED] writes: Applications that support multiple documents in the one process (such as GIMP) are actually MDIs. An example of a true SDI is something like Inkscape or GPDF. Inkscape does actually allow you to open multiple documents in the same process. It is not a good example for true SDI. The point of adding this would be to replace all the code in SDI applications that have a save confirmation dialogue box with a single GTK call. Removing code from applications like this makes them faster and easier to write, easier to read and maintain, and the binary would be smaller. I don't know how this would affect the GTK binary - whether the save confirmation code would be shared across running applications or loaded once per application. I don't think binary size is a compelling reason here. The main advantage is that the dialog will look and feel the same in all applications. The user will recognize the dialog which makes the app easier to use. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK framebuffer needed for the GTK debian installer
Hi, attilio [EMAIL PROTECTED] writes: I'm posting to this mailing list to ask you if some future development of the fb/dfb gdk are planned, since this would be the most appropriate gdk layer for a gtk-based debian-installer. As far as I know the DirectFB port is under active development and currently being ported to GTK+ CVS using cairodfb. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: JPEG, PNG, and TIFF
Hi, Hans Breuer [EMAIL PROTECTED] writes: AFAIK the only format really required (even at compile time of gdk-pixbuf following modules) is PNG, the GTK+ icon format. Since the standard icons are compiled in, you can even use GTK+ without the PNG loader but that's certainly only useful for corner cases such as embedded systems. And even on those, you will most likely want to be able to handle a couple of image formats. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkComboBox and GtkComboBoxEntry
Hi, Dru [EMAIL PROTECTED] writes: Under GtkCombo the dropdown list showed your currently selected item in the popup list. The new combo boxes dont do this, if you have a large list of it makes navigation a bit more difficult if you dont know what you had selected before. Is there anyway to get this behavour or suggestions of what code to modify to make this happen? The default behaviour is to show the selected item. Either your code is doing something wrong or your GTK+ theme is somehow broken. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: threaded balaced GTree in Glib
Hi, Maurizio Monge [EMAIL PROTECTED] writes: It looks like glib does not get much attention on this ml (i have sent a couple of patches for something i considered useful and got no answer, if you think my code is broken just tell me so :-) ). The preferred way to submit patches is to open a bug report and attach the patch there. Of course if you think that your patch needs to be discussed by a wider audience, then it is appropriate to do that here. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Introspection API
Hi, Mike Kestner [EMAIL PROTECTED] writes: One more wrinkle for params... It would be nice for string params to identify encoding when they are not in utf8 encoding, such as in the filename case. A case could probably be made for a GStringDef. Not sure if this is helpful, but we solved this in GIMP by adding a new param_spec derived from GParamSpecString: http://cvs.gnome.org/viewcvs/gimp/libgimpconfig/gimpconfig-path.h?view=markup http://cvs.gnome.org/viewcvs/gimp/libgimpconfig/gimpconfig-path.c?view=markup GimpConfigPath has a type enum that identifies it as a file or direcory path or a list of files or list of directories. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: UNC paths, glib, and the file chooser
Hi, James Henstridge [EMAIL PROTECTED] writes: Internet Explorer canonicalises UNC paths to URIs as file://hostname/share/path, while mozilla canonicalises to file:/hostname/share/path. While the IE path is a bit shorter, the five-slash version probably follows the specs better It's not only IE. GtkFileChooser on Win32 also seems to return file://hostname/share/path URIs for files in UNC paths. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
