Bugzilla is down, so here's a patch for another problem
Havoc
From d8b6eb473b0eb13b9540f91516f2f60df2d5f1a7 Mon Sep 17 00:00:00 2001
From: Havoc Pennington
Date: Sun, 5 Sep 2010 01:42:14 -0400
Subject: [PATCH] default impls of width_for_height,hfw should chain directly not use wrapper API
In Gtk
Also,
4. AuxInfo still contains x,y, x_set, y_set and code reads them, but
commit 0d322676dcb06be62329a7d4373c497993509fbd removed set_uposition
and now there is no way to set these - so they should die, right?
Havoc
___
gtk-devel-list mailing list
gtk-
Hi,
several questions looking at this code,
1. I may be nuts but I really thought set_size_request() could reduce
a size request below the widget's normal request, back in the day.
However, won't this code allow set_size_request to *increase* min size
only?
http://git.gnome.org/browse/gtk+/tree/
Hi,
On Sat, Sep 4, 2010 at 1:40 PM, Thomas Wood wrote:
> It might be worth re-using the CSS box model¹ nomenclature here to avoid
> confusion. In the CSS box model:
>
> * "margin": extra spacing around the element, outside of the
> border.
> * "border": the width of the frame d
Hello,
some time ago I have looked into the printing stack to sanely support a
new MFP on GNOME. There were some annoying issues that need to be
solved.
So I would love to get these issues fixed.
Attachment #168505[1] is the most important patch (bug #599664[2]).
It fixes the non-blocking intera
Hello everyone,
Pushing back the DirectFB subject again.
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).
This week Sven pushed the patches I made for GTK+ 2.22. I would really
like to see GTK+ work well on Direct
On Thu, 2010-09-02 at 19:58 -0400, Havoc Pennington wrote:
> > And here are some of the 'layout' style properties:
>
> I think we could add style props on GtkWidget that would modify the
> padding on the widget (I don't know if they'd just replace the
> programmer-set padding, or be an adjustment
I'd say a useful emphasis is to focus on enabling deprecation by
adding "the new way," rather than on actually removing the old way.
e.g. on my pixbuf patch, the changes allow dropping any actual use of
the old format. But going on a "compile with
GDK_PIXBUF_DISABLE_DEPRECATED" spree just in pixbu
2010/9/4 Emmanuele Bassi :
>> Well, since currently gdk-pixbuf comes inside Gtk+, and Gtk+ depends
>> on cairo.
>
> this is not true any more, since GDK-Pixbuf has been split from GTK+ and
> it's a separate library once again.
Which is the actual point of my argument :P
> ciao,
> Emmanuele.
>
>
On Fri, 2010-09-03 at 21:49 +0100, Alberto Ruiz wrote:
> > For what it's worth, libgpod has a gdk-pixbuf dependency and no cairo dep,
> > and people complain from time to time about that dependency (though that's
> > mainly on distros where gdk-pixbuf is in the same package as gtk+, which
> > will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I filed Bug 628236 for this in Bugzilla but how do GIR based bindings
work around this limitation in the meantime?
- --
Sincerely,
Serkan KABA
Java-GNOME Developer
Gentoo Developer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Hi Benjamin,
Great that you bring this up for discussion.
I think another trade-off you want to make in this discussion is what
amount of backwards compatibility you want to have with GTK 2.x. In
the original GTK+ 3 plans a few years ago it was argued to have a very
smooth migration path by limi
So,
I've been busy the last few days making all expose events use Cairo
contexts exclusively and while doing that had to wander into the
cobwebbed regions of Gtk code and other exciting places. While doing
that a few questions about general cleanup occured to me:
1) How to handle old-school widge
Thanks.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
14 matches
Mail list logo
