GTK3 breaking key grab rules?
Hi list, I am the developer of an application named AutoKey. One of the features of AutoKey is allowing the user to create hotkeys. The hotkeys are grabbed using the xlib window.grab_key() function. In all other desktop environments to date, grabbing a hotkey in the root window using this method causes that hotkey to no longer be received by any other application, which is exactly what I want. However, in Gnome Shell, with GTK3 applications, for some reason this breaks down. Hotkeys grabbed in the root window are still received by other GTK3 applications, unless I specifically grab the hotkey in every window in the tree. KDE applications running under Gnome Shell are not affected by this issue. I have tried implementing various nasty workarounds but they are slow and unreliable. Ideally I'd like to understand what GTK3 is doing that is causing this behaviour and see if there is another way around it. Thanks, Chris Dekter ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to use hbox?
Hi Gary, 2011/12/11 Gary Kline kl...@thought.org: well, i've reached a stumbling block. the app i am working on had things is a vertical stack. so far, there about 6 rectangles. the first shows the default title and the count: Something like talk.0.txt Here's a tiny demo program I think I made for someone a while ago. I doesn't do what you want, but it does have an hbox with two buttons in. Look down for create_window1(). John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to use hbox?
There is a very handy program called gtk-demo which contains many demo programs complete with source code. gtk3-demo is for GTK3. They're in the gtk2.0-examples and gtk-3-examples packages on Ubuntu. Check, for instance, Dialog and Message Boxes in the do_dialog() function. You can double-click the name of the demo in the left list to run it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Child widgets of GtkBox not resized until clicked
Hi,
I have this weird problem with layouts in Gtk and I hope you could push me in
the right direction:
I have GtkScrolledWindow with vertically-oriented GtkBox inside. Within this
box there are multiple GtkScrolledWindows.
For each of these embedded scrolled windows I have handler of vadjustment's
changed signal:
static void
inner_window_vadjustment_changed (GtkAdjustment* adjustment,
gpointer user_data)
{
GtkWidget *widget = user_data; /* the scrolled window */
gint height = gtk_adjustment_get_upper (adjustment);
gtk_widget_set_size_request (widget, -1, height);
gtk_widget_queue_resize (widget);
}
This actually expands the scrolled window to height of it's content, thus
hides the scrollbars (it's a workaround, GTK_POLICY_NEVER does not work, see
below).
This works pretty well, the correct values are assigned
(gtk_widget_get_size_request returns the new height), but the scrolled windows
are in fact not resized. When I click in the window the new height is applied
immediately and the scrolled window is resized correctly (but only the one I
clicked into, not the other ones). What can I do to make the scrolled windows
resize as soon as they receive gtk_widget_set_size_request()?
Thanks for any suggestions
Dan
PS: you may wonder why on Earth am I doing this such stupid way, so here's
some explanation: each GtkScrolledWindow contains a single WebKitWebView. I
can't embed the webviews directly to the GtkBox, because such webviews cannot
be resized (you can't shrink WebKitWebView which is not inside a scrolled
window). Other option would be to set GTK_POLICY_NEVER to disable vertical
scrolling, but webkit treats this policy as GTK_POLICY_AUTOMATIC [1]. I want
the master scrolled window to handle the scrolling of the entire layout, not
each of the embedded scrolled windows to have scroll bars on their own, so
that's why I'm using such workaround.
[1] http://webkitgtk.org/reference/WebKitWebFrame.html#WebKitWebFrame-
scrollbars-policy-changed
--
dvra...@redhat.com | Evolution developer
GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.31.4
GLib 2.31.4 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
627fbffdb0c0a95709778e54ab32620d3e4ae9dfed939bb69ab4a50209ff43fb
glib-2.31.4.tar.xz
Overview of changes from GLib 2.31.2 to 2.31.4
==
* EXPERIMENTAL: Menu support has been added to GApplication. Menus
are exported on the bus, alongside the actions that are already there.
There have also been many related improvements to action group
functionality.
These new APIs are subject to changes in the coming releases. In
particular, it seems somewhat likely that the APIs for registering
menubars may change in order to accommodate windows with different
types of menubars.
* GDBusConnection previously directly dispatched destroy notifies when
unregistering objects if the current main context was the same context
the object was exported on. It now unconditionally dispatches these
through an idle on the context.
* Clean up Requires in pc files. Linking against GIO no
longer drags in gmodule. This may require dependency
fixes here and there.
* Introduce GBytes, a data type for immutable, fixed-size
byte sequences. This makes the pre-existing GBuffer
API available outside GLib
* GDBusInterfaceSkeleton can now be exported on multiple
connections
* Bugs fixed:
600161 Do not use static GTypeInfo and GInterfaceInfo
640077 GFileMonitor: Always send CHANGES_DONE_HINT after a move...
641720 Misleading definition for local_command_line() in GApplic...
648516 Little comment error and 2 useless lines of code
651997 Dummy backend for gapplication
652560 Test for g_ascii_strtod is failing
662208 failure to initialize a GInitable should be considered...
662718 GDBusInterfaceSkeleton should be able to export on multi...
663291 GBytes: Immutable, refcounted sequence of bytes
664406 Need context for a proper translation
664455 Build fixes for GLib GIT master (2.31.x)
664558 GDBusWorker.frozen has a value 1 in a gboolean
664559 sys/wait.h not available on windows
664617 gdbus segfault error 4 in libgio-2.0.so.0.3102.0
664635 GMemory{Out,In}putStream _async functions break sub-class...
664809 Add command line option to gtester to allow skipping tests
665067 cryptic assertion failure if nonsensical flag combinations...
665184 Check ref. count before reffing/unreffing
665298 Add 'Requires.private: libpcre' to glib-2.0.pc
665391 update documentation around mainloops
665607 ./configure is there for fiddling with cross-compile enviro...
665634 g_dbus_node_info_new_for_xml() errors on unknown attributes...
665685 Add a #define for the max length of a Unicode decomposition
665733 GDBusConnection holds lock while calling destroynotify
* Translation updates:
Hebrew
Korean
Norwegian bokmål
Spanish
Thanks to the contributors to this release:
Aleksander Morgado
Behdad Esfahbod
Benjamin Otte
Carlos Garcia Campos
Colin Walters
Cosimo Alfarano
Daniel Mustieles
Dan Winship
David Zeuthen
Kjartan Maraas
Matthias Clasen
Michael Vogt
Nicola Fontana
Philip Withnall
Piotr Drąg
Rico Tzschichholz
Sam Thursfield
Seong-ho, Cho
Simon McVittie
Stef Walter
Thomas Hindoe Paaboel Andersen
Tristan Van Berkom
Yaron Shahrabani
Cheers
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GMenuModel has landed
On Fri, 2011-12-09 at 08:47 -0500, Ryan Lortie wrote: On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote: Windows actually has an application menu thing. If you right-click on the application on the panel you can get app-specific operations in the menu. I'm not sure if the normal usecase for these match what the app menu is typically used for though. Is this the so-called jumplist? It sounds more likely that we'd treat this as a 3rd type of menu -- since the shell, unity and mac os all have this same concept these days as well... Yeah, this is one instance of the jumplist. The other one being on the app icon in the start menu. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On 12/12/2011 03:24 AM, Matthew Brush wrote: On 12/11/2011 12:14 PM, Stefan Sauer wrote: On 12/09/2011 01:00 AM, Ryan Lortie wrote: hi, Today I landed the GMenuModel work on glib master. A release will be following shortly. Just one quick question - why is this in GLib? Is that to allow command-line apps to have a menu? I tried to ask this here a day or two ago but had problems, so I asked Ryan on IRC. The answer is that it's in GIO rather than GLib and there is precedence; GIcon for example. My (probably misguided) opinion is that if this type of stuff can't go into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome` library or something like this. I have doubts how many apps linking to GIO without GTK+ are going to need such a model, either because they don't have a UI at all or are using some other toolkit which likely provides a mechanism of its own for this. I think this is not so easy. Having a glib-app library sounds goo, but I believe we don't want to have too many mini libraries. On the other hand I wouldn't look for it in gio either. Stefan Cheers, Matthew Brush - Just some guy ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On Mon, 2011-12-12 at 10:18 +0100, Stefan Sauer wrote: On 12/12/2011 03:24 AM, Matthew Brush wrote: On 12/11/2011 12:14 PM, Stefan Sauer wrote: On 12/09/2011 01:00 AM, Ryan Lortie wrote: hi, Today I landed the GMenuModel work on glib master. A release will be following shortly. Just one quick question - why is this in GLib? Is that to allow command-line apps to have a menu? I tried to ask this here a day or two ago but had problems, so I asked Ryan on IRC. The answer is that it's in GIO rather than GLib and there is precedence; GIcon for example. My (probably misguided) opinion is that if this type of stuff can't go into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome` library or something like this. I have doubts how many apps linking to GIO without GTK+ are going to need such a model, either because they don't have a UI at all or are using some other toolkit which likely provides a mechanism of its own for this. I think this is not so easy. Having a glib-app library sounds goo, but I believe we don't want to have too many mini libraries. On the other hand I wouldn't look for it in gio either. I know not everyone is so crazy about the idea, but perhaps this will be a good starting point for implementing a decent desktop IPC environment. For an example that I'm familiar with, currently Glade has to invoke DevHelp and detect DevHelp existence entirely through the command line. Ideally Glade, IMO should simply be activating the 'search' action on the DevHelp entitiy. From my very limited understanding of GMenuModel, essentially this is only a wrapper around GActions and action groups, implements a hierarchy of actions and such with some probable merging/pathing sugar apis, those actions will be accessible by other programs on the Bus. Some of those programs *might* happen to be a desktop environment that wants to display menus from these hierarchical actions which have been assigned a special token such as I am the App menu, other applications might very well not have anything to do with displaying menus at all... perhaps a11y technologies could be transparently integrated into a system that exports good introspection via the GMenuModel, perhaps one could use GMenuModel to extend their application with a sister application which syncs the application state with some database or webserver interface... simply by adding the extra program, starting it and giving it access to the bus. Point being that just because having a hierarchical structure of actions exported on the bus might be useful for a desktop menuing system, does not mean that it's not a useful concept when applied in different ways... it might rather be called 'GActionModel' and then just by it's name have much more relevance in libgio... Just 2 extra cents... Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On 12/12/2011 03:24 AM, Matthew Brush wrote: On 12/11/2011 12:14 PM, Stefan Sauer wrote: On 12/09/2011 01:00 AM, Ryan Lortie wrote: hi, Today I landed the GMenuModel work on glib master. A release will be following shortly. Just one quick question - why is this in GLib? Is that to allow command-line apps to have a menu? I tried to ask this here a day or two ago but had problems, so I asked Ryan on IRC. The answer is that it's in GIO rather than GLib and there is precedence; GIcon for example. In Ubuntu, at least, we have quite a few daemons that export menu-like constructs which is then rendered in another process (the shell). Think distributed model-view-controller where the models are these daemons. These daemons have no reason to link to libgtk* (and does not need an X connection etc). (and these daemons happen to use loads of GIcons as well - I love how glib/gio separates abstract entities from the actual toolkit) Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On 12/12/2011 10:45 AM, Ryan Lortie wrote: On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote: My (probably misguided) opinion is that if this type of stuff can't go into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome` library or something like this. I have doubts how many apps linking to GIO without GTK+ are going to need such a model, either because they don't have a UI at all or are using some other toolkit which likely provides a mechanism of its own for this. We had this conversation in context of GSettings, a few years ago. It wasn't really IO, so why should it go in GIO? We threw around the idea of libgplatform or libdesktop and so on and decided that we should just treat libgio as this. That's when we started (only half-jokingly) insisting that GIO stands for GLib Interfaces and Objects. I think a separate G library would be an *excellent* idea, much more sensible and practical from a consumer (app developer) POV. A quick scan through the API docs, I'd nominate the following to be moved to a separate library: - Icons - Settings - Application support - (the menu stuff) Everything else in there seems to be, even if not purely IO, at least used by or in conjunction with the other stuff that is (I think). I have a long-held belief that the model side of things that are not directly related to widgets should be kept outside of the toolkit. I'd support, for example, a GtkTreeModel replacement to be merged into libgio. Yep, I certainly don't disagree with this either, just that it's strange to put this type of stuff in the IO library (IMO). It feels like there's some stuff in the G stack that's looking for a home and everything just winds up in GIO, like it's a dumping ground for miscellaneous stuff (which I guess it is as you said, presently). I just fear people will start calling GIO bloated and GNOME-bound and might cause people who would've otherwise used this excellent IO library to either re-write their own or look elsewhere. Just my $0.02 as a Joe Random Hacker :) Cheers, Matthew Brush ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
