We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
Deal with remote action invocations correctly by implementing
GRemoteActionGroup in the same way that GApplication does and pushing
remote activations through the before/after_emit functions of the
GApplication associated with the window.
This is the last part of getting the threading situation right.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
When we have incoming activations or action invocations we should
acquire the GDK lock, just in case the program in question is using gdk
threads.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
When parsing GMenu xml, use the facility for pick up named submenus.
Note that <section id='foo'>...</section> is _not_ a named submenu.
It is a named item with an unnamed submenu :-(
We want accelerators to work, even if the menus are not shown
locally, so we can't rely on the GtkMenu code to set them up
for us. Currently, this code only installs accelerators when the
window is realized.
This allows to specify accelerators in a convenient way, by
adding accel="..." attributes to the menu items in the
XML for the menu.
Currently, the accelerators are extracted only once, when the
menu property is changed on the application.
Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.
Put this in a separate file and substantially refactor it.
Move handling of submenu creation into gtkmodelmenuitem where it
belongs.
Improve our handling of when to show separators or not.
GtkModelMenuItem, being based on GtkCheckMenuItem, was always reserving
space for a check/radio indicator. This ends up looking pretty strange
in a GtkMenuBar.
Don't reserve space for the indicator unless it's appropriate.
This GtkMenuItem subclass (and GActionObserver implementation) contains
all the knowledge necessary for converting a GMenuModel item description
into a GtkMenuItem.
Remove much of the code that used to do this from
gtkapplicationwindow.c.
This feels premature; we do have the fallback situation covered
adaequately with the menubar, and people can do their own creative
solutions with gtk_application_window_get_menu(), so we don't have
to offer a widget for this right now.
This is a GtkWindow subclass that "application windows" will use. Each
is associated with a GtkApplication, has the ability to show menus and
will have its own associated set of actions.
These were destined for GLib, but they don't really make sense as a
public API. Instead, we'll copy/paste them around between the various
codebases that need to render menus.
This is a boolean property that will be set to TRUE if the current
desktop environment is capable of displaying the application menu as
part of the desktop shell.
If it is FALSE then the application will need to display the menu for
itself.
This should be redone to show the label together with the
separator line, somehow. For now, just put the label below
the separator, as a separate item.
This makes GtkBuilder accept a GMenuMarkup tree at the toplevel
(ie with <menu id='foo'> being a child of <interface>) and the resulting
GMenu object can be obtained via gtk_builder_get_object (builder, "foo").
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.
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
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
That way, we can use the regular filtering features of the
filesystemmodel instead of having our own filtering function that
duplicates much of the matching code.
This also removes the broken-on-windows feature where files strting with
a dot were not autocompleted.
Use all the clever functions we invented in recent refactorings to
compute the file and dir part and the current folder.
This also fixes the bug where "./" was not taken as the current
directory but interpreted as a file named "./".
This returns the text that should be completed on. As this is somewhat
tricky to compute (and in fact one place did it wrong), let's make it a
function.
Now that we don't need to know anymore why insertion failed, we can
simplify the append function quite a lot.
A simple rule now: If we did not insert anything, beep.
Too much special code for no gain.
I did a totally unscientific questionnaire on GNOME IRC (assuming
autocompletion is for advanced users) and nobody even knew what this is.
So I suspect it's useless. Also, it's positioned completely wrong anyway
and nobody noticed so far. Last but not least, I'm trying to imitate
bash here and bash doesn't show feedback.
Use dispatch_properties_changed() instead of GtkEditable to watch for
changes to the to-be-completed text. This is necessary because various
functions in GtkEntry don't use the interface vfuncs and one only
becomes aware of them via notifications. I'm not sure this is intended
behavior, but it's how it works today.
Also, use the same code for triggering in all situations.
What the code does is this: It looks at the part of the text in front of
the cursor (or selection) and completes for it. Once the directory has
been enumerated, inline completion is activated. Note that popping up of
the completion popup is completely handled by GtkEntry.
Instead, pass the text to use to refresh_current_folder_and_file_part().
This also gets rid of the problem introduced earlier that the position
is not properly updated in do_insert_text() and therefor the completion
is wrong.
... from GtkEntryCompletion instead of implementing a poor copy
ourselves. This also makes the file chooser entry behave a lot closer to
normal entries.
This is identical to the display name when not having a path that
changes the folder. Otherwise it will have the full path that was
entered in the entry. Say when from your home dir, you type
"../../usr/li", the full path for "lib" and "lib64" will be
"../../usr/lib" and "../../usr/lib64" respectively. This value isn't
used yet, but will be soon.
The new version does not need to muck with the entry, it just extracts
the required information. It returns a reference to the folder though,
as we extract the information now instead of returning something stored.
