GtkPaned: visible handle?
Hi, according to the documentation (and the image on https://developer.gnome.org/gtk3/stable/GtkPaned.html), GtkPaned-widgets have a visible handle (e.g. 4 dots) to show that the user can drag this handle. Unfortunately, these handles are invisible here -- both in Glade and in the running program. Is there any way to make them visible? thanks, Roland ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkGrid sets no expand with homogeneous
I'd like to port GtkTable to GtkGrid but my cells show big widths.
I have no problem with GtkTable.
The following is the test code.
Could you help me to set no expanded cells with homogeneous in GtkGrid?
scrolled = gtk_scrolled_window_new (NULL, NULL);
gtk_widget_set_size_request (scrolled, 300, 150);
gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolled),
GTK_POLICY_NEVER,
GTK_POLICY_ALWAYS);
gtk_box_pack_start (GTK_BOX (priv-content_box), scrolled, FALSE, FALSE, 0);
viewport = gtk_viewport_new (NULL, NULL);
gtk_container_add (GTK_CONTAINER (scrolled), viewport);
#if GTK_CHECK_VERSION(3, 10, 0)
table = gtk_grid_new ();
gtk_grid_set_row_spacing (GTK_GRID (table), 0);
gtk_grid_set_column_spacing (GTK_GRID (table), 0);
gtk_grid_set_row_homogeneous (GTK_GRID (table), TRUE);
gtk_grid_set_column_homogeneous (GTK_GRID (table), TRUE);
gtk_container_add (GTK_CONTAINER (viewport), table);
for (i = 0; i 12; i++) {
gchar *text = g_strdup_printf (%d, i + 1);
row = i / 4;
col = i % 4;
button = gtk_button_new_with_label (text);
gtk_grid_attach (GTK_GRID (table), button,
col, row, 1, 1);
g_free (text);
}
#else
table = gtk_table_new (row, col, TRUE);
gtk_table_set_row_spacings (GTK_TABLE (table), 0);
gtk_table_set_col_spacings (GTK_TABLE (table), 0);
gtk_container_add (GTK_CONTAINER (viewport), table);
for (i = 0; i 12; i++) {
gchar *text = g_strdup_printf (%d, i + 1);
GtkStyleContext *context;
row = i / 4;
col = i % 4;
button = gtk_button_new_with_label (text);
gtk_table_attach (GTK_TABLE (table), button,
col, col + 1, row, row + 1,
GTK_FILL, GTK_FILL, 0, 0);
}
#endif
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGrid sets no expand with homogeneous
On Wed, 2014-04-02 at 19:40 +0900, Takao Fujiwara wrote: I'd like to port GtkTable to GtkGrid but my cells show big widths. Have you considered this: https://developer.gnome.org/gtk3/stable/GtkGrid.html Description GtkGrid is a container which arranges its child widgets in rows and columns. It is a very similar to GtkTable and GtkBox, but it consistently uses GtkWidget’s “margin” and “expand” properties instead of custom child properties, My guess is that you should set your buttons “expand” property to false. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkLockButton / GPermission
Hi, is there any example for GtkLockButton (and/or GPermission)? I'm trying to use it, but all I get are segfaults (in Python): 1. Adding a GtkLockButton and clicking on it segfaults: $ python from gi.repository import Gtk w = Gtk.Window() b = Gtk.LockButton() w.add(b) w.show_all() Gtk.main() (click) Segmentation fault 2. Trying to use GSimplePermission segfaults: $ python from gi.repository import Gio p = Gio.SimplePermission.new(True) p.acquire(None) Segmentation fault 3. Using a GPermission-subclass works, but using it with the GtkLockButton segfaults again: $ python from gi.repository import Gio, Gtk class dummy_permission(Gio.Permission): def __init__(self): Gio.Permission.__init__(self) self.impl_update(False, True, True) def acquire(self, cancellable=None): self.impl_update(True, True, True) def release(self, cancellable=None): self.impl_update(False, True, True) p = dummy_permission() p.get_allowed() False p.acquire() p.get_allowed() True p.release() p.get_allowed() False w = Gtk.Window() b = Gtk.LockButton() b.set_permission(p) w.add(b) w.show_all() Gtk.main() (click) Segmentation fault Any ideas? Roland ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGrid sets no expand with homogeneous
(04/02/14 20:43), Stefan Salewski-san wrote: My guess is that you should set your buttons “expand” property to false. The expand property does not effect if homogeneous is TRUE in my test. And the expand property is FALSE in GtkWidget by default. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Initial impressions of the gesture branch
Hey :), On lun, 2014-03-31 at 23:10 -0400, Matthias Clasen wrote: Here are some unsorted, initial impressions from looking over the gesture branch. I've also tried the wip/gesture branches of eog and evince - they work quite nicely. Thanks for the comments! I should add that evince is particularly a good test bed, it demonstrates better than eog how gesture management works across a widget hierarchy. A bunch of replies below. The class hierarchy I see: GtkEventController (abstract) GtkGesture (abstract) GtkGestureSingle (abstract) GtkGestureDrag GtkGestureLongPress GtkGestureMultiPress GtkGestureSwipe GtkGestureRotate GtkGestureZoom What other uses are there for GtkEventController, if the widget api is now using GtkGesture ? Is it worth keeping this base class around ? That's a good point, I guess depends a bit on the future direction. I thought GtkEventController might be also useful for keyboard controllers, keybindings could fit as controllers hooked to the capture phase, Other (likely out of GTK+ scope) cases I could think of are key combo handlers, or something to abstract the handling of directional keys, eating key repeat events, allowing several keys to be simultaneously pressed, etc. But the GtkWidget-level helpers in the branch are all around GdkEventSequence (hence GtkGesture), it was a bit inconsistent to have those added as GtkEventController, so I figured other possible uses might need other hooks into GTK+. Something that comes across my mind lately is that GtkEventController might hook underneath to the widget (it's a required construct-time argument anyway), that'd help get rid of this oddity, although maybe not of the why GtkEventController? question :). It would be good to write a high-level explanation of how events are handled now, highlighting the changes. one way to do it would be to update the comment above gtk_main_do_event - it needs updates anyway. Yes indeed, and probably a big chunk with diagrams in GtkGesture, documentation in the branch is admittedly half-way... Doesn't it do violence to grab semantics if the capture phase runs all the way from the top ? No for all traditional event handling (ie. bubbling), captured events have been kept in private domains so far, that played in my favor here a bit... But this is most nominally to counteract the perform GTK+ grab while button is pressed trend in widgets, that largely defeats gesture recognition on parents if none of those captured the button/touch press. OTOH it probably makes sense to mass remove those superfluous GTK+ grabs, and document it as a possible pitfall regarding gesture recognition. The case for ENTER/LEAVE looks at the sensitivity of the grab_widget before propagating the event - I think the logic there needs to be changed to always propagate, regardless of the grab_widget sensitivity. Hmm, you mean only on the capture phase, right? Looks like the gtk_widget_event() bubble call should still check for sensitivity. The long press gesture is always using the default delay - that should probably be a property ? Oh indeed, I pushed some patches to have it rely on a GtkSettings property. The swipe gesture is a subclass of GtkGestureSingle - aren't there two-finger swipes, or is that not a useful distinction ? That's one thing I considered when making all those gestures derive from GtkGestureSingle, in greater or lesser degree, in the end having mouse-friendly API in a common place for those won... In theory those can be made multi-touch, even though they are optimized for single touch. That is, you could have two finger swipes, but speed calculation is only done on one of both sequences (or the bounding box?), this at least makes sense for swipe/drag. one thing for sure, multi-touch GtkGesture[Multi|Long]Press and accuracy are not going to get along... GtkPressAndHold should probably be replaced by GtkGestureLongPress. Oops yes, that's missing :) Comparing to ClutterAction, I see ClutterPanAction and ClutterTapAction that have no equivalent yet. Right, would be good to have those for completeness. It seems slightly complicated that gtk_widget_add_gesture() takes a GtkPropagationPhase as argument. clutter_actor_add_action doesn't have that. Yeah... maybe if I get rid of gtk_widget_add_gesture() as proposed above, this could be moved to a less often called gtk_event_controller_set_propagation_phase(), a bubble default could make sense, at least for non-containers. But due to the way event propagation is prone to be stopped deep in the stack in the bubble phase, the capture phase is very likely what containers want. Maybe if events propagated unstoppable in the bubble phase we could get rid of the capture phase, but that'd require deepest widgets to hold off interaction until they're guaranteed to be the only handlers. This might compare in the X model to the presence/lack of XI_TouchOwnership
Re: Scrolling: be able to disable the zoom mode
On Sun, Mar 23, 2014 at 02:06:32PM +0100, Sébastien Wilmet wrote: I've filed a bug about the scrolling zoom mode: https://bugzilla.gnome.org/show_bug.cgi?id=722438 More information about the scrolling zoom mode: http://blogs.gnome.org/mclasen/2013/08/05/scrolling-in-gtk/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
