Hi,
On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi wrote:
> - branches for alignment and margin for review
widget-padding and widget-expand branches pushed, widget-expand
includes widget-padding
Pending changes not in the branches yet include:
- rename padding to margin
- some docs tweaks Matt
Hi,
On Tue, Sep 7, 2010 at 7:25 PM, Emmanuele Bassi wrote:
> - possible addition pre-3.0: surface ↔ pixbuf conversion functions in gdk
>
Incidentally, these should probably be in gdk-pixbuf (to avoid cairo
dep they could just go to guint8*). The main use I guess is say in
Clutter or other cairo-
On Sat, Sep 4, 2010 at 4:56 AM, Benjamin Otte wrote:
> 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
• G(tk)Application status
- r-t remove obligation to backport GtkApplication to gtk+ 2.22.0
- GApplication is not ready
‣ actions need more work
‣ proper review before committing to a new API
- remove from 2.25, release 2.26 (for GNOME 2.32) without
- punt it to 2.28 (December, with GTK+ 3.0)
-
On Tue, Sep 7, 2010 at 6:28 PM, Alberto Ruiz wrote:
>
> Would it be possible to move the current GApplication code to which a
> lot of apps are already ported to an external library somehow,
I actually developed it originally that way
(http://people.gnome.org/~walters/gapplication-standalone.git/
Hi Ryan and the rest of the Gtk+ team,
Sorry for not attending the meeting today, I have an exam next week
and I really have to focus.
I have a question though, regarding the situation with GApplication:
2010/9/7 Ryan Lortie :
> - go back to libunique (which is GDBus-enabled these days)
>
> -
Hey,
sorry for not getting around to this earlier. We've briefly talked
about this in todays GTK+ team meeting, and the 'a better
implementation hasn't surfaced in 9 years' argument has prevailed, so
we'd like to invite you to turn the sourceview code into a gtk patch,
so that we can integrate thi
On Tue, 2010-09-07 at 14:21 -0400, Colin Walters wrote:
> I think it makes sense to put gtk-doc.m4 inside glib (and the same for
> introspection.m4).
Shouldn't you be able to get away with the same hack that we use in
GIMP ?
http://git.gnome.org/browse/gimp/commit/?id=4f14da539118f7a4017c271b202c
I think it makes sense to put gtk-doc.m4 inside glib (and the same for
introspection.m4).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Tue, Sep 7, 2010 at 9:41 AM, Havoc Pennington wrote:
> Cool. So I'm inclined to search-and-replace the patch and make the properties:
>
> margin-left
> margin-right
> margin-top
> margin-bottom
> margin /* sets all four at once */
>
> I'll give it a couple more days though in case this turns
Hi,
I've been wanting to write a somewhat trivial patch for
GtkWindow to collapse the GtkOffscreenWindow code completely
as a property of GtkWindow (GtkWindow:offscreen).
The rationale is shamelessly and completely for Glade; here's
our story:
We've been using a hack for the longest time to e
On 09/08/10 22:54, Devin Samarin wrote:
I posted this on Bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=626380)
and I was recommended by Martyn to post the details here.
Hi Devin,
I know there isn't much activity on the review here any more, but
actually, I have been thinking. If people
On 03/09/10 11:27, Mike Massonnet wrote:
One website that has its own coordinators: http://webkitgtk.org/
It could deserve an update with the html skel that you have come up with.
My 2 cents
I think it probably does make sense yes. Now I start to think of the
other GTK+ sub-projects though,
On 06/09/10 21:39, John Ralls wrote:
On Sep 6, 2010, at 12:13 PM, Stefan Kost wrote:
I think I heard somewhere that you have a kind of dummy gtk-doc to
satisfy the build deps. I wonder if we can fix this somehow better.
Can you either ping me in #gtkdoc (gimpnet-irc), write to gtk-doc
mailing
Hi,
On Tue, Sep 7, 2010 at 3:49 AM, Tristan Van Berkom
wrote:
> What is the use-case for forcing a widget to request something smaller
> than it's content ?
>
I think the use-cases are mostly caused by the old limited layout
system. For example, to get a label to ellipsize, you used to have to
s
Cool. So I'm inclined to search-and-replace the patch and make the properties:
margin-left
margin-right
margin-top
margin-bottom
margin /* sets all four at once */
I'll give it a couple more days though in case this turns out to be
controversial so I don't do too much busywork ;-)
Havoc
__
On Sat, 2010-09-04 at 15:59 -0400, Havoc Pennington wrote:
> 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, out
Hi all,
Glib has GMainLoop for asynchronous programming and GThread & GThreadPool
for concurrent programming. To combine the advantages of them two, users
need to take care of threads themselves in sources' callbacks. This
introduces some kind of complexity and also duplicate works.
So introducin
On Tue, 2010-09-07 at 14:44 +0900, Tristan Van Berkom wrote:
> On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote:
> > Hi,
> >
> > several questions looking at this code,
>
> Sorry it took me a while to answer this mail.
>
> >
> > 1. I may be nuts but I really thought set_size_request()
19 matches
Mail list logo
