Re: gnome canvas doesnt work properly on GTK-DirectFB
Hi Paul, k. So the fix you spoke about was in your application code and not in your GTK-quartz backend? CMIIMW. On Wed, Jun 11, 2008 at 8:04 PM, Paul Davis [EMAIL PROTECTED] wrote: On Wed, 2008-06-11 at 19:55 +0530, svalbard colaco wrote: HI all; Further debugging has shown that antialiased canvases formed using gnome_canvas_new_aa() appear correctly on GTK-DFB backend whereas canvases formed using gnome_canvas_new() fail to render on GTK-DirectFB ;rather they appear black instead of white. in which case, my previously mentioned issue is not relevant. and to be clear, my fix for that problem is not in any distributed version of GnomeCanvas or in any repository. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How do I disable automatic drag and drop between GtkEntry widgets?
I've finally discovered a workaround to my problem. It is not ideal, but it works for us for now. Unsetting the drag source and drag dest doesn't stop the effect, it just makes the drop not work anywhere. Returning TRUE to a handler for drag_begin seemed to do nothing. I effectively disabled drag and drop completely for the entire gtk application by setting the gtk-dnd-drag-threshold property to a value greater than the screen width. This works for me for now. If we ever need to do drag and drop in this application I will have to revisit this problem. After reviewing months of messages I found a few other people trying to disable this automatic drag-and-drop between entry widgets, but they didn't get any helpful answer, either. I hope that this workaround, though not a solution, may help some of those people. Kurt M. Bruhnke Rockwell-Collins Simulation Training Solutions ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk performance
Hi, i started to make an application in gtk. I have find on the web why gtk is slow and require much memory! Is true? Thanks Gerardo Di Iorio ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk performance
I have find on the web why gtk is slow and require much memory! Is true? If you read it on the web, it must be true, yes. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gnome canvas doesnt work properly on GTK-DirectFB
On Wed, 2008-06-11 at 19:55 +0530, svalbard colaco wrote: HI all; Further debugging has shown that antialiased canvases formed using gnome_canvas_new_aa() appear correctly on GTK-DFB backend whereas canvases formed using gnome_canvas_new() fail to render on GTK-DirectFB ;rather they appear black instead of white. in which case, my previously mentioned issue is not relevant. and to be clear, my fix for that problem is not in any distributed version of GnomeCanvas or in any repository. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gnome canvas doesnt work properly on GTK-DirectFB
On Wed, 2008-06-11 at 20:26 +0530, svalbard colaco wrote: Hi Paul, k. So the fix you spoke about was in your application code and not in your GTK-quartz backend? its in my own modified version of libgnomecanvas, which is distributed on OS X as part of the app bundle. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk performance
On Wed, 11 Jun 2008 17:37:46 +0200, G Hasse [EMAIL PROTECTED] wrote: On Wed, Jun 11, 2008 at 01:27:34PM +0200, Gerardo Di Iorio wrote: Hi, i started to make an application in gtk. I have find on the web why gtk is slow and require much memory! Is true? You must ask yourself - comparing to what? Java? QT? comparing to QT. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
how to get signal_changed on a TextView widget
Hi All, I'm replacing some Gtk::Entry widgets with Gtk::TextView widgets and the signal_changed method is not available -- how can I tell when the user changes the text in the TextView? Thanks in advance. -Garth ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk performance
On Wed, Jun 11, 2008 at 6:30 PM, Gerardo Di Iorio [EMAIL PROTECTED] wrote: You must ask yourself - comparing to what? Java? QT? comparing to QT. As Tor already pointed out, if you have read it on the web it _must_ be true. cheers -- Gian Mario Tagliaretti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How do I use the fullscreen in a gtkmm app?
Hi All, I notice that quite a few apps (firefox, gimp, terminal, etc. -- but not gedit, huh?) have the option to toggle fullscreen mode in their view menu using the F11 key. How would I implement this in my Gtkmm app? Thanks in advance -Garth ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk performance
Gian Mario Tagliaretti escribió: On Wed, Jun 11, 2008 at 6:30 PM, Gerardo Di Iorio [EMAIL PROTECTED] wrote: You must ask yourself - comparing to what? Java? QT? comparing to QT. As Tor already pointed out, if you have read it on the web it _must_ be true. cheers http://www.wikivs.com/wiki/Qt_vs_GTK -- Regards. Martin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk performance
Gerardo Di Iorio wrote: Hi, i started to make an application in gtk. I have find on the web why gtk is slow and require much memory! Is true? Yes, no, maybe. From my experience, speed is really divided into two things: perception and throughput. On the perception side of things, sometimes end users perceive GTK as slow due to things like flicker during refresh, or widgets that redraw too many times during a resize. These are issues that have been addressed and are being addressed. Some of the perception issues have a lot to do with the asynchronous nature of X11, or due to the way GDK was implemented on windows (windows don't redraw while being moved on windows xp, for example). If the problem is X11, then Qt will exhibit it also. Things like double buffering and the new X11 synchronization protocol help with flickering. As for throughput, you'll need hard numbers to make any judgments there. And it all depends on what you are doing too. From what I've seen, GTK is probably faster and light than Qt. Signal propagation is known to be faster, and in general, GTK is pretty quick, at least as fast as Qt. I highly doubt GTK takes up much memory compared to Qt either. Frankly there are lots of reasons to choose one toolkit over the other but simply slow or much memory are not initially valid reasons. Rather ease of development, the richness of the widgets, the ability to rapidly generate good, usable interfaces, and other factors are much, much more important to you as a developer. Whether or not and end user thinks your program is slow often depends on how badly you've set up the interface! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How do I use the fullscreen in a gtkmm app?
Garth's KidStuff wrote:
Hi All,
I notice that quite a few apps (firefox, gimp, terminal, etc. -- but not
gedit, huh?) have the option to toggle fullscreen mode in their view menu
using the F11 key. How would I implement this in my Gtkmm app?
Connect the key_press_event to your top window, ot to a drawing area,
and then prepare a callback along these lines (sorry, C code):
#include gdk/gdkkeysyms.h
void function_handle_key_press (GtkWidget *widget,
GdkEventKey *event, void *data)
{
GtkWidget *window = (GtkWindow *) data; /* this is just a simple example */
static int fullscreen = FALSE;
switch (event-keyval)
{
case GDK_F11:
if (fullscreen == FALSE)
{
gdk_window_raise (window-window);
hide decorations;
gtk_window_fullscreen (GTK_WINDOW (window));
fullscreen = TRUE;
}
else
{
show decorations;
gtk_window_unfullscreen (GTK_WINDOW (window));
fullscreen = FALSE;
}
break;
}
Thanks in advance
-Garth
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: new object, with variables
2008/5/14 Kees Scherpenhuijzen [EMAIL PROTECTED]:
heyy,
@ the moment i trying to make an object inherited from GTK_ACTION,
this all is managed.
Only now i'm trying to initialize the object with an variable, a
struct. Ie read the manual about the wrapper that is used, only i
can't seem
to find a way in which i can add the struct to g_object_new or otherwise.
to be clear, in this function:
GtkAction*
menu_action_new (const gchar *name,
const gchar *label)
{
GtkAction* action;
_thunar_return_val_if_fail (name != NULL, NULL);
_thunar_return_val_if_fail (label != NULL, NULL);
action = g_object_new (MENU_TYPE_ACTION,
hide-if-empty, FALSE,
label, label,
name, name,
NULL);
return action;
}
i want to add the struct so i don't need any get of set functions, is
this possible?
the thing i want to do is to init :
menu_thing*item;
in:
struct _MenuTemplatesAction
{
GtkAction __parent__;
menu_thing*item;
};
I hope this enough info to get me close to an answer
--
Kees
Hi,
I've saw some examples about this problem and tried it with no luck. i
saw that the object was cast and just added.
i've tried:
GtkAction*
menu_action_new (const gchar *name,
const gchar *label,
Model *model)
{
GtkAction* action;
_thunar_return_val_if_fail (name != NULL, NULL);
_thunar_return_val_if_fail (label != NULL, NULL);
action = g_object_new (MENU_TYPE_ACTION,
hide-if-empty, FALSE,
label, label,
name, name,
NULL);
MENU_ACTION(action)-items = model;
if(G_TYPE_FUNDAMENTAL (action) == G_TYPE_OBJECT)
{
g_message(model-menu-name);
g_message(action-items);
g_message(test);
}
return action;
}
but it seems the second g_message won't print, it gives an segmentation fault.
extra info: #define MENU_ACTION(obj)
(G_TYPE_CHECK_INSTANCE_CAST ((obj), MENU_TYPE_ACTION,
MenuTemplatesAction))
What am i missing here?
Thanks in advance
--
Kees
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Slow treemodel loading
Damien Caliste wrote: Hello, If I'm not wrong, you may be interested with gtk-list-store-insert-with-values() function: http://library.gnome.org/devel/gtk/unstable/GtkListStore.html#gtk-list-store-insert-with-values Thank you for your suggestion. The documentation is characteristically ambiguous, so I can't tell whether this function would solve the problem. The documentation says that the function does not emit the rows_reordered signal, but it does not say that the list store is not resorted. Perhaps suppressing the rows_reordered signal also suppresses sorting, but I don't find that crucial detail documented anywhere. In any case, insert_with_values does not appear to be available in PyGTK, which is what I am actually using. This problem with list stores seems serious to me, so I am surprised that Gtk suffers from it. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Slow treemodel loading
Jeffrey Barish wrote: Damien Caliste wrote: Hello, If I'm not wrong, you may be interested with gtk-list-store-insert-with-values() function: http://library.gnome.org/devel/gtk/unstable/GtkListStore.html#gtk-list-store-insert-with-values Thank you for your suggestion. The documentation is characteristically ambiguous, so I can't tell whether this function would solve the problem. The documentation says that the function does not emit the rows_reordered signal, but it does not say that the list store is not resorted. Perhaps suppressing the rows_reordered signal also suppresses sorting, but I don't find that crucial detail documented anywhere. In any case, insert_with_values does not appear to be available in PyGTK, which is what I am actually using. This problem with list stores seems serious to me, so I am surprised that Gtk suffers from it. a) hide the widget that displays the list store b) populate c) show the display widget. I have encountered this exact same problem in an application I am developing. Unless you are dealing with more than 200,000 rows or so, the sort time is negligible compared to the amount of time to do the computations required to determine what is visible and update the display every time you insert a new row. My current application deals with about 103,000 rows - and the difference was easily 2 orders of magnitude. I use a progress bar on the bottom of the window in question to display the progress bar so that the user (me) doesn't freak when the display seems to freeze. Another alternative would be to change the sort column of your tree to a column that does not have a sort function associated with it. In that case, you set the column, populate, reset the column, and away you go - the sort would only be done once at the end, instead of every time you add a row. Hope something here helps. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gnome canvas doesnt work properly on GTK-DirectFB
On Wed, 2008-06-11 at 19:55 +0530, svalbard colaco wrote: HI all; Further debugging has shown that antialiased canvases formed using gnome_canvas_new_aa() appear correctly on GTK-DFB backend whereas canvases formed using gnome_canvas_new() fail to render on GTK-DirectFB ;rather they appear black instead of white. in which case, my previously mentioned issue is not relevant. and to be clear, my fix for that problem is not in any distributed version of GnomeCanvas or in any repository. ___ 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
[resending since the original reply somehow got lost] On Mon, 2008-06-09 at 09:44 +0200, Murray Cumming wrote: On Tue, 2008-06-03 at 13:34 +0200, Kristian Rietveld wrote: [snip] We should start to enforce the usage of single header includes and not make this optional. Mitch has been working on this and most is already in place in SVN trunk. [snip] What's the advantage of this? Has this been a real problem for GTK+ so far? Many people (particularly C++ developers) like to reduce pollution of the global namespace by including as few headers as reasonably possible. That can also reduce compile times (particularly for C++ developers). I described the reasons for this in the GIO API review thread here: http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00144.html All of them are also valid for GTK+, especially the need for maintaining compatibility of all possible combinations of includes as long as source compatibility is guaranteed. We simply do not want to give this completely unneccessary guarentee any more and therefore we will switch to forcing everybody to only include gtk/gtk.h starting with GTK+ 3.0. The -DGTK_DISABLE_SINGLE_INCLUDES method is simply a path of migration so you can prepare your code for that. ciao, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gnome canvas doesnt work properly on GTK-DirectFB
Hi Paul, k. So the fix you spoke about was in your application code and not in your GTK-quartz backend? CMIIMW. On Wed, Jun 11, 2008 at 8:04 PM, Paul Davis [EMAIL PROTECTED] wrote: On Wed, 2008-06-11 at 19:55 +0530, svalbard colaco wrote: HI all; Further debugging has shown that antialiased canvases formed using gnome_canvas_new_aa() appear correctly on GTK-DFB backend whereas canvases formed using gnome_canvas_new() fail to render on GTK-DirectFB ;rather they appear black instead of white. in which case, my previously mentioned issue is not relevant. and to be clear, my fix for that problem is not in any distributed version of GnomeCanvas or in any repository. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gnome canvas doesnt work properly on GTK-DirectFB
On Wed, 2008-06-11 at 20:26 +0530, svalbard colaco wrote: Hi Paul, k. So the fix you spoke about was in your application code and not in your GTK-quartz backend? its in my own modified version of libgnomecanvas, which is distributed on OS X as part of the app bundle. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [compiz] color management spec
Am 10.06.08, 17:56 -0400 schrieb Owen Taylor: On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote: Added gtk-devel-list@gnome.org to hear their opinion about this matter. For reference, this is what I proposed: http://lists.freedesktop.org/archives/xorg/2008-May/035772.html Danny Baumann wrote: Hi, I strongly dislike supporting subwindow ID/profile tuples. The task of window and compositing managers is and always has been to manage and draw _toplevel_ windows, not subwindows. I don't really think that adding a subwindow management infrastructure to compositing managers just for saving some lines of code in the toolkit (and not even all of them) is an overly good idea. It's not just for 'saving some lines of code in the toolkit'. Color management would require significantly more code in the toolkit and would most likely be slower then if it is done in the compositing manager. I was just talking about communicate using subwindow id/profile tuples vs. communicate using toplevel window region/profile tuples. The former would save a bit of code in the toolkit, but would complicate compositing managers significantly; which is why I strongly prefer the latter. The compositing manager would never actually draw subwindows, just merely use them to identify regions. When using properties on the top level window, the toolkit would have to explicitly update those whenever the window is resized. But when using subwindows, the toolkit (at least gtk) wouldn't have to do anything special. In gtk, each widget that uses a subwindow resizes it when the top level window is resized. The compositing manager would just subscribe to ConfigureNotify events of the subwindows and be done. If I was working on a new toolkit from scratch it would most likely have no subwindows, or a very, very limited use of subwindows. In the case where you do have subwindows, future toolkits will commonly act as compositing managers for their own subwindows, so a subwindow does not necessarily represent an integer-pixel-bordered region of the window. I have trouble seeing the idea of separate profiles for subwindows as being a good idea. There are also other problems like: - There's no easy way to get or be notified of changes to the clip region of a window in X. If a subwindow with a separate profile was partially obscured by another subwindow, the compositing manager would have trouble tracking that. - If there was inter-process embedding, the ID's of subwindows with separate profiles would have to be propagated up to the toplevel, which would be a pain. (You don't seem to have a WM_COLORMAP_WINDOWS equivalent, but one would be needed.) Are colour maps applicable in the range of this project? I'd guess that OpenGL cards with the necessary features for compiz would run almost always in a true visual mode? The _NET_COLOR_MANAGER client message also introduces a whole lot of complexity for toolkit authors. I assume that the problem you are trying to solve here is: A) Photo app has a embedded image in a wider-than-SRGB-colorspace plus some random toolbars B) You don't to convert the image to SRGB and lose gamut that the monitor might actually be able to reproduce C) Deploy a fast colour conversion path on the GPU rather than the CPU E) Manage the whole desktop at once, like it is displayed at once. While the suggestion of subwindow tracking is seductive, I don't think it really works out. So, you need to go with one of the other possibilities - either you export the monitor profile to applications and allow applications to mark windows as being in the monitor profile, or you put the whole window into the image colorspace. (Using the monitor colorspace obviously works better if there are multiple images with significantly different gamuts in the same toplevel.) Tagging the window with the image colour space will render in rather a mosaic of windows. The other suggestion is covered by the _ICC_PROFILE_xxx atom but misses a practical use case. Either way, this end up with the question ... how do you get a toolkit dealing with some non-SRGB colorspace? I don't have a full or sRGB: http://www.w3.org/Graphics/Color/sRGB.html is a special, close to a idealised monitor, colour space. We have nearly nowhere such devices. Toolkits typical display on real world devices which differ from sRGB. The sRGB would have to be supported by the drivers, which would introduce a rather big burden on them. One partitial answere are video LUT's, which are limited to neutrality management with several drawbacks. With any computational intensive approach, a system to indicate damage or request rerendering is a nice work load saver (XDamage?). The project of Tomas moves the necessary driver implementation to a higher layer and deploys hardware
Re: [compiz] color management spec
[ Intentionally not trimming quoting much due to various bounces from lists ] On Wed, 2008-06-11 at 09:05 +0200, Kai-Uwe Behrmann wrote: Am 10.06.08, 17:56 -0400 schrieb Owen Taylor: On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote: Added gtk-devel-list@gnome.org to hear their opinion about this matter. For reference, this is what I proposed: http://lists.freedesktop.org/archives/xorg/2008-May/035772.html Danny Baumann wrote: Hi, I strongly dislike supporting subwindow ID/profile tuples. The task of window and compositing managers is and always has been to manage and draw _toplevel_ windows, not subwindows. I don't really think that adding a subwindow management infrastructure to compositing managers just for saving some lines of code in the toolkit (and not even all of them) is an overly good idea. It's not just for 'saving some lines of code in the toolkit'. Color management would require significantly more code in the toolkit and would most likely be slower then if it is done in the compositing manager. I was just talking about communicate using subwindow id/profile tuples vs. communicate using toplevel window region/profile tuples. The former would save a bit of code in the toolkit, but would complicate compositing managers significantly; which is why I strongly prefer the latter. The compositing manager would never actually draw subwindows, just merely use them to identify regions. When using properties on the top level window, the toolkit would have to explicitly update those whenever the window is resized. But when using subwindows, the toolkit (at least gtk) wouldn't have to do anything special. In gtk, each widget that uses a subwindow resizes it when the top level window is resized. The compositing manager would just subscribe to ConfigureNotify events of the subwindows and be done. If I was working on a new toolkit from scratch it would most likely have no subwindows, or a very, very limited use of subwindows. In the case where you do have subwindows, future toolkits will commonly act as compositing managers for their own subwindows, so a subwindow does not necessarily represent an integer-pixel-bordered region of the window. I have trouble seeing the idea of separate profiles for subwindows as being a good idea. There are also other problems like: - There's no easy way to get or be notified of changes to the clip region of a window in X. If a subwindow with a separate profile was partially obscured by another subwindow, the compositing manager would have trouble tracking that. - If there was inter-process embedding, the ID's of subwindows with separate profiles would have to be propagated up to the toplevel, which would be a pain. (You don't seem to have a WM_COLORMAP_WINDOWS equivalent, but one would be needed.) Are colour maps applicable in the range of this project? I'd guess that OpenGL cards with the necessary features for compiz would run almost always in a true visual mode? WM_COLORMAP_WINDOWS is just an analogy; in the same way that WM_COLORMAP_WINDOWS identifies subwindows that have different colormap, you would need a property to identify subwindows with different color profiles. *If* you wanted to put color profiles on subwindows (something that I think is a bad idea.) The expense for the compositing manager to monitor all subwindows of each toplevel for property changes would be extreme. The _NET_COLOR_MANAGER client message also introduces a whole lot of complexity for toolkit authors. I assume that the problem you are trying to solve here is: A) Photo app has a embedded image in a wider-than-SRGB-colorspace plus some random toolbars B) You don't to convert the image to SRGB and lose gamut that the monitor might actually be able to reproduce C) Deploy a fast colour conversion path on the GPU rather than the CPU E) Manage the whole desktop at once, like it is displayed at once. While the suggestion of subwindow tracking is seductive, I don't think it really works out. So, you need to go with one of the other possibilities - either you export the monitor profile to applications and allow applications to mark windows as being in the monitor profile, or you put the whole window into the image colorspace. (Using the monitor colorspace obviously works better if there are multiple images with significantly different gamuts in the same toplevel.) Tagging the window with the image colour space will render in rather a mosaic of windows. I don't understand this. The other suggestion is covered by the _ICC_PROFILE_xxx atom but misses a practical use case. What use case? Either way, this end up with the question ... how do you get a toolkit dealing with some non-SRGB
gdkpixbufloader-API shortcoming
A small shortcoming in the gdkpixbufloader-API causes me trouble. The problem is this: Let's say my loader libpixbufloader-foobar can handle the two (very similar) formats image/x-foo and image/x-bar. Then an application identifies an image as either foo or bar it invokes my loader. But the loader has no way of telling if it's supposed to handle a foo-image or a bar-image. I guess that the idea is that the loader should be able to easy distinguish between the two formats by fingerprinting the first few bytes. But since both foo and bar lack a decent header that cannot be done. (I must stress that this is not a hypothetical problem but a very real one I have encountered more than once then writing loaders for obscure formats). The solution is some way for the loader to know why it was chosen. Either which mimetype or which extension (of those supplied by the loader) was a match. Perhaps just a function which could be called by the loader like: gdk_pixbuf_why_me(gpointer handle,gchar **matching_mimetype,gchar ** matching_extension); Or are there some plans for a totally new API for pixbuf loaders since I have seen some other shortcomings of the current one. Someone requested about the same thing as me (but for using an external library which already supported all image formats supported by gdkpixbuf and then some). Another thing mentioned is the one to one mapping between loader and image format which is bad then then saving images (even if the loader can distinguish between different variants then loading it does nothing for saving). A suggested solution (read ugly hack) was to duplicate all of the code for each format (or create a library which is called by a small wrapper for each format). But that is obviously not an optimal solution. I did't find anything about this in bugzilla. But I'll wait with filing a bug until I know if there is a plan already. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdkpixbufloader-API shortcoming
A possible (though non-optimal) solution is to create 2 loaders - 1 for image/x-foo and 1 for image/x-bar. You can share 99% of the code, and then pass the mime type to your decoder function, based on which DLL got invoked. This is what the GDI+ based loaders do on Windows, for instance. Best, Dom On Wed, Jun 11, 2008 at 3:19 PM, Magnus Bergman [EMAIL PROTECTED] wrote: A small shortcoming in the gdkpixbufloader-API causes me trouble. The problem is this: Let's say my loader libpixbufloader-foobar can handle the two (very similar) formats image/x-foo and image/x-bar. Then an application identifies an image as either foo or bar it invokes my loader. But the loader has no way of telling if it's supposed to handle a foo-image or a bar-image. I guess that the idea is that the loader should be able to easy distinguish between the two formats by fingerprinting the first few bytes. But since both foo and bar lack a decent header that cannot be done. (I must stress that this is not a hypothetical problem but a very real one I have encountered more than once then writing loaders for obscure formats). The solution is some way for the loader to know why it was chosen. Either which mimetype or which extension (of those supplied by the loader) was a match. Perhaps just a function which could be called by the loader like: gdk_pixbuf_why_me(gpointer handle,gchar **matching_mimetype,gchar ** matching_extension); Or are there some plans for a totally new API for pixbuf loaders since I have seen some other shortcomings of the current one. Someone requested about the same thing as me (but for using an external library which already supported all image formats supported by gdkpixbuf and then some). Another thing mentioned is the one to one mapping between loader and image format which is bad then then saving images (even if the loader can distinguish between different variants then loading it does nothing for saving). A suggested solution (read ugly hack) was to duplicate all of the code for each format (or create a library which is called by a small wrapper for each format). But that is obviously not an optimal solution. I did't find anything about this in bugzilla. But I'll wait with filing a bug until I know if there is a plan already. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
