| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Add and remove items and actions - we don't update
the menus properly yet.
|
| | |
|
| |
|
|
| |
This is some test code for constructing GtkMenus from GMenus.
|
| | |
|
| |
|
|
|
|
|
| |
We want to emit signals when stuff happens, not sometime later. That way
we can also catch the correct text that was deleted.
https://bugzilla.gnome.org/show_bug.cgi?id=659445
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
|
| |
|
|
|
|
|
| |
This code was essentially copy-pasted in two locations, so unify them in
the same place.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
That was an abomination. Also, if people called it twice, you got even
mor signal handlers!
|
| |
|
|
| |
No need to add t manually later.
|
| |
|
|
| |
It's not used now that set_widget() does the right thing.
|
| | |
|
| |
|
|
| |
GtkAccessible does all of that for us now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
When the accessible was disposed before the notebook it referenced, the
weak ref could still trigger. This works around it.
|
| | |
|
| | |
|
| |
|
|
| |
A GtkAccessible with a NULL widget is defunct, there's no way around it.
|
| | |
|
| |
|
|
| |
We don't want to bypass the unset_widget call.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I expect them to be used a lot, so this approach seems better than
requiring signals that connect to "notify::widget". Also, we can't use
regular functions (like dispose or constructed), becaiuse those assume
that (un)setting of the widget only happens once and with the current
design (a puble set_widget() function) we can't really guarantee that.
Also, I split them into two separate functions as one function is part
of construction and the other part of destruction of the object. And it
doesn't sound like a good idea to have that both be part of one
function.
|
| |
|
|
|
|
| |
I wanted to use weak refs to ensure this instead, but it's a performance
problem when used in the treeview and each and every cell adds a weak
ref to the treeview.
|
| | |
|
| | |
|
| |
|
|
|
| |
Single point of entry. It's actually going to become more complicated
with a11y now.
|
| |
|
|
|
| |
Use peek_cell() instead of a custom find_cell() function that duplicates
loads of functionality.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This uses the new workarea API to avoid placing popups underneath
panels, docks, etc.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
|
| | |
|
| |
|
|
|
|
|
| |
Dealing with disabled devices may turn into hierarchy/device
changed events on device IDs with no backing GdkDevice yet,
so protect against that. The device attachment will be handled
correctly when the device is enabled later.
|
| |
|
|
| |
Use g_clear_object, move unrefs to dispose and reorganize code
|
| |
|
|
|
| |
We already have a gtk_text_layout_get_iter_at_line wrapper that takes
care of getting the btree from the layout, we may as well use it.
|
| |
|
|
|
| |
No need to call _gtk_text_btree_get_iter_at_line right before calling
totally_invisible_line, since it is the first thing it does itself.
|
| | |
|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=666392
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Even if we can't change our sensitivity because the parent is insensitive we
should still flip the sensitive flag. Otherwise, with and insensitive parent,
child.set_sensitive(True)
...
parent.set_sensitive(True)
would result in child still being insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=666392
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of in the key_press handler, use a signal handler. The signal
handler runs before the default handler, and before other signal
handlers. In particular it runs before the signal handler installed via
gtk_entry_set_completion() which pops down the entry completion, and we
don't want that to happen.
The code does not change the code of the handler in any significant way,
it just refacotrs it to not call the parent anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
|
| |
|
|
|
|
|
| |
When saving files, using <tab> is required. We don't want the UI
randomly changing filenames from below us.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
|
| | |
|
| |
|
|
|
|
|
|
| |
This was removed previously, but is necessary to support the case where
no base folder is in use, which should cause an error. This can be
experienced in save mode in the recent files list.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
|
| |
|
|
|
| |
We don't want to complete on files when they're not supposed to be
selectable.
|
| |
|
|
|
| |
There's only 2 places left where we potentially beep. We can call
gtk_widget_error_bell() directly there.
|
