On 09/16/2010 04:20 PM, "Andrés G. Aragoneses" wrote:
El 16/09/10 15:24, Olav Vitters escribió:
On Thu, Sep 16, 2010 at 01:07:15PM +0200, "Andrés G. Aragoneses" wrote:
Another good thing to do after that is deploying the codeformatter in
the server as a hook for any commit, so users don't need
El 16/09/10 15:24, Olav Vitters escribió:
> On Thu, Sep 16, 2010 at 01:07:15PM +0200, "Andrés G. Aragoneses" wrote:
>> Another good thing to do after that is deploying the codeformatter in
>> the server as a hook for any commit, so users don't need to run it.
>
> This is impossible with distribute
Hi,
On Thu, Sep 16, 2010 at 6:36 AM, Andrew Cowie
wrote:
> On Sun, 2010-09-12 at 11:23 -0400, Matthias Clasen wrote:
>
>> > Anyhow, sure, if GTK has no policy that's fine. I assumed it had a
>> > sensible policy...
>>
>> We don't have a written-down policy, beyond 'fit in locally'. But I
>> have
On Thu, Sep 16, 2010 at 01:07:15PM +0200, "Andrés G. Aragoneses" wrote:
> Another good thing to do after that is deploying the codeformatter in
> the server as a hook for any commit, so users don't need to run it.
This is impossible with distributed version control.
Hooks can only contain policy,
El 16/09/10 13:00, Florian Müllner escribió:
> El jue, 16-09-2010 a las 20:36 +1000, Andrew Cowie escribió:
>> If someone write up a list of indent options and stick the command in a
>> one line script somewhere prominent (like / :)) then we can just run the
>> code formatter once over the entire t
El jue, 16-09-2010 a las 20:36 +1000, Andrew Cowie escribió:
> If someone write up a list of indent options and stick the command in a
> one line script somewhere prominent (like / :)) then we can just run the
> code formatter once over the entire tree, and then just tell people to
> run it in futu
On Sun, 2010-09-12 at 11:23 -0400, Matthias Clasen wrote:
> > Anyhow, sure, if GTK has no policy that's fine. I assumed it had a
> > sensible policy...
>
> We don't have a written-down policy, beyond 'fit in locally'. But I
> have become increasingly annoyed by trailing whitespace ...
Can we may
As I said on irc last night, I think we should merge the branch. It
looks largely fine to me, and we can work out remaining details after
the merge.
One thing we should do first though, is make sure that we have patches
/ branches ready for some core components. At least the gnome-shell
dependenci
+ g_return_if_fail (GTK_WIDGET_ALLOC_NEEDED (widget));
g_return_if_fail( ! GTK_WIDGET_ALLOC_NEEDED (widget));
right?
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fixed in
http://git.gnome.org/browse/gtk+/commit/?h=rendering-cleanup-next&id=99f0da58168e3db6cdf8c27c4239afc600bef058
Thanks for pointing out that flag, I never realized it exists.
Benjamin
On Wed, Sep 15, 2010 at 2:36 AM, Havoc Pennington wrote:
> Hi,
>
> On Tue, Sep 14, 2010 at 7:42 PM, Ben
Hi,
On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte wrote:
> On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen
> wrote:
>> What about the expose_event / gtk_widget_send_expose_event stuff ? Do
>> we want to merge what you have first and figure that out afterwards ?
>>
> I want to figure that out
Hi,
On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte wrote:
> I'm actually not sure about that. First, we don't have any code that
> defines if an allocation is valid or even defines what a "valid"
> allocation is. Or do we? gtk_widget_get_allocation() at least doesn't
> do anything there.
yes, we
On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen
wrote:
> What about the expose_event / gtk_widget_send_expose_event stuff ? Do
> we want to merge what you have first and figure that out afterwards ?
>
I want to figure that out afterwards. It's something I haven't figured
out completely yet. I co
And did you want to add some of the checks and warnings in
gtk_widget_draw_internal that were discussed (eg about not having
up-to-date allocation) ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel
On Tue, Sep 14, 2010 at 11:46 AM, Benjamin Otte wrote:
>
> I consider this API prtty much done at this point. There might be some
> implementation details that we might want to change later (like
> background handling), but we can do that after rendering-leanup-next
> hit master. So I consider it
I just pushed an update to rendering-cleanup and
rendering-cleanup-next that incorporates the suggestions from this
thread. In particular:
- I squelched commits
The fixes from Kris for OS X should now be in their correct position
and allow compiling random checkouts so git bisect works on OS X
(hop
On Sep 13, 2010, at 6:54 AM, Havoc Pennington wrote:
> On Mon, Sep 13, 2010 at 12:05 AM, John Ralls wrote:
>>> Could also make it a gdk_x11 api.
>>> But maybe a hint that is a no-op on other backends is better.
>>
>> I'm in favor of keeping platform-specific stuff in platform-specific files
>>
On Sep 12, 2010, at 9:54 PM, Havoc Pennington wrote:
> Hi,
>
> On Mon, Sep 13, 2010 at 12:05 AM, John Ralls wrote:
>>> Could also make it a gdk_x11 api.
>>> But maybe a hint that is a no-op on other backends is better.
>>
>> I'm in favor of keeping platform-specific stuff in platform-specific
Hi,
On Mon, Sep 13, 2010 at 4:26 AM, Alexander Larsson wrote:
> I'm personally a tiny bit uneasy about dropping bg None, as in some
> cases its really required to do flicker-free stuff in X. However, with a
> modern Gtk+ these situations are quite rare, and I don't think any of
> these changes re
On Sat, 2010-09-11 at 18:57 +0200, Benjamin Otte wrote:
> On Sat, Sep 11, 2010 at 6:29 PM, Havoc Pennington wrote:
> > - in many languages GtkSizeRequest::get_width() is already just
> > callable as widget.get_width()
> > - plain get_width() more naturally gets request, anyhow
> >
> Ugh, I'd alway
On Sat, 2010-09-11 at 11:16 -0400, Havoc Pennington wrote:
> *
>
> I'm skeptical of removing ability to set window background to None.
> This feature can be important to avoid visual artifacts on X11. The
> API should maybe change to not involve a "NULL" pixmap; conceptually,
> what this means is
Hi,
On Mon, Sep 13, 2010 at 12:05 AM, John Ralls wrote:
>> Could also make it a gdk_x11 api.
>> But maybe a hint that is a no-op on other backends is better.
>
> I'm in favor of keeping platform-specific stuff in platform-specific files
> and directories, but that's in large part just because I
On Sep 12, 2010, at 2:05 PM, Matthias Clasen wrote:
> On Sat, Sep 11, 2010 at 4:23 PM, Havoc Pennington wrote:
>
>>
>> Does GDK have enough information to know when to set background to None?
>> The patch
>> d3802ca Remove calls that try to set GDK_NO_BG
>>
>> basically removes hints to GDK t
Hi,
On Sun, Sep 12, 2010 at 5:05 PM, Matthias Clasen
wrote:
> Also, the idea to separate the translation and the size in
> size_allocate is intriguing.
>
A prior art thing I thought of that's relevant, Clutter has the
translation transform *and* the allocation origin.
The clutter model is that
On Sat, Sep 11, 2010 at 4:23 PM, Havoc Pennington wrote:
>
> Does GDK have enough information to know when to set background to None?
> The patch
> d3802ca Remove calls that try to set GDK_NO_BG
>
> basically removes hints to GDK that the background should not be
> repainted by the OS. I don't kn
On Sat, Sep 11, 2010 at 4:23 PM, Havoc Pennington
>
>>> There's a fair bit of trailing whitespace in the patch. Maybe turn on
>>> trailing-whitespace-highlighting in your editor.
>>>
>> I'm of the "if the tools don't fix it, it isn't broken" school of
>> thought.
>
> Emacs can be set up to fix it
Hi,
On Sat, Sep 11, 2010 at 11:46 AM, Havoc Pennington wrote:
> * size_allocate vfunc and wrapper change to (* size_allocate)
> (GtkWidget, int w, int h)
>
Another possible addition here, which is in both Clutter and
HippoCanvas, would be an ORIGIN_CHANGED flag. (Clutter uses a flags
arg, Hippo
Hi,
On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte wrote:
> Ugh, I'd always assume that widget.get_width() would give me the width
> of the widget, not the width the widget thought would be ideal but had
> nothing to do with reality. Also, a width getter would never return 2
> values for me.
> S
Hi,
On Sat, Sep 11, 2010 at 1:50 PM, Benjamin Otte wrote:
> The problem here is that I want to get rid of proxying the ugly X11
> background API via GDK. Neither Windows nor Quartz have anything
> similar. So my approach was to use a cairo_pattern_t in the API and
> then say "The backends are res
Whew, lots of things to reply to. Here we go...
On Sat, Sep 11, 2010 at 5:16 PM, Havoc Pennington wrote:
> A round of rebase/squash might be nice which would make it easier to
> review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could
> squish into 9badb81a7ed62af1cdf11eb31c7e94293a6834
Hi,
On Sat, Sep 11, 2010 at 1:11 PM, Benjamin Otte wrote:
> This is actually a rather ugly situation right now: Everything in the
> widget but the draw function (key press events etc) uses coordinates
> relative to the GdkWindow, only the draw function doesn't. So when
> calling internal get_offs
On Sat, Sep 11, 2010 at 7:05 PM, Havoc Pennington wrote:
> I'm looking at gtk_scale_draw for example on your branch
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=rendering-cleanup-next#n1159
>
gtk_scale_get_layout_offsets() returns values relative to
widget->window, so takes into accoun
Hi,
On Sat, Sep 11, 2010 at 12:57 PM, Benjamin Otte wrote:
> gtk_paint_*() does - at least in my branch - draw relative to the
> passed in cairo_t. As almost all the paint functions take
> x,y,width,height anyway it doesn't really matter where the origin of
> the cairo_t is. You'll notice in all
On Sat, Sep 11, 2010 at 6:29 PM, Havoc Pennington wrote:
> - in many languages GtkSizeRequest::get_width() is already just
> callable as widget.get_width()
> - plain get_width() more naturally gets request, anyhow
>
Ugh, I'd always assume that widget.get_width() would give me the width
of the widg
Hi,
On Sat, Sep 11, 2010 at 12:15 PM, Benjamin Otte wrote:
> What's you opinion on having gtk_widget_get_width() and
> gtk_widget_get_height() functions? They would just return
> widget->priv->allocation.width/height for now.
>
> Such functions would address your issues and would make writing dra
What's you opinion on having gtk_widget_get_width() and
gtk_widget_get_height() functions? They would just return
widget->priv->allocation.width/height for now.
Such functions would address your issues and would make writing draw
functions pretty much as simple as they are now, without having to
p
On Sat, Sep 11, 2010 at 5:22 PM, Bastien Nocera wrote:
> On Sat, 2010-09-11 at 07:03 +0200, Benjamin Otte wrote:
> It's missing the symbolic icons...
>
I suppose that's because I'm on F13 and F13 oes not have symbolic
icons? At least, I don't have any icons showing up in gtk3-demo
either...
Benja
Hi,
On Sat, Sep 11, 2010 at 11:16 AM, Havoc Pennington wrote:
> I still think passing width, height to draw() is weird.
btw, I guess the argument here (per IRC) is that people might be
confused by allocation.x,y. But this is a really weak band-aid fix for
that, which will be wrong in the long te
On Sat, 2010-09-11 at 07:03 +0200, Benjamin Otte wrote:
> Hey,
> PS: Attached is a rendering of the liststore example from gtk-demo to
> a pdf surface using Raleigh, Clearlooks and EasyListening. Just
> because I want to show off.
It's missing the symbolic icons...
__
Awesome! Some stuff I noticed looking through the branch:
*
A round of rebase/squash might be nice which would make it easier to
review, for example c5c08bafb94e794a88ef5d650999f46b419429ed could
squish into 9badb81a7ed62af1cdf11eb31c7e94293a683429 (I was pretty
confused by the None there at firs
40 matches
Mail list logo
