How to inserts a widget in the toolbar at the given position
hello, how to inserts a widget in the toolbar at the given position. because gtk_toolbar_insert_widget is deprecated i tried with gtk_tool_button_new (GtkWidget *icon_widget, const gchar *label); instead of icon_widget i used other widget (e.g GtkHScale) it is able to show hscale in its default size , but not getting the control of scale , it acts like a button. how i can get control of hscale ? is it a right way to insert a widget in the toolbar ? can anybody help me? Thank you sphurti Get the freedom to save as many mails as you wish. To know how, go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to make GtkTreeView and GtkTextView scrollable?
Hi. I want to make my GtkTreeView and GtkTextView scrollable automaticaly. How to do it? It's lame question. I know. Thank you. -- |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,3- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to inserts a widget in the toolbar at the given position
I answered this in your post here: http://www.gtkforums.com/about876.html From the GtkToolItem API: GtkToolItems are widgets that can appear on a toolbar. To create a toolbar item that contain something else than a button, use gtk_tool_item_new(). Use gtk_container_add() to add a child widget to the tool item. - Micah Carrick Developer - http://www.micahcarrick.com GTK+ Forums - http://www.gtkforums.com sphurti durgade wrote: hello, how to inserts a widget in the toolbar at the given position. because gtk_toolbar_insert_widget is deprecated i tried with gtk_tool_button_new (GtkWidget *icon_widget, const gchar *label); instead of icon_widget i used other widget (e.g GtkHScale) it is able to show hscale in its default size , but not getting the control of scale , it acts like a button. how i can get control of hscale ? is it a right way to insert a widget in the toolbar ? can anybody help me? Thank you sphurti Get the freedom to save as many mails as you wish. To know how, go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html ___ 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: How to set background color for a pango layout being printed ?
On Wed, 17 Oct 2007 08:40:04 +0200, Miroslav Rajcic [EMAIL PROTECTED] wrote: On Windows (GTK+ 2.10.11 from http://gladewin32.sourceforge.net/), when using print preview operation (.emf image format) everything seems to work, but I get strange drawing artefacts in the picture. Individual text layouts are drawn with gray lines either on the left and right layout bounds or on the top and bottom bounds!! Some layouts are even completely squared in Did you solve this? I got the same problem. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.key ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to make GtkTreeView and GtkTextView scrollable?
On Nov 16, 2007 1:58 PM, AlannY [EMAIL PROTECTED] wrote: Hi. I want to make my GtkTreeView and GtkTextView scrollable automaticaly. How to do it? It's lame question. I know. Just add them inside a GtkScrolledWindow. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Nov 13, 2007 4:15 PM, BJörn Lindqvist [EMAIL PROTECTED] wrote: Checkout using: svn co svn.gnome.org/svn/cairoio/trunk cairoio The implementation is in /ref/cairoio.py which also contain lots of documentation. I know the name CairoIO might not be so nice, but it is only seven characters. Maybe someone can think of a better name? The API documentation can now be found here (looking for a better home for it): * http://trac.bjourne.webfactional.com/chrome/common/cairoio-docs/ * http://trac.bjourne.webfactional.com/chrome/common/cairoio-docs/CairoIO.pdf -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Is g_source_remove threadsafe?
I'm doing something where i have one thread queueing idles and timeouts
in a thread, and the main loop consumes this. In some cases i want to
remove the sources (to replace a timeout with an idle). However:
gboolean
g_source_remove (guint tag)
{
GSource *source;
g_return_val_if_fail (tag 0, FALSE);
source = g_main_context_find_source_by_id (NULL, tag);
if (source)
g_source_destroy (source);
return source != NULL;
}
This doesn't seem threadsafe to me. g_main_context_find_source_by_id()
grabs the context lock, which is held during dispatches. However, there
is no lock held between g_main_context_find_source_by_id() returning and
g_source_destroy() being called, so what protects against the mainloop
triggering a dispatch on another thread at this point, invalidating the
pointer we have to the source (since we haven't got a ref on the
source).
Am I missing something obvious here?
I guess I will have to keep the actual source object around (with a ref
to it).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 2007-11-16 at 14:12 +0100, Alexander Larsson wrote: On Fri, 2007-11-16 at 14:04 +0100, Tim Janik wrote: On Fri, 16 Nov 2007, Alexander Larsson wrote: I'm doing something where i have one thread queueing idles and timeouts in a thread, and the main loop consumes this. In some cases i want to remove the sources (to replace a timeout with an idle). However: Am I missing something obvious here? simply use g_source_remove (id) instead. Eh, thats the call I talked about. I think Tim meant g_source_destroy() ... if you have a reference to a source, it's not going to vanish from beneath you in a different thread because you return FALSE from the source function. The ID versions of the functions are basically just there for backwards compat: they are a bit slower, and aren't completely protected against ID wraparound. While I don't really consider g_source_remove(some_id_that_I_might_already_have_removed) 100% valid, the docs do imply that it is legal, so perhaps it would be worth fixing up that case (say, by having a referencing internal variant of find_source_by_id().) - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 16 Nov 2007, Owen Taylor wrote: While I don't really consider g_source_remove(some_id_that_I_might_already_have_removed) 100% valid, the docs do imply that it is legal, so perhaps it would be worth fixing up that case (say, by having a referencing internal variant of find_source_by_id().) i think such a variant really needs to be exposed as public API. g_main_context_find_source*() is fairly pointless if it can only be used correctly if the caller must be holding a reference to the returned source already. i think this API should have in the first place, either: - returned an id, because g_source_remove(invalid_id) behaves gracefully, or - returned a GSource* with increased reference count, to ensure the returned pointer is alive and valid. - Owen --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Nov 15, 2007 10:34 PM, Mikkel Kamstrup Erlandsen
[EMAIL PROTECTED] wrote:
Some background info about this project is found here:
* http://www.mail-archive.com/gtk-devel-list@gnome.org/msg06472.html
* http://live.gnome.org/GtkCairoIntegration
* http://bugzilla.gnome.org/show_bug.cgi?id=395578#c6
In short, GdkPixbuf has some big problems which are hard to solve, so
we need a new image library which is more compatible with Cairo.
CairoIO is my attempt at creating such a library. The library is not a
reimplementation of GdkPixbuf, it only wraps it to provide a
cairoified front end to all the image loading functionality.
Currently it consists of nothing more than a executable specification
written in Python and unit tests. The intention is to first create a
rock-solid, future-proof interface that solves all architectural
problems GdkPixbuf has. So lets have some nice discussion about it!
The things I've found really bad with GdkPixbuf and which I think
CairoIO can solve are listed in Targeted GdkPixbuf Problems in the
/ref/cairoio.py file. In particular I was not happy with how
PixbufAnimations work so I've tried to make them better.
Checkout using:
svn co svn.gnome.org/svn/cairoio/trunk cairoio
The implementation is in /ref/cairoio.py which also contain lots of
documentation. I know the name CairoIO might not be so nice, but it
is only seven characters. Maybe someone can think of a better name?
Feedback welcome!
1) I am wondering if it should integrate with the upcoming libgio? Ie, take
a GFile instead of a filename in function args..? Or maybe going entirely
G{Input,Output}Stream based? That would obsolete a few of the methods in the
API.
That may be a good idea.
2) I see that you do not have any methods to match GdkPixbuf.get_has_alfa
and a handful other methods on GdkPixbuf. Is the reason documented somewhere
or am I missing something obvious?
It is documented now. :) CairoIO merely (de)serializes images and
doesn't concern itself with the pixel data. So:
surface = cairoio.load('foobar.png')
if surface.get_format() in (cairo.FORMAT_ARGB32,):
is equivalent with:
pixbuf = gdk.pixbuf_new_from_file('foobar.png')
if pixbuf.get_has_alpha():
Cairo currently only supports one alpha format which is FORMAT_ARGB32
(FORMAT_A8 and FORMAT_A1 doesn't count), but might support more in
the future.
3) Why is there a load_xpm()?
This function is for loading inline xpm data and works exactly the
same as gdk_pixbuf_new_from_xpm_data(). The name is now
load_xpm_data() to make that clear.
4) I gather that the load*() family functions replace the constructors of
GDkPixbuf.
4.1) How exactly would you map the load_frames() method with the keyword
arguments?
Not sure I understand? Do you mean the arguments with default values?
4.2) Why do I have to call load_frames() to request the image size on
construction of the surface? Just load() would space me the linked list for
normal images.
What do you mean? cairoio.load() only returns a single
cairo.ImageSurface. cairoio.load_frames() is supposed to be the
full-featured general purpose method that works in all situations,
such as when you want to load thumbnails in Nautilus for example.
4.3 (Assuming gio based) If we are in stream terminology s/load/read is
probably more in line
5) All load_*() family functions returns a SurfaceInfo, but load() returns a
Surface... A bit odd maybe.
The reason is that cairoio.load() is the convenience function which
covers 95% of the use cases. So that function should be as simple as
possible because you are almost never interested in the image files
options.
I am really exited about the idea about joggling cairo surfaces around over
G{In,Out}putStreams, but the idea may be bonkers, I have not read the GIO
api much, not do I understand the finer details of cairo surfaces.
That's a really cool idea and I'll definitely look into it as soon as
GIO becomes a little more stable.
--
mvh Björn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 16 Nov 2007, Alexander Larsson wrote: I'm doing something where i have one thread queueing idles and timeouts in a thread, and the main loop consumes this. In some cases i want to remove the sources (to replace a timeout with an idle). However: Am I missing something obvious here? simply use g_source_remove (id) instead. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtester git repo (Re: GLib testing framework)
Your API has g_test_rand_bit() which should (IMO) be called g_test_rand_boolean() to match the fundamental type's name that's used for this in glib (gboolean) and also to provide consistency with g_rand_boolean(). I think a difference to the rest of the g_* API isn't really helpful in using the new test framework (imagine someone porting self-written tests to the framework and the g_rand_boolean() has to be replaced with g_test_rand_bit() - feels a little odd). Regards, Sven Am 08.11.2007 um 15:59 schrieb Tim Janik: On Tue, 6 Nov 2007, Tim Janik wrote: i've checked in Sven's and my code into a git-svn mirror of glib on testbit.eu. so you can browse the recent changes here: http://testbit.eu/gitdata?p=glib.git;a=shortlog;h=gtester e.g. todays latest version of the testing examples is here: http://testbit.eu/gitdata?p=glib.git;a=blob;f=glib/tests/ testing.c;hb=9c8ae8c0097b8f7c098970e87bf413cd9c4f6a22 i've created a different repo for testing framework previews now, as cloning the above includes dozens of megabytes for all of the GLib history. the new shallow repo is here: http://git.imendio.com/?p=timj/glib-testing.git;a=summary the branch i'm currently pushing to is: http://git.imendio.com/?p=timj/glib- testing.git;a=shortlog;h=gtester1 i'll create gtester2, etc. everytime the branch is rebased onto recent upstream changes. the repo can be cloned with: git-clone git://git.imendio.com/timj/glib-testing however building it might require this before autogen.sh: mkdir -p build/win32/dirent build/win32/vs8 touch build/win32/vs8/Makefile.am build/win32/dirent/ Makefile.am build/win32/Makefile.am build/Makefile.am --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Thu, 2007-11-15 at 22:34 +0100, Mikkel Kamstrup Erlandsen wrote:
I am really exited about the idea about joggling cairo surfaces around
over G{In,Out}putStreams, but the idea may be bonkers, I have not read
the GIO api much, not do I understand the finer details of cairo
surfaces.
Yeah, this seems like a good idea. In the star trek future, the idea is
that all sorts of libs that read data (from network or whatever) will
produce a GInputStream. If cairoIO can read these (async and sync) it
will automatically be able to consume pixbuf data from any source.
Although there should still be (helper) functions to load from a
GFile*, and maybe from char *path.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
On Fri, 16 Nov 2007, Richard Hult wrote: Tim Janik wrote: hey All. Hi Tim, [snip] /* syncronize rendering operations with X server rendering queue */ voidgtk_test_xserver_render_sync(GdkWindow *window); Should this be named less X-ish? I noticed that some of the event simulation functions are very X specific anyway, but if we have the API at least look generic, we can make it work on other backends later. the API that generates button or key events should ideally be implemented for non-X backends as well at some point, yes. gtk_test_xserver_render_sync() however uses a technique that is only known to work for X servers (according to keith packard), please search for XGetImage in this email: http://mail.gnome.org/archives/gtk-devel-list/2006-October/msg00166.html if there's a chance we could use and implement a similar call for other windowing system backends though, a rename like you suggest would be good. Tml, any input? ;) /Richard --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 2007-11-16 at 08:30 -0500, Owen Taylor wrote: On Fri, 2007-11-16 at 14:12 +0100, Alexander Larsson wrote: On Fri, 2007-11-16 at 14:04 +0100, Tim Janik wrote: On Fri, 16 Nov 2007, Alexander Larsson wrote: I'm doing something where i have one thread queueing idles and timeouts in a thread, and the main loop consumes this. In some cases i want to remove the sources (to replace a timeout with an idle). However: Am I missing something obvious here? simply use g_source_remove (id) instead. Eh, thats the call I talked about. I think Tim meant g_source_destroy() ... if you have a reference to a source, it's not going to vanish from beneath you in a different thread because you return FALSE from the source function. Yeah, thats what I meant by the last statement in my mail (I guess I will have to keep the actual source object around). The ID versions of the functions are basically just there for backwards compat: they are a bit slower, and aren't completely protected against ID wraparound. Most people still use them though, because it involves less typing due to the helper functions like g_idle_add(). While I don't really consider g_source_remove(some_id_that_I_might_already_have_removed) 100% valid, the docs do imply that it is legal, so perhaps it would be worth fixing up that case (say, by having a referencing internal variant of find_source_by_id().) Yeah, the docs does seem to impy these things are legal. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
Tim Janik wrote: hey All. Hi Tim, [snip] /* syncronize rendering operations with X server rendering queue */ voidgtk_test_xserver_render_sync(GdkWindow *window); Should this be named less X-ish? I noticed that some of the event simulation functions are very X specific anyway, but if we have the API at least look generic, we can make it work on other backends later. /Richard -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Gtk+ testing utilities
Some quick and random comments that come to mind... /* syncronize rendering operations with X server rendering queue */ voidgtk_test_xserver_render_sync(GdkWindow *window); /* synthesize and send key press or release event */ gbooleangtk_test_simulate_key (GdkWindow *window, /* synthesize and send button press or release event */ gbooleangtk_test_simulate_button(GdkWindow *window, Shouldn't the above be named gdk_test or take GtkWidget as parameter? /* synthesize and send key press or release event */ gbooleangtk_test_simulate_key (GdkWindow *window, gintx, ginty, guint keyval, GdkModifierType modifiers, gboolean press_or_release); /* synthesize and send button press or release event */ gbooleangtk_test_simulate_button(GdkWindow *window, gintx, ginty, guint button, /*1..3*/ GdkModifierType modifiers, gboolean press_or_release); Instead of gboolean press_and_release, how about using GDK_KEY_PRESS / GDK_KEY_RELEASE and GDK_BUTTON_PRESS / GDK_BUTTON_RELEASE instead (or anything more explicit than TRUE)? When reading the test code the intention would be much more obvious. while (gtk_events_pending ()) gtk_main_iteration (); The test examples had quite a few of these, adding noise. Most of them were related to spin buttons, so I suppose in general tests shouldn't have many of these? Would it make sense to flush the events in gtk_test_spin_button_click instead, for example? -- Tommi Komulainen[EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is g_source_remove threadsafe?
On Fri, 16 Nov 2007, Alexander Larsson wrote: On Fri, 2007-11-16 at 14:04 +0100, Tim Janik wrote: On Fri, 16 Nov 2007, Alexander Larsson wrote: I'm doing something where i have one thread queueing idles and timeouts in a thread, and the main loop consumes this. In some cases i want to remove the sources (to replace a timeout with an idle). However: Am I missing something obvious here? simply use g_source_remove (id) instead. Eh, thats the call I talked about. sorry, i mistook the call to g_source_destroy(GSource*) for your own code, and thought you'd wrongly try to use g_source_destroy() instead of g_source_remove(guint). yes, you're right, there's a race in the implementation of g_source_remove() and also g_source_remove_by_user_data, g_source_remove_by_funcs_user_data. this must have been introdcued when we moved away from hook lists, for which removal by id was safe. the code here needs fixing to either move the searching into internal functions so a single lock can be held around searching and destroying the sources, or by just making g_source_remove() thread safe again via inlining of find_source_by_id, and then provide alternative APIs to search for source *ids* instead of pointers from user_data and funcs. changing the API for source searching is actually needed anyway to get rid of the thread race inherent in the current API (g_main_context_find_source*() return GSource pointers but no lock is held when they return and they don't add a reference count to the sources. so the pointer may already be invalid when the functions return). --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Fri, 16 Nov 2007 14:04:45 +0100, =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?= wrote:
surface = cairoio.load('foobar.png')
if surface.get_format() in (cairo.FORMAT_ARGB32,):
is equivalent with:
pixbuf = gdk.pixbuf_new_from_file('foobar.png')
if pixbuf.get_has_alpha():
Actually, better cairo code would be:
if surface.get_content() == cairo.CONTENT_COLOR_ALPHA:
Cairo currently only supports one alpha format which is FORMAT_ARGB32
(FORMAT_A8 and FORMAT_A1 doesn't count), but might support more in
the future.
The code I presented will be robust against future additions of
color-and-alpha-supporting image formats.
Another thought that occurs to me is that you should think about how
to support fast loading of image data directly into cairo surfaces
other than cairo-image surfaces, (for example a cairo-xlib surface).
There's been recent discussion on the cairo mailing list about adding
API to support this well, (for example, allowing XShm transport), and
it might be very nice if you could provide some feedback on that. Let
me know if you need a specific pointer to the thread(s).
-Carl
pgpQFpUbuM9TU.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On 16/11/2007, BJörn Lindqvist [EMAIL PROTECTED] wrote:
On Nov 15, 2007 10:34 PM, Mikkel Kamstrup Erlandsen
[EMAIL PROTECTED] wrote:
Some background info about this project is found here:
* http://www.mail-archive.com/gtk-devel-list@gnome.org/msg06472.html
* http://live.gnome.org/GtkCairoIntegration
* http://bugzilla.gnome.org/show_bug.cgi?id=395578#c6
In short, GdkPixbuf has some big problems which are hard to solve, so
we need a new image library which is more compatible with Cairo.
CairoIO is my attempt at creating such a library. The library is not a
reimplementation of GdkPixbuf, it only wraps it to provide a
cairoified front end to all the image loading functionality.
Currently it consists of nothing more than a executable specification
written in Python and unit tests. The intention is to first create a
rock-solid, future-proof interface that solves all architectural
problems GdkPixbuf has. So lets have some nice discussion about it!
The things I've found really bad with GdkPixbuf and which I think
CairoIO can solve are listed in Targeted GdkPixbuf Problems in the
/ref/cairoio.py file. In particular I was not happy with how
PixbufAnimations work so I've tried to make them better.
Checkout using:
svn co svn.gnome.org/svn/cairoio/trunk cairoio
The implementation is in /ref/cairoio.py which also contain lots of
documentation. I know the name CairoIO might not be so nice, but it
is only seven characters. Maybe someone can think of a better name?
Feedback welcome!
1) I am wondering if it should integrate with the upcoming libgio? Ie,
take
a GFile instead of a filename in function args..? Or maybe going
entirely
G{Input,Output}Stream based? That would obsolete a few of the methods in
the
API.
That may be a good idea.
2) I see that you do not have any methods to match
GdkPixbuf.get_has_alfa
and a handful other methods on GdkPixbuf. Is the reason documented
somewhere
or am I missing something obvious?
It is documented now. :) CairoIO merely (de)serializes images and
doesn't concern itself with the pixel data. So:
surface = cairoio.load('foobar.png')
if surface.get_format() in (cairo.FORMAT_ARGB32,):
is equivalent with:
pixbuf = gdk.pixbuf_new_from_file('foobar.png')
if pixbuf.get_has_alpha():
Cairo currently only supports one alpha format which is FORMAT_ARGB32
(FORMAT_A8 and FORMAT_A1 doesn't count), but might support more in
the future.
3) Why is there a load_xpm()?
This function is for loading inline xpm data and works exactly the
same as gdk_pixbuf_new_from_xpm_data(). The name is now
load_xpm_data() to make that clear.
4) I gather that the load*() family functions replace the constructors
of
GDkPixbuf.
4.1) How exactly would you map the load_frames() method with the
keyword
arguments?
Not sure I understand? Do you mean the arguments with default values?
Yes. In fx. load_frames what will the C api look like? One method with all
the args or several methods with combinations?
4.2) Why do I have to call load_frames() to request the image size on
construction of the surface? Just load() would space me the linked list
for
normal images.
What do you mean? cairoio.load() only returns a single
cairo.ImageSurface. cairoio.load_frames() is supposed to be the
full-featured general purpose method that works in all situations,
such as when you want to load thumbnails in Nautilus for example.
Ok, I don't know how I ended up writing that paragraph :-) What I meant was
that load_frames() is the only method capable of scaling on the fly. So if I
want to do that I have to accept that the returned value is a list packing
the single frame I want. I assume the overwhelming majority of cases only
use single-frame images, so why not provide a convenience variant of load()
that returns only one SurfaceInfo?
4.3 (Assuming gio based) If we are in stream terminology s/load/read is
probably more in line
5) All load_*() family functions returns a SurfaceInfo, but load()
returns a
Surface... A bit odd maybe.
The reason is that cairoio.load() is the convenience function which
covers 95% of the use cases. So that function should be as simple as
possible because you are almost never interested in the image files
options.
It just seems inconsistent:
load() - Surface
load_frames() - [SurfaceInfo]
load_xpm_data() - SurfaceInfo
load_inline() - SurfaceInfo
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
