Re: Handle Enter pressing at GtkEntry
On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the activate signal, but for some reason documentation says Applications should not connect to it. My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton::file-set
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:
#include gtk/gtk.h
int main(int argc, char **argv)
{
GtkWidget *window, *chooser;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
chooser = gtk_file_chooser_button_new(NULL,
GTK_FILE_CHOOSER_ACTION_OPEN);
gtk_container_add(GTK_CONTAINER(window), chooser);
g_signal_connect_swapped(chooser, file-set,
G_CALLBACK(g_print), file-set\n);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
What am I supposed to do? I can provide my custom dialog to
GtkFileChooserButton but checking when the file has changed in a
file chooser seems a too natural request for requiring such
effort.
Ciao.
--
Nicola
[1] https://bugzilla.gnome.org/show_bug.cgi?id=555351
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, 2012-10-03 at 20:18 +0200, David Nečas wrote: On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the activate signal, but for some reason documentation says Applications should not connect to it. My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti I asked a similar question some time ago https://mail.gnome.org/archives/gtk-list/2012-March/msg00033.html Seems that the irritating statement Applications should not connect to it, but may emit it... http://developer.gnome.org/gtk/stable/GtkEntry.html#GtkEntry-activate is removed for current GTK3. Thanks. http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkEntry-activate ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton::file-set
On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:
#include gtk/gtk.h
int main(int argc, char **argv)
{
GtkWidget *window, *chooser;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
chooser = gtk_file_chooser_button_new(NULL,
GTK_FILE_CHOOSER_ACTION_OPEN);
gtk_container_add(GTK_CONTAINER(window), chooser);
g_signal_connect_swapped(chooser, file-set,
G_CALLBACK(g_print), file-set\n);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
What am I supposed to do? I can provide my custom dialog to
GtkFileChooserButton but checking when the file has changed in a
file chooser seems a too natural request for requiring such
effort.
Well, I'm not 100% sure what you mean (and that callback of yours
looks like it's only working by chance), but the change on cancel was
recently fixed in bug 645065 in regard of gtk 3.4 and 3.6 (unfortunately, not
in 2.24 though, even if it seems to be only a matter of a cherry-pick).
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkFileChooserButton::file-set
Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło
galtge...@gmail.com scrisse:
On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:
#include gtk/gtk.h
int main(int argc, char **argv)
{
GtkWidget *window, *chooser;
gtk_init(argc, argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
chooser = gtk_file_chooser_button_new(NULL,
GTK_FILE_CHOOSER_ACTION_OPEN);
gtk_container_add(GTK_CONTAINER(window), chooser);
g_signal_connect_swapped(chooser, file-set,
G_CALLBACK(g_print), file-set\n);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
What am I supposed to do? I can provide my custom dialog to
GtkFileChooserButton but checking when the file has changed in a
file chooser seems a too natural request for requiring such
effort.
Well, I'm not 100% sure what you mean (and that callback of yours
looks like it's only working by chance)
No, this is valid GTK+ code.
but the change on cancel was
recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in
2.24 though, even if it seems to be only a matter of a cherry-pick).
What I mean is pressing ESC or clicking cancel unset the file name
and I didn't find a way to catch it: this is not the same issue.
I'm using gtk 3.4.4 but I don't think it is relevant.
Ciao.
--
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkFileChooserButton::file-set
On Thu, Oct 04, 2012 at 12:33:24AM +0200, Nicola Fontana wrote: Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło galtge...@gmail.com scrisse: but the change on cancel was recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in 2.24 though, even if it seems to be only a matter of a cherry-pick). What I mean is pressing ESC or clicking cancel unset the file name and I didn't find a way to catch it: this is not the same issue. I'm using gtk 3.4.4 but I don't think it is relevant. It's in fact not only the *very same* problem, but also while it *was* fixed on 3.4 branch, there was no release there yet containing this commit from this branch - it's post 3.4.4. PS: there's no need to CC me explictly - this is one of a few lists I'm subscribed to, that I didn't turn the delivery off. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev muta...@rambler.ru wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry gtk_entry_set_activates_default() is probably what you want. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: glib branched
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... Thanks, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_home_dir (), ${HOME}, and getpwuid ()-pw_dir
Debarshi Ray rishi...@lostca.se writes:
Also to note is that non-GNOME (and even non-desktop) GLib-based
applications were seen in the wild. Consider, e. g., the OpenBSD
version of the Netcat command-line networking diagnostic tool (as of
the version currently in Debian stable [4].) And I'm not yet sure
that the developers of these packages will be eager to implement the
support for the aforementioned variables.
Git supports them:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.12.txt#L18-23
ACK, thanks for the information.
However, contrary to GLib, Git actually follows the
specification [1] by falling back to ${HOME}/.config should
XDG_CONFIG_HOME be unavailable. It doesn't seem to use
getpwuid () there at all.
--cut: https://raw.github.com/git/git/master/path.c --
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
char *home = getenv(HOME);
char *to_free = NULL;
...
if (!xdg_home) {
to_free = mkpathdup(%s/.config, home);
xdg_home = to_free;
}
...
}
--cut: https://raw.github.com/git/git/master/path.c --
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html
--
FSF associate member #7257
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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: gtk_widget_set_size_request stopped working with GTK3
On Thu, Oct 4, 2012 at 1:46 AM, Steffen Gutmann muib...@yahoo.com 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 packed the widget with the expand flag inside a GtkBox,
then the widget might get extra space.
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 added idle handlers can run 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
