Olexiy Avramchenko wrote:
Carlos Eduardo Rodrigues Diogenes wrote:
What of these two components are fastest to copy from one to another
(GdkDrawable to GdkDrawable or GkdPixbuf to GdkPixbuf)?
The fastest case depends on your client's hardware (pixbufs) and X
server's hardware (drawables).
Hi all,
In my application I want to create a setup wizard which reuses the same
window. Is it possible to achieve using a dialog and removing the contents of
its vbox.
If so how do I remove the contents of the dialog's vbox. I've tried
gtk_widget_destroy should I use g_object_unref ??
Hello,
I have a GUI with
-a GtkDrawingArea which has an associated GdkDrawable which has
an associated GtkPixmap which is used to display images and drawing
primitives
-a GtkHBox with buttons
The backend of the GUI is CPU intensive and when the backend starts,
the GUI is no longer interactive
hello, I have a some buttons inside a table like a matrix. Lets pick one
of this buttons, we have one vbox set as child of the button and inside
the box we have 4 labels. But we have a problem, one of this labels have
a very random width, so would be desired that this specific label does
not make
Hi Morten,
On Wed, 2005-11-30 at 19:58 -0500, Morten Welinder wrote:
Uhm, I'll put that code under #idef G_OS_UNIX/#endif guards for the time
being, but the getenv(TZ)/setenv(TZ) timezone trick should work on
any sufficiently recent POSIX-like system; users of other operating
systems
Emmanuele Bassi wrote:
Hi Morten,
On Wed, 2005-11-30 at 19:58 -0500, Morten Welinder wrote:
Uhm, I'll put that code under #idef G_OS_UNIX/#endif guards for the time
being, but the getenv(TZ)/setenv(TZ) timezone trick should work on
any sufficiently recent POSIX-like system; users of other
On Thu, 1 Dec 2005, Alexander Larsson wrote:
On Fri, 2005-11-25 at 07:11 -0500, Owen Taylor wrote:
The GList API isn't an opaque abstract data structure; it's a a set of
well-defined operations on list nodes. It would not be OK to change the
g_list_append() operation to modify the list in
J. Ali Harlow writes:
The advantages outweigh the tiny API breakage.
Yup. And especially as I finally found out that one of the reasons why
Evolution's on this machine folders never showed up on Win32 was
partially because of this rename() issue, I went ahead with the change.
At the same time
On Thu, 2005-12-01 at 15:41 +0200, Tor Lillqvist wrote:
J. Ali Harlow writes:
The advantages outweigh the tiny API breakage.
Yup. And especially as I finally found out that one of the reasons why
Evolution's on this machine folders never showed up on Win32 was
partially because of this
Shouldn't GdkGC be deprecated now that we have cairo contexts?
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
hello,
i have been for years struggling with pango. it refused to build from
cvs into /usr/local/lib (the default) while my distribution had a version
in /usr/lib
i do not completely understand the way things work -- i do understand
how they are supposed to work in the simpler sense.
i
Hi,
During the week-end of February 25 and 26th, the FOSDEM 2006 will be
held in Brussels. FOSDEM is a 2 days event to promote the widespread use
of Free and Open Source software.
Gnome has a dedicated Developers Room, where we can give talks about the
project. That's why we are looking for
When auditing the new API in 2.8 for Gtk#, I noticed that a property and
signal were added to the FileChooser interface. Adding anything to an
interface is a non-compatible change, because any class implementing the
interface must be updated to add the new API members. Whether a C
compiler would
Mike Kestner wrote:
When auditing the new API in 2.8 for Gtk#, I noticed that a property and
signal were added to the FileChooser interface. Adding anything to an
interface is a non-compatible change, because any class implementing the
interface must be updated to add the new API members.
On Thu, 2005-12-01 at 09:55 -0600, Mike Kestner wrote:
When auditing the new API in 2.8 for Gtk#, I noticed that a property and
signal were added to the FileChooser interface. Adding anything to an
interface is a non-compatible change, because any class implementing the
interface must be
On Thu, 2005-12-01 at 12:39 +0100, Tim Janik wrote:
and there were no strong objections after that. so it'd be nice if you
provided
a patch that covered all list functions. i think that can get commit approval
right away then.
What about this one.
quote who=Christophe Fergeau
If you are interested about giving a talk, please send me an email telling
me what you want to give a talk about.
I'll be there - would love to do a talk about GNOME advocacy and kicking
arse in that field. :-)
- Jeff
--
Ubuntu USA Europe Tour: Oct-Nov 2005
On Thu, 2005-12-01 at 15:44 -0500, Behdad Esfahbod wrote:
When we discussed the shortened schedules at the last GTK+ team meeting,
I proposed to aim for API freeze for GLib 2.10 and Pango 1.12 before or
immediately after the Christmas break, so that we can do API frozen
releases in the
I agree but it doesn't sound really easy as GtkStyle holds a number of GdkGCs for the style colors.I am currently unaware of whether the style engines access them directly but i'd rather think they do, so this would require the style engines to 1) only use the GdkColors of the style and (while
I agree but it doesn't sound really easy as GtkStyle holds a number of
GdkGCs for the style colors.
So, I guess that should be ported too.
In general, deprecation doesn't mean that you may not use it. Deprecation
is n't breaking.
I am currently unaware of whether the style engines access
On Tue, Nov 22, 2005 at 10:09:29AM -0600, Federico Mena Quintero wrote:
On Tue, 2005-11-22 at 12:07 +0100, Kristian Rietveld wrote:
We are indeed going to add a toplevel gtk_file_system_get_info(), I was
not thinking of removing gtk_file_folder_get_info() though. Does it
make sense to
Yes, that's what i meant by deprecation by policy (i.e. you'd say it's deprecated, but don't remove the code or anything, you just discourage it's use; although that might be not the proper word for it, i'm sorry in that case as i'm not a native english speaker)
The problem is just there are a
On Thu, 01 Dec 2005 09:11:30 -0800
Alan M. Evans [EMAIL PROTECTED] wrote:
I believe that this is a reasonable behavior. But it should be
documented.
I am inclined to agree. Anyone with any sense, as you point out, would
keep a pointer to the head of the list; thus making g_list_prepend()
On Thu, 2005-12-01 at 15:55 -0500, Matthias Clasen wrote:
The implementation of the major new api in GLib, the slice allocator,
just landed in cvs. So I don't expect big problems with freezing the
GLib API before the year ends.
I'd like to have at least a relocation API in place. This is so
hey all.
i've comitted the new memory allcoator to glib HEAD now.
it replaces the old slow and memory bloated memchunk implementation
and should provide significant speedups and memory savings over
using the systems malloc()/free() implementations.
gslice.c contains a large comment which
On Thu, 2005-12-01 at 09:55 -0600, Mike Kestner wrote:
When auditing the new API in 2.8 for Gtk#, I noticed that a property and
signal were added to the FileChooser interface. Adding anything to an
interface is a non-compatible change, because any class implementing the
interface must be
On Fri, 2005-12-02 at 01:50 +, Paul LeoNerd Evans wrote:
That said, by specifically not moving to the head of the list, this makes
it into an equivalent of g_list_insert_before(), when passed the same
GList* as both arguments. Is this intended / desirable / noticed?
Could you please submit
One first step could be to back all gdk_draw_*() functions with actual cairo drawing (disabling antialiasing so compatibility is kept) and reading only the color values off the GCs, and then officially deprecate the GdkGCs.
(Not entirely sure if that makes sense, RFC)That way at least the GdkGCs
On Thu, 2005-12-01 at 22:50 +0100, milosz derezynski wrote:
I agree but it doesn't sound really easy as GtkStyle holds a number of
GdkGCs for the style colors.
... and apps still do this:
gdk_gc_set_clip_rectangle (widget-style-black_gc, my_rect);
gdk_draw_pixbuf (widget-window,
29 matches
Mail list logo
