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,
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 wo
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 subm
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 u
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 outline
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 i
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()
And in addition all current style engines would need to be ported, since once the GdkGCs are declared as deprecated, it would as a consequence deprecate the styles engine's code as well.
On 12/1/05, milosz derezynski <[EMAIL PROTECTED]> wrote:
Yes, that's what i meant by "deprecation by policy" (i.
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 do
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 t
> 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
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 we'
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
> 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 first week of January.
And as far as I'm concerned, there's
> 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 2005http://wiki.ubuntu
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Thu, 2005-12-01 at 18:04 +0100, Murray Cumming wrote:
> On Thu, 2005-12-01 at 14:07 -0200, Johan Dahlin wrote:
> > 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
> > >
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 u
On Thu, 2005-12-01 at 08:36, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN
wrote:
> Just wondering if there is a legacy reason why g_list_prepend() does not call
> g_list_first() on the pointer passed in to ensure that it is prepending to
> the
> head of the list. The g_list_append() call ensure it is a
On Thu, 2005-12-01 at 14:07 -0200, Johan Dahlin wrote:
> 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 implementi
On Thu, 2005-12-01 at 14:07 -0200, Johan Dahlin wrote:
> 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 implementi
Just wondering if there is a legacy reason why g_list_prepend() does not call
g_list_first() on the pointer passed in to ensure that it is prepending to the
head of the list. The g_list_append() call ensure it is appending to the end,
and this is unintuitive to people. If this seems logical, is
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. Wheth
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
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 volun
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 changed
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
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
On Thu, 2005-12-01 at 13:11 +0100, Vincent Untz wrote:
> On Thu, December 1, 2005 13:10, Vincent Untz wrote:
> > [I'm not sure why I didn't cc gtk-devel-list in my previous mail, so
> > doing it right now]
>
> And really doing it now.
>
> > On Thu, December 1, 2005 13:01, Murray Cumming 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 rename() issue, I went ahead with the change.
At the same tim
On Thu, December 1, 2005 13:10, Vincent Untz wrote:
> [I'm not sure why I didn't cc gtk-devel-list in my previous mail, so
> doing it right now]
And really doing it now.
> On Thu, December 1, 2005 13:01, Murray Cumming wrote:
>> On Thu, 2005-12-01 at 12:58 +0100, Vincent Untz wrote:
>>> On Thu, D
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 some
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 some different way,
> no matter what is docume
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;
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
> > s
35 matches
Mail list logo
