I have a problem with above mentioned widget on touchscreen (Elo). List of options is visible only while widget is pressed. This is different behavior to that one with mouse as pointer. After mouse left click list of options appears and waits for user choice.
I`m using Perl 5.22, and GTK3 (3.18.2) and Perl Gtk3 wrapper library (0.025).
I think this is likely due to this bug (which has not yet been fixed) in GTK3:
https://bugzilla.gnome.org/show_bug.cgi?id=333470
It seems that if you move the mouse pointer at all after pressing on the combo box (which is likely to happen on a touchscreen) it will be interpreted as a selection, instead of keeping the options open for selection.
Related
I'm using GTK on Linux. (Both GTK2 and GTK3 exhibit this behavior.)
When you grab the window on some free space or menubar, the window itself gets dragged.
I'm using the window as a giant OpenGL canvas, and this prevents the primary mouse button presses from ever reaching the window. Double-clicks and secondary button presses arrive just fine.
How do I disable or work around this behavior? I've also tried adding a GtkDrawingArea to the window, but it still gets dragged.
This is not possible. GTK overrides the function of primary mouse button unconditionally. However, simply adding an empty GtkLabel to the window worked just well for me.
Edit: eventually I just used a GtkDrawingArea, because I also wanted a scroll/menubar. That works just as well.
Gtk does grab unconditionally, but you have full control of what that specific "click" will do.
Returning True from any "button-xxx" method will stop further processing from Gtk. See "Return type" here.
When clicking C-mouse-1 in emacs you get a pop up buffer menu to select opened buffers from.
I noticed after switching from emacs 23 to 24 that the menu is slow to open "categories".
For example I have :
Fundamentals
Dired by name
C
Others
Moving the mouse to one of these categories wont open the list of buffers inside it without moving the mouse a little more.
Meaning, I would move the mouse lets say on Fundamentals, it gets highlighted but doesn't show the second level popup with the list of buffers, I need to move the mouse some more "while still on Fundamentals" to reveal the list.
This was not the behavior in emacs 23 where the second level list opens instantly once you hover the mouse on the category.
Any reason for that? And a possible fix?
Sounds like the difference between Lucid menus and Gtk menus. IOW it's probably not the change in Emacs version but the fact that your Emacs-23 was built with the Lucid toolkit whereas your Emacs-24 is built with the Gtk toolkit.
In gtk2 (.rc) and GTk3 (.css) how do you theme the default button in a dialog ?
(The one that will be activated when hitting enter)
In Lubuntu 12.10, the default theme (/usr/share/themes/Lubuntu-default) has a file in the gtk-2.0 folder called button.rc. There are five "states" listed: normal, prelight, insensitive, active, and focus. It is my impression (from a bit of fiddling), that the "focus" state represents the one you are interested in. In other words, if a window with a few buttons is present, it is the button in the focus state that will be "pressed" or "clicked" by hitting enter.
In Lubuntu 12.10, the screen that appears when you click "Logout" from the main menu (or run lubuntu-logout from a terminal) illustrates this well. Of the seven "buttons" that appear, the topmost one, Shutdown, is shaded slightly differently (or has a focus ring) whereas the other six are similar to each other except for the text. Hitting "enter" without doing anything else is equivalent to clicking the "Shutdown" button.
I too am trying to figure out how to make the button in focus, if we call it that, a bit more contrasty.
For the gtk2 side of things, if you're happy with making the focus ring more obvious (but a bit more ugly), editing the theme's gtkrc may be one way. Look for a section captioned style "default" and then for a line that has something like
GtkWidget ::focus-line-width = 1
Changing 1 to 2 or 3 will make the focus ring more obvious.
(I haven't got round to looking at gtk3 apps.)
When Gtk GUI is started seems that Gtk sets "optimal" focus order to his controls which can be switched (beside usual way) with arrows. Then we can easily move (modify) focus order with "grab" to whatever enabled widget.
In case of GtkEntry, after pressing enter key "activated" event raises where I do validation and then I would like to jump to next control, like I was pressed "down arrow".
For now I transfer focus with "grab" and explicit name of wanted control but I would like to jump to "next" control of gtk's order without referencing it.
Also I transfer focus manually in keypress event of entry but this is also too fixed and unwanted way.
If I woud be able to set focus to "next control" this can make later modification in GUI much simpler.
Is this possible and how?
Thanks.
The PyGTK FAQ has one way to set tab order and two different ways to traverse it. These are likely the same in whatever language you're using.
I'm trying to get a window to cover the whole screen. Its positioning and dimensions is fine but it gets covered by the Gnome panel. To complicate things I have two monitors and this app needs to support people with multiple screens.
WINDOW_TYPE_HINT_SPLASHSCREEN is a good start. It covers both screens but not the panel. It's still there, just behind the panel.
WINDOW_TYPE_HINT_DOCK looked ideal but I need this window to take focus to listen to a keyboard event. _DOCK seems like it purposely ignores keyboard events (which kind of makes sense). Can I force it to take keyboard focus?
Is there some way I can force a hinted window to cover the panel?
There's window.fullscreen() which you can call on a normal "un-hinted" window. I assume this lets the window manager decide whether the window should cover the panel or not.
If you use the WINDOW_TYPE_HINT_MENU, you can give the focus to the window by calling the gtk_window_present() function.
However, I don't know if you will be able to cover the panel.
Another hint: the panel probably change its _NET_WM_STRUT property so that other windows cannot cover it. Maybe you will have to play with this property (or another) in your window.