it's possible something in here is useful:
http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg4.html
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
On Tue, May 31, 2011 at 5:47 AM, Christian Dywan wrote:
> This is a great argument. There was a mistake. It made you notice the API is
> inconsistent, so you suddenly insist that GLib can't be improved further
> without rewriting all the functions
It didn't "make me notice" - I've know
Hi,
On Mon, May 30, 2011 at 8:37 PM, Shaun McCance wrote:
> But I want to point out that my point was never that GLib
> should behave like a language with exceptions. Just that
> it should let bindings in those languages behave like they
> should.
I agree that would be ideal if you were optimizi
Hi,
On Mon, May 30, 2011 at 8:17 PM, Morten Welinder wrote:
> Doing a g_return_val_if_fail is fine here. That will give the user a
> chance of saving his work. This is in contrast to g_error which is a
> sure way of eating data.
If that's the argument it's fine. I treat return_if_fail and g_er
Hi,
Man, how many times has this thread happened? At least fifty.
On Fri, May 27, 2011 at 10:57 AM, Shaun McCance wrote:
> try:
> load_some_extension()
> except:
> warn("This extension sucks. I'm disabling it and moving on.")
>
> Of course, GLib is C. We don't have exceptions. We have GErr
Hi,
On Thu, May 12, 2011 at 9:53 PM, Benjamin Otte wrote:
> Don't assign any extra space to children, use it as space on the
> right/bottom side. (This is the current behavior)
This seems screwy, unless the grid has left/top alignment set. I would
expect the grid to position the children accordi
Hi,
On Fri, May 13, 2011 at 12:00 PM, Matthias Clasen
wrote:
>> Second, if children should never get
>> assigned extra space, why do we have the ALIGN_FILL parameter?
>
> expand is about whether you _want_ the child to receive extra space.
> align=fill is about how the child should react if it _g
czk, another thing you'll need to do to get useful results is run a
lot of iterations. If you get this all going in a loop then you can
run sysprof for a while to get enough data. I would try to keep
running for 20-30 seconds.
To see one-time startup initialization, your loop will have to keep
rel
Hi,
On Sat, Feb 26, 2011 at 9:35 AM, David Zeuthen wrote:
> but if someone writes a nice dbus-daemon(1) patch, we
> would probably accept it, right?
>
I suppose... if they had enough test coverage to prove it actually worked ...
Havoc
___
gtk-devel-l
Hi,
On Fri, Feb 25, 2011 at 9:13 PM, Wen-Yen Chuang wrote:
>
> I suppose GtkApplication users do not need to handle dbus directly.
>
> So if GtkApplication can handle dbus restart / dbus crash, I may also
> consider using GtkApplication for single instance app.
However, the whole restart issue a
Hi,
On Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang wrote:
> a.) restart dbus daemon (and keep everything communicating to dbus
> still working) is not supported by upstream in a sensible way.
> [1][2][3][4]
upstream doesn't support this because it isn't a dbus issue. The
problem is that n
Hi,
It seems like the following would work but maybe I'm missing the obvious
* have the video request natural size = its natural unscaled size, and
min size of whatever lowest scale factor you want to allow
* to snap to natural size, just size request the entire toplevel to
get the natural size,
This document may help you:
http://git.gnome.org/browse/gtk+/tree/docs/text_widget_internals.txt
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen
wrote:
>
> In fact, here it is:
> http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions
Was a bit confused reading this example, what are the hold/release in
the action callbacks about? Would they only be needed
Hi,
On Mon, Nov 1, 2010 at 2:10 PM, Peter Clifton wrote:
>> Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code.
>
> Much as I am a fan of self-documenting code.. isn't "* 1000" much
> shorter and easier?
Well there's already G_USEC_PER_SEC but I guess it's saving typing of
more ze
Hi,
On Mon, Nov 1, 2010 at 1:06 PM, John Ralls wrote:
> I don't see any reason to have a replacement for GDate.
fwiw, the original (and possibly only) use of GDate was for security
price data (Open/High/Low/Close), which has only a day, not a time or
timezone. This is also why GDate is not opaqu
Hi,
On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie wrote:
> The conclusion of all of this is one point: barring substantial
> complaints, the be-all and end-all of time in glib is going to be
> microseconds stored in a gint64.
Your arguments sound right and a nice upgrade over current APIs.
Maybe
Hi,
On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor wrote:
> - We should not start painting the next frame until we are notified
> the last frame is complete.
Does frame-complete arrive when "we just did the vsync" i.e. last
frame is just now on the screen?
We can dispatch "other stuff" while w
Hi,
On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis wrote:
> you guys are working out an incredibly complex and potentially baroque
> solution when the elegant and arguably "correct" one has already been
> implemented several times in different contexts. what's the point?
>
There's a lot of text in
Hi,
On Fri, Oct 22, 2010 at 4:48 PM, Owen Taylor wrote:
> I think we're largely agreeing on the big picture here - that priorities
> don't work so there has to be arbitration between painting and certain
> types of processing.
Right, good. The rest is really just details - there are various ways
Hi,
On Fri, Oct 22, 2010 at 5:06 PM, Paul Davis wrote:
> starting from scratch, and thinking about the parallels with a
> pull-model realtime audio design, it seems to me that if you were
> designing this entirely from scratch you wouldn't serialize painting
> and other source handling. you'd dou
Hi,
On Fri, Oct 22, 2010 at 10:28 AM, David Zeuthen wrote:
> If you believe that the GUI thread should never perform blocking IO
> (such as reading from disk or IPC) or never perform CPU-intensive
> tasks (such as image- or video-decoding) then... then all that your
> code in the GUI thread does,
Hi,
On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie wrote:
> - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
> microseconds (same story with struct timeval vs. struct timespec).
> The librt interfaces provide this level of accuracy so it would be a
> shame to needle
Hi,
On Fri, Oct 22, 2010 at 10:24 AM, Owen Taylor wrote:
> Is painting well behaved? Inherently - no. We can easily get in
> situations where we can spend all our time painting and no time doing
> anything else.
That's the point of the up-to-5ms-of-dispatch thing (or the
wait-for-frame-complete
Hi,
On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen wrote:
> Note that with GDBus the resulting GDBusMessage is actually being
> built in a separate (and private) thread - so in practice there is
> zero overhead in the GUI thread - in particular it doesn't depend on
> what kind of message it is or
Hi,
I guess a frame-complete signal (or timer) acts like the 5ms to create
a window for other event sources to run? So painting should not starve
other stuff, the mainloop could dispatch other stuff while the frame
is being completed. Given a gap waiting for frame-completed you don't
need a hardco
Hi,
On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie wrote:
>
> What about non-input events, though? Like, if some download is
> happening and packets are coming in and causing dispatches from the
> mainloop that we do not have control over.
I brought this up a bit in the earlier thread.
My takeaw
Hi,
On Thu, Oct 21, 2010 at 4:26 AM, Emmanuele Bassi wrote:
> no, the GL context should *not* be per window. multiple GL contexts
> usually pose more problems than they solve, in synchronization and
> context switching, on basically all drivers - except maybe on nvidia[0].
Fair enough, I didn't
Another issue, seems like the ticker needs to be per-native-window:
* the GL context is per-window so the vsync mechanism also is
* we ought to shut down the ticker on windows that aren't visible
* each screen has its own vsync and the window is the normal
convention to imply a screen
* the gen
Hi,
On Tue, Oct 19, 2010 at 7:49 AM, Carlos Garnacho wrote:
> * There is no intuitive replacement for gtk_widget_modify_*(). If we are
> to drop GtkStyle, I think that 3rd party libraries and apps implementing
> widgets could define regions and attach a GtkStyleProvider with the
> fallback priori
Hi,
On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
wrote:
>
> What happens when another subclass wants to use
> ->adjust_size_allocation() to realign itself further ? how
> can it cooperate with GtkWidgetClass and not cause bad side
> effects ?
In the patch I posted (assuming the FIXME is
Hi,
Here's roughly what I'm thinking about. This is an untested patch with
a big FIXME in it (FIXME must be fixed to have a hope of working). But
I thought since you were poking at this I better share sooner than
later. Maybe there is some glaring problem here but just wanted to
communicate the co
Hi,
I would think of it like this maybe
real_adjust_request(orientation, &request_data)
{
adjust_request_by_adding_margin(orientation, &request_data)
/* alignment does not affect request */
}
real_adjust_allocation(orientation, &allocation_data)
{
adjust_allocation_by_removing_margin(orie
Hi,
On Fri, Oct 15, 2010 at 11:32 AM, Havoc Pennington wrote:
>
> Without trying to code it and see if it works, it could look like:
>
> (* adjust_size_allocation) (GtkWidget *widget,
> GtkOrientation orientation,
>
Hi,
I think I get what you're saying. If not I'll probably understand it
reading your code.
btw things are looking kind of messed up to me in the current code in
gtkwidget.c ... this:
gtk_widget_get_preferred_width (widget, NULL, &natural_width);
get_span_inside_border_horizontal (wi
Hi,
On Fri, Oct 15, 2010 at 9:55 AM, Havoc Pennington wrote:
> I think you should just call the request methods again. (Not the
> wrappers of course, the vfuncs directly.) Instead of passing in a
> natural size.
>
I guess this doesn't work when chaining u
Hi,
On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom
wrote:
> The for_size fed to widget implementations additionally needs to
> strip the added padding that can happen in ->adjust_size_request()
Right, adjust_size_allocation should basically invert anything
adjust_size_request does so the wi
In sounds like in short the for_size somehow needs to be adjusted
(strip out the pixels that adjust_size_request added). (If I'm
understanding properly.) Of course that's what adjust_size_allocation
does, except it's both dimensions. for_size is after all the proposed
allocation size in one dimensi
Hi,
On Tue, Oct 12, 2010 at 12:38 PM, Havoc Pennington wrote:
> d) max size widget can do something useful with
> e) size at which widget acts like expand=false (this is what I'd call
> "max size" and I think it's a feature GTK doesn't have right now)
Tryin
Hi,
On Tue, Oct 12, 2010 at 12:09 PM, Owen Taylor wrote:
> I think you need to think very carefully about how natural width is
> explained and documented, since it seems to be neither exactly:
>
> - the maximum useful width
> - a "good width" for the widget
>
> I get the impression from the abo
Hi,
On Tue, Oct 12, 2010 at 11:40 AM, Tristan Van Berkom
wrote:
> And currently the "min useful" is just not defined as
> "a single word width".
>
Understood, I think we basically agree.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
h
Hi,
On Tue, Oct 12, 2010 at 11:20 AM, Tristan Van Berkom
wrote:
> I'm not sure what exactly you are talking about here, the only guess
> a label currently makes is for a reasonable "width-chars", i.e. limiting
> a wrapping label to a reasonably large minimum width. This is to avoid
> unreasonably
I guess to me it's much better to have one hack in GtkWindow globally
(GtkWindow is already a giant special case) than to leak the hack into
all widgets that actually do h-for-w. Just a separation of concerns
thing. It doesn't make sense for N child widgets inside a window to
all be trying to heuri
Hi,
On Tue, Oct 12, 2010 at 2:44 AM, Tristan Van Berkom
wrote:
> On Mon, 2010-10-11 at 15:30 -0400, Owen Taylor wrote:
>> On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote:
>> > Agreed, GtkLabel needs to report min size = true min sane size and
>> > natural s
Hi,
On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor wrote:
> Setting the hints dynamically based on the current width can work, if
> we're willing to say "screw wireframe resizing" (wireframe resizing
> doesn't completely *not* work, you just have to release and retry
> a few times to get to certain
indow, or whatever. Or maybe GtkWindow should
constrain the default size to "nice aspect ratio" somehow, solving
globally for the window instead of per-label.
Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington
Date: Mon, 6 Sep 2010 11
Hi,
On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson wrote:
> First of all, what happened to Bug 628902 "Add expand flags to
> GtkWidget". It seems to have stalled. This would be very useful.
>
The latest code is on widget-expand-3 branch, fwiw.
todo items are:
* magic resizability behavior
Hi,
On Sun, Oct 10, 2010 at 10:41 AM, Tristan Van Berkom
wrote:
> I would only expect the expand to be distributed evenly among
> children as, thats what GtkBox does ;-)
But the whole point of the exercise is to mop up GtkBox cruft...
> I'm not sure that having all the children stop expanding
>
Hi,
On Sun, Oct 10, 2010 at 6:36 AM, Tristan Van Berkom
wrote:
> bottom or right size of the Grid. (if the user wants the
> grid children not to expand at all, they should only have
> to pack the whole grid into another container and say that
> the grid does not expand).
Or set halign/valign on
Hi,
On Thu, Oct 7, 2010 at 1:18 PM, Federico Mena Quintero
wrote:
> However, who writes UIs by hand these days? Doesn't everyone just use
> Glade?
It's a valid point, but I don't know that Glade is always easiest. I
don't think it's a good excuse for making the actual API crappy.
(In fact I'd
Hi,
On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom
wrote:
> However I would really appreciate it if a widget's placement
> inside a container can still be clearly introspected and defined
> with container child properties (in other words I think the widget
> should be built with child proper
Oh, another thing to have is probably h-spacing and v-spacing for the
grid-wide space between rows and columns. For per-column or per-row
spacing you could use a margin or a spacer widget placed on that row
(?)
If not clear the idea of the exercise I was doing is to figure out how
you'd naturally
I think a picture would be helpful ;-)
Are we sure this is of general interest? It seems like something only
a few percent of apps would end up using.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/
Hi,
Oh, I see now it's a WrapBox replacement I guess (reading threads out of order)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi,
Maybe the very very simple first step that punts on all the hard stuff
is to do a queue-redraw virtualization like this:
http://git.clutter-project.org/clutter/commit/?id=961aac3fb36f73d4a48720d93b8928a3e24b5b84
The default implementation of this in GtkWidget would invalidate on
GdkWindow, b
Hi,
On Sat, Oct 2, 2010 at 7:32 PM, Soeren Sandmann wrote:
> FWIW, I put up the notes I wrote about this subject here:
>
> http://www.daimi.au.dk/~sandmann/framehandlers.txt
>
> They were written with a different toolkit than GTK+ in mind, so they
> make various assumptions that don't appl
Hi,
On Sat, Oct 2, 2010 at 8:57 PM, Matthias Clasen
wrote:
> If we move to a fixed order of doing things each frame, like Owen
> described here:
> http://blog.fishsoup.net/2009/05/28/frames-not-idles/
A link I obviously should have included, thank you
>, then the paint
> clock could perhaps jus
Hi,
On Sat, Oct 2, 2010 at 6:37 PM, Xavier Bestel wrote:
> * how do you handle multimonitor setups where an application can have 2
> different vblanks to care about ?
>
Separate paint clock per toplevel, I guess. The approach in the patch
of gdk_window_set_paint_clock() would support that. It so
Hi,
2010/9/26 Javier Jardón :
>
> It returns a pointer to a GObject now
>
Shouldn't it just return a GtkAdjustment* ? returning GtkObject was
some weird legacy thing.
Also, isn't gtkobject still there in master?
http://git.gnome.org/browse/gtk+/tree/gtk/gtkobject.h
Havoc
___
A couple other ideas, just to put more options in the pile.
Minor concern. gdk_event_set_coords() and set_source() could be
problematic in that GdkEvent would become a mutable non-GObject. This
is normally considered Bad language-binding-wise. Though in this case,
the implications are perhaps limi
Hi,
On Wed, Sep 22, 2010 at 10:28 AM, Matthias Clasen
wrote:
>
> Isn't that handled by containers simply not calling draw on covered up
> or hidden children ?
>
yeah, quite possibly. Especially if we move animations into a magic
master clock that would also be stopped.
Havoc
___
Hi,
On Wed, Sep 22, 2010 at 8:55 AM, Paul Davis wrote:
>
> i think you might want to consider MAP and UNMAP
I was thinking the vfuncs (already called on no-window) and map/unmap
signals would be fine. i.e. I agree map is interesting for no-window,
but I don't think ::map-event adds anything over
Hi,
I've been exploring how widgets with no GdkWindow could receive
events. Here are some notes so far in case people have thoughts.
Event Types
===
Events separate very cleanly into "weird lowlevel stuff only matters
for GdkWindow" and "things widgets in general including no-window
widgets care
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
+ 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
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
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
Hi,
On Mon, Sep 13, 2010 at 7:06 AM, Tristan Van Berkom
wrote:
> Heh, do you mean GtkWindow widgets or GtkWidgets that have their own
> GdkWindow ?
Widgets that have their own GdkWindow
i.e. I was proposing that when adjusting a size request,
if (gtk_widget_get_window(widget))
{
if (*minimum
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
c just not do this?
Havoc
From 218ab01aa87e9344f6708ae32d74503014508905 Mon Sep 17 00:00:00 2001
From: Havoc Pennington
Date: Sun, 12 Sep 2010 21:43:39 -0400
Subject: [PATCH] Add documentation on adjust_size_request adjust_size_allocation
Also note in the docs for various other functions, whethe
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
Hi,
I pushed a widget-padding-2 branch which has everything cleaned up.
Both widget-padding and widget-padding-2 can be deleted once this is
merged.
(I can merge if you like or feel free. or let me know what else to change.)
While messing with branches, I noticed hp-patches and havoc-patches
bran
Hi,
On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte wrote:
> Uh, you've found out about one of my secret projects. Actually, what
> I'm aiming at is reftests (see
> http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for
> a description). They are independant of font settings, themes
Hi,
On Sun, Sep 12, 2010 at 1:33 AM, Tristan Van Berkom
wrote:
> Ok I see, so we end up with:
> - set_size_request() Can be used to increase the minimum request
I was thinking this should stay backward compatible and allow lowering
it, fwiw. Though I can't actually come up with a use case, I'm
out keeping the old name also.
btw along these lines, I can't remember if I filed the attached patch.
Natural size much less useful without it.
Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH
Something that occurred to me mid-bisect is that with Benjamin's
draw() work, it would probably be straightforward to write the
following test program:
* instantiate every widget type in GTK (or even various modes of every
widget type, like different text styles, wrap or not, padding/border
or not
Hi,
On Sat, Sep 11, 2010 at 11:41 PM, Matthias Clasen
wrote:
> Turns out this is unrelated to your branch. I've bisected this to
>
Oops, I just burnt a hole in my lap bisecting this too. At least _one_
of those checkouts could have managed not to rebuild the whole tree...
I got to this commit t
Hi,
I pushed the changes I had in mind to the widget-padding branch. I
have a rebased/squashed branch cleaned up for merging, too, if anyone
wants me to push or send that version.
the changes are:
733991c84df4300ec54af8b557385759a93360f0 Rename GtkWidget padding to margin
83008588e162b78f8f66ba3
Hi,
Just thinking, in the new GtkSizeRequest world it's probably more
useful to set natural size than minimum size.
With Clutter, what we often find ourselves wanting to do at litl is
"set natural size, clamping it to be larger than minimum size"
So for example setting natural size to 0 would me
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
a
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
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
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
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
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 l
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
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-
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
__
I forgot that GtkWidget::parent already works:
g_object_new (TYPE_FOO, "parent", box, "blah", 42, NULL)
This is a pretty nice solution I think. You don't even have to save a
pointer to the new object if you aren't doing anything other than
adding it to parent and setting a couple of props.
Havoc
Hi,
On Mon, Sep 6, 2010 at 8:18 PM, Matthias Clasen
wrote:
> In particular the automatic window resizability will be nice.
Unfortunately this part is scary ;-) a whole lot of the gtkwindow.c
code related to this was last touched by me in 2001, some was last
touched even earlier than that, and I
With
https://bugzilla.gnome.org/show_bug.cgi?id=628828
and
https://bugzilla.gnome.org/show_bug.cgi?id=628902
Box and Table are pretty much all messed-up. They have a bunch of
redundant flags to specify, and their redundant fill flag is a problem
because it has the wrong default (must always be tru
Hi,
This is a major enough change it should probably hit the list and not
just bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=628902
The patch needs finishing as noted in the bug but you can already play
with it, it just is missing some production details.
Havoc
___
Hi,
On Mon, Sep 6, 2010 at 10:06 AM, Emmanuele Bassi wrote:
>> ‣ undo combobox / option menu mix ?
what is the argument on this? sounds like going in circles ;-)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mai
https://bugzilla.gnome.org/show_bug.cgi?id=628828
has a patch ready for review.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 AP
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-
1 - 100 of 350 matches
Mail list logo
