Re: glib branched
On Wed, 2012-10-03 at 08:20 +0200, David Nečas wrote: > On Wed, Oct 03, 2012 at 12:35:57AM -0400, Matthias Clasen wrote: > > I have now created a glib-2-34 branch, so master is now open for > > ... GTask ... > > Is this also intended, at least in the future, for things like > long-running calculations that need some monitoring/reporting of > progress not just the final result? I mean, some monitoring can be > always implemented on top of GTask but once I get my hands dirty with > explicit asynchronous communication I can implement that directly on top > of GThread as well. I always look hopefully at the asynchronous > interfaces in GLib with hope, however, the intended use cases do not > seem to match mine... Popping results out of a running thread is easy to do. Create a GAsyncQueue. In your thread, add your results to the queue, a schedule a function to be called from the main loop with g_idle_add(). In your g_idle_add() callback, use g_async_queue_pop() to get the results, and free your results. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: "reversible"
Not a lot of serious feedback here, but I also worry about the implicitness about this API. Its really not well defined what it does, and the fact that it may change over time as functions are implemented differently or new things support reversible just seems scary. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
Hi Tristan!
> I suggest you start by filing an enhancement bug against GtkImage for this.
Yes, I can do that. Just to make sure, I file a new bug for component gtk,
severity set to enhancement, and put somethign like "Size request of GtkImage"
into the title. Is this correct?
> If you have a patch to propose, here would be a good place to discuss
> the proposed new apis.
I might also be able to work on this and provide a patch. Before starting on
this, how about the following changes:
Regarding size request:
We add a new property of type boolean to GtkImage. If it is set (default), the
size request for GtkImage will be the size of the underlying image (or the
pixel-size), i.e. the exact same behaviour as it is now. If it is set to FALSE
then the minimum size will be (1, 1) and an application can use "width-request"
and "height-request" for making the widget size larger. I am not sure what a
good name for this new property would be, but maybe you have a suggestion?.
Something like "min-size-is-image-size" would probably make the property
self-explanatory but is obviously too long compared to other existing property
names. Maybe "full-image" or "image-size-request"?
Regading placement:
In GTK2, GtkImage cropped the image such that only the center is shown, i.e. it
took off an equal amount of image content on the left and right, and top and
bottom. It probably just sets the right clipping mask when drawing the image
for achieving this. We could simply use the same policy, or we modify the
usage of GtkWidget's "halign" and "valign" properties. Currently the docs
reads:
"halign" GtkAlign : Read / Write
How to distribute horizontal space if widget gets extra space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with extra space in a single (x or y)
dimension.
Alignment only matters if the widget receives a "too large" allocation,
for example if you packed the widget with the "expand" flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch to fill all space if possible, center if no meaningful
way to stretch
GTK_ALIGN_START snap to left or top side, leaving space on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space on left or top
GTK_ALIGN_CENTER center natural width of widget inside the allocation
My suggestion is to make halign and valign also deal with the case where the
content of the widget is larger than the allocated space. The modified docs
would then read:
"halign" GtkAlign : Read / Write
How to distribute horizontal space, see GtkAlign
enum GtkAlign
typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END, GTK_ALIGN_CENTER
} GtkAlign;
Controls how a widget deals with space in a single (x or y)
dimension.
Alignment only matters if the widget receives a "too large" or "too small"
allocation,
for example if you packed the widget with the "expand" flag inside a GtkBox,
then the widget might get extra space. If
you have for example a 16x16 icon inside a 32x32 space, the icon
could be scaled and stretched, it could be centered, or it could be
positioned to one side of the space. Likewise, if you have a 100x100 image
inside a 20x20 space
then the image could be scaled down, only the center part of the image be
shown, or it could
be cropped to the top left or bottom right part.
Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
interpreted relative to text direction.
GTK_ALIGN_FILL stretch or shrink to fill all space if possible, or center if no
meaningful way to scale
GTK_ALIGN_START snap to left or top side, leaving space or cropping widget
content on right or bottom
GTK_ALIGN_END snap to right or bottom side, leaving space or cropping widget
content on left or top
GTK_ALIGN_CENTER center widget inside the allocation
Steffen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RadioButtons
Hello everyone, I have several RadioButtons in the same group, but I would like that when first shown they would all be un-active and when the user selects one of them then have the expected behavior. Is this possible? I know I've seen it somewhere, just not sure if somewhere using Gtk+3. Best regards 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RadioButtons
Hi. > I have several RadioButtons in the same group, but I would like that > when first shown they would all be un-active and when the user selects > one of them then have the expected behavior. Is this possible? I know > I've seen it somewhere, just not sure if somewhere using Gtk+3. The easiest way of achieving this is to add one hidden radio button to your group and make it active at the start. This way all other buttons will be initially inactive. Cheers, Tadej -- Tadej Borovšak tadej.borov...@gmail.com tadeb...@gmail.com tadeboro.blogspot.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib branched
On Wed, Oct 03, 2012 at 09:06:19AM +0200, Bastien Nocera wrote: > Popping results out of a running thread is easy to do. > > Create a GAsyncQueue. > In your thread, add your results to the queue, a schedule a function to > be called from the main loop with g_idle_add(). > > In your g_idle_add() callback, use g_async_queue_pop() to get the > results, and free your results. I know this approach and it is not what I call monitoring because it is worker-initiated. I only want to report progress if and when someone asks. Otherwise either you have to very carefuly tune the work chunk sizes, or you get skippy status updates sometimes and too much communication other times. But OK, I will continue to implement these things myself... Regards, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On Thu, Oct 4, 2012 at 1:46 AM, Steffen Gutmann wrote:
> Hi Tristan!
>
>> I suggest you start by filing an enhancement bug against GtkImage for this.
>
> Yes, I can do that. Just to make sure, I file a new bug for component gtk,
> severity set to enhancement, and put somethign like "Size request of
> GtkImage" into the title. Is this correct?
Right, the bug might have to do more with cropping/scaling support in
GtkImage, rather than it's size request.
>
>> If you have a patch to propose, here would be a good place to discuss
>> the proposed new apis.
>
> I might also be able to work on this and provide a patch. Before starting on
> this, how about the following changes:
>
> Regarding size request:
>
> We add a new property of type boolean to GtkImage. If it is set (default),
> the size request for GtkImage will be the size of the underlying image (or
> the pixel-size), i.e. the exact same behaviour as it is now. If it is set to
> FALSE then the minimum size will be (1, 1) and an application can use
> "width-request" and "height-request" for making the widget size larger. I am
> not sure what a good name for this new property would be, but maybe you have
> a suggestion?. Something like "min-size-is-image-size" would probably make
> the property self-explanatory but is obviously too long compared to other
> existing property names. Maybe "full-image" or "image-size-request"?
>
> Regading placement:
>
> In GTK2, GtkImage cropped the image such that only the center is shown, i.e.
> it took off an equal amount of image content on the left and right, and top
> and bottom. It probably just sets the right clipping mask when drawing the
> image for achieving this. We could simply use the same policy, or we modify
> the usage of GtkWidget's "halign" and "valign" properties. Currently the
> docs reads:
>
> "halign" GtkAlign : Read / Write
While it's true that the align properties make no sense when the
widget's natural size is equal to,
or exceeds the widget's allocation; I'm not exactly sure it's a good
idea to use the GtkWidget's
halign/valign properties directly (i.e. it's like hidden candy, people
wont see it evidently in
the docs/headers for GtkImage and so will probably not discover it).
However I do like the idea of GtkAlign properties for that, where FILL
would mean scale
and CENTER/START/END have the obvious clipping behaviors.
It would have to deal well with situations where the user asked the
image to scale (FILL)
horizontally but to clip vertically ;-)
Also, it should have reasonable behaviors defined for the various
configurations of
a GtkImage (i.e, how does GtkIconSize fit into this ? does it make
sense to allow
the image to try loading the given icon at different sizes to satisfy
the allocation ?
naturally the natural size of the image would have to still be determined by the
user specified icon size, in the case that GtkImage be allocated extra space,
should a larger icon size be tried ? and should the image be upscaled as
a fallback or in situations where the source is a GdkPixbuf ?)
If you're serious about working on this, I would open an enhancement bug
and put your ideas there. You'll be sure to receive more feedback if you do
provide a patch with some test cases showing how it works.
Cheers,
-Tristan
>
> How to distribute horizontal space if widget gets extra space, see GtkAlign
>
> enum GtkAlign
> typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END,
> GTK_ALIGN_CENTER
> } GtkAlign;
>
> Controls how a widget deals with extra space in a single (x or y)
> dimension.
>
> Alignment only matters if the widget receives a "too large" allocation,
> for example if you packed the widget with the "expand" flag inside a GtkBox,
> then the widget might get extra space. If
> you have for example a 16x16 icon inside a 32x32 space, the icon
> could be scaled and stretched, it could be centered, or it could be
> positioned to one side of the space.
>
> Note that in horizontal context GTK_ALIGN_START and GTK_ALIGN_END are
> interpreted relative to text direction.
> GTK_ALIGN_FILL stretch to fill all space if possible, center if no meaningful
> way to stretch
> GTK_ALIGN_START snap to left or top side, leaving space on right or bottom
> GTK_ALIGN_END snap to right or bottom side, leaving space on left or top
> GTK_ALIGN_CENTER center natural width of widget inside the allocation
>
> My suggestion is to make halign and valign also deal with the case where the
> content of the widget is larger than the allocated space. The modified docs
> would then read:
>
> "halign" GtkAlign : Read / Write
>
> How to distribute horizontal space, see GtkAlign
>
> enum GtkAlign
> typedef enum { GTK_ALIGN_FILL, GTK_ALIGN_START, GTK_ALIGN_END,
> GTK_ALIGN_CENTER
> } GtkAlign;
>
> Controls how a widget deals with space in a single (x or y)
> dimension.
>
> Alignment only matters if the widget receives a "too large" or "too small"
> allocation,
> for example if you packe
Frame synchronization status
I've just pushed publically wip/frame-synchronization branches for Mutter and GTK+ that include my long-delayed work to get proper synchronization going between the toolkit and the compositor. This is the work that I spoke about and demo'ed at GUADEC. The patches are also in bugs: GTK+: https://bugzilla.gnome.org/show_bug.cgi?id=685460 Mutter: https://bugzilla.gnome.org/show_bug.cgi?id=685463 For those who prefer to look at patches that way. The GTK+ patch is a hybrid between my “modernizing the display loop” mail: https://mail.gnome.org/archives/gtk-devel-list/2011-December/msg00082.html and the work that Havoc started in: https://mail.gnome.org/archives/gtk-devel-list/2010-October/msg4.html I started from Havoc's work, removed some parts of it that didn't make sense to me, then added multiple phases, layout, compositor synchronization, and motion event compression. I'll send out some follow up mails with more details about how the event compression works and about remaining questions and TODO items. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Frame-based motion event compression
One of the concepts of the paint-clock work is that it also should be used for event delivery and compression. The idea is that instead of continually delivering events and possibly never getting to updating, we batch up events and deliver them right before doing the other work of the frame. This allows to "look ahead" and compress consecutive motion events. This is the approach that was taken for Clutter. However, doing it for GTK+ would create serious compatibility because it's very common in current GTK+ programs to add idle handlers that have a more urgent priority than GDK_PRIORITY_RESIZE, and expect those handlers to actually be run before resizing. I found about 70 idles being added at a priority above RESIZE in the GNOME code checked out on my laptop. It's hard to say how many of these actually are triggered from event handlers, but some of them certainly are. The alternate approach I took was instead to make the paint clock install two separate idle handlers, so we have the following sources from high to low in priority: G_PRIORITY_DEFAULT - GDK Event Handling - Events are proccessed, motion events are not flushed to GTK+ until some other events comes in. Consecutive motion events are deleted. G_PRIORITY_DEFAULT + 1 - ::flush-events Pending motion event is flushed Event delivery is paused GDK_PRIORITY_REDRAW ::before-paint ::update Animations are updated ::layout size request and size allocate ::paint Everything is redrawn ::after-paint ::resume-events Event delivery is resumed Pausing the event delivery is necessary because if you don't pause event delivery, then if the motion event delivery takes significant amount of time and more motion events arrive, you will return immediately to the event source at G_PRIORITY_DEFAULT and never get to drawing. The current implementation of this in my branch is fairly simplistic in how it does motion event compression - it only ever compresses motions if they are completely consecutive in the event queue - any other events, even if they are completely unrelated to the mouse will flush out motion events and prevent compression. More sophisticated approaches are possible but may not be necessary. We've already done a lot of work at suppressing mouse lag in the GTK+ core, so there wasn't much noticeable affect for things like dragging scrollbars, but the patch does make a huge difference for an artificial test case I wrote that calls g_usleep() in its motion event handler. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Partial frame synchronization TODO
Here's the dump of my current TODO list for finishing up the frame synchronization work. If things on this list are things you want to work on, speak up - there's more here than I'll be able to do in any short amount of time. Major Stuff Inside GTK+ === * Implement paint synchronization for the OS X backend. This basically means that after we submit a frame we want to use CVDisplayLink to find out when it makes sense to start drawing the next one. * Implement paint synchronization for the Window backend. It's less clear how to do this - I suspect there are some sensible approaches using DwmGetCompositionTiminginfo() and QueryPerformanceCounter() to figure out an appropriate time to sleep before drawing the next frame, but it would take some experimentation. * Implement paint synchronization for the Wayland backend. This may be straightforward if the protocol already has the right messages for frames being drawn, or may require protocol extensions. ? Implement paint throttling for the Broadway backend. (I'm not sure what this means exactly - the default throttling to 60fps may be OK.) * When there is a frame where no painting ends up being done, we still at the moment are sending increments to the frame serial and waiting for_NET_WM_FRAME_DONE. It may be worth tracking when we are about to damage a toplevel window (by drawing or configuring it) and only at that point start a frame. Then we'll avoid asking the compositor to tell us when it's done painting a frame that involves no painting. Minor stuff inside GTK+ === * Rename GtkTimeline:progress-type to GtkTimeline:timing-function and sync definitions to be exactly the same as CSS if they aren't. * Make GtkIconView, GtkTextView, GtkTreeView do the pre-layout layout handling in an ::update handler (is this right? should it happen after ::update and before redraw? connect-after to ::update?) * Consider whether GtkIconView/GtkTextView/GtkTreeView should do the incremental validate step in ::after-paint rather than in a low priority idle. Doing it in a timeout means that an animation could completely starve animation. * Figure out what to do with GtkEntry::recompute-handler * Right now, we do "scan scrolling" (that is, dragging past the end to scroll) by adding a timeout and periodically advancing a jump that's influenced by how far the pointer is off the end. We possibly should do this scrolling in an ::update handler instead and make it smooth by advancing by a velocity * time rather than a fixed jump. (GtkComboBox, GtkIconView, GtkMenu, GtkTextView, GtkTreeView) * Make GtkWindow not ever call gdk_window_process_updates() and always work within the paint cycle. * Handle switching to a different window manager when we are pending waiting for _NET_WM_FRAME_DONE - I think this can cause a hang, though it may be that we'll always get an UnmapNotify signal. Outside GTK+ * Fix up Metacity, Mutter, gnome-canvas (evolution, gcompris, any other cut-and-pastes), WebKit for adding idle handlers either between GTK_PRIORITY_RESIZE and GDK_PRIORITY_REDRAW or at GDK_PRIORITY_REDRAW - this never really worked, and will work less well now. * Do a good job on integration of GtkClutter with this system - both directions of embedding to figure out what API changes are needed. * Hook up GStreamer to the paint clock - find out if any changes are needed. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Frame synchronization open questions
Some open questions in my head about the frame synchronization work: * Is GdkPaintClock the right name? It might imply that it only has to do about painting and not about other things like layout. GdkFrameClock would be an alternative. GdkClock is possible but likely too generic. * For pausing the main event delivery, what we currently do is that we queue events but don't dispatch them. This could conceivably cause ordering problems for apps that use filters, or for work in GDK that is done at the translate stage - since we are not pausing translation, just pausing delivery. Alternatives: - Remove the file descriptor and don't unqueue events from the OS queue until event delivery is unpaused. Since we can wait and sleep currently while event delivery is paused, we have to be careful that we don't spin in this case. - Unpause event delivery earlier - before we freeze waiting for _NET_WM_FRAME_DRAWN. Then we don't need to worry about spinning when there are OS events pending, since we'll never sleep with event delivery paused. * Do we need something like GtkTimeline but "rawer" - where you can just get updates and a raw elapsed time? Should we make GtkTimeline with a negative duration do this with the progress being the elapsed time? * Is it OK for the paint-clock to be an immutable property set at GdkWindow construction time? Right now, it's mutable, but not notified, and not handled within gtk. * Right now GdkPaintClockTarget only has a set_clock() method. Would it make sense to also have it have a update() method, and have the behavior that adding a paint clock target to a widget or directly to a GdkPaintClock implicitly requests the ::update phase until the target is removed? This would simplify the code in the places where I'm using GdkPaintClockTarget currently a bit, but I don't see implementing GdkPaintClockTarget directly to be a common thing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Partial frame synchronization TODO
This all sounds fantastic, but I have a stupid question: On Thursday, October 4, 2012, Owen Taylor wrote: > > * When there is a frame where no painting ends up being done, we still > at the moment are sending increments to the frame serial and waiting > for_NET_WM_FRAME_DONE. It may be worth tracking when we are about to > damage a toplevel window (by drawing or configuring it) and only at > that point start a frame. Then we'll avoid asking the compositor to > tell us when it's done painting a frame that involves no painting. > Does this mean we have a busy idle? Does this have implications for laptop battery life? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
