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.
Setter functions the way I code it look like this (in order):
1) Figure out if the value changed. If not, exit early.
2) Clear the old value (ie unref stuff, disconnect signals
3) Copy the new value
4) Set up things about the new value
This reorganization does that.
And by doing that, it even reduces the amount of code and the amount of
branches (and with it, nesting) needed.
Instead, fall through to the default handler after closing the
completion. This has the advantage of letting the file chooser entry
capture the tab key properly, so one can't accidentally move out of the
entry by pressing tab while the completion is popped up.
I also suspect it fixes bugs with weird tab keys and shift/ctrl
oddities. But who knows...
1) always emit signals
Previously, newly constructed cells would be told to not emit events.
However, we can ensure that nothing is connected to the signals, so
they will not actually emit anything.
2) don't return anything
The return value is unused anyway.
No more signal handler is needed, therefore the code can also get rid of
tracking the treemodel. And we use a faster approach for iterating the
changed cellrenderers: We just iterate all columns instead of over all
cell accessibles, as that number is likely quite a bit smaller.
Multiple changes:
- actions are now available unconditionally, but only work in the right
state. This mirrors other actions.
- instead of adding actions manually, they invoke the action on the
GtkCellAccessibleParent interface.
Tests have been updated to reflect the changes
Treat the empty string as if it was a NULL icon name instead of
rendering GTK_STOCK_MISSING_IMAGE.
This used to be the previous behavior of GtkCellRendererPixbuf and
applications might still rely on it.
We need to save the icon size locally for GtkCellRendererPixbuf, since
its properties are set again every time it's drawn (resetting the icon
size on the helper by means of _gtk_icon_helper_clear() each time).
The code is very similar; having two slightly different code paths is
bad and can lead to bugs. Refactor the code to use the same height
request function.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
Add a new window property which requests from the window manager
to hide titlebars when windows are maximized to account for this.
https://bugzilla.gnome.org/show_bug.cgi?id=665616
If the scale has an origin (it will have one by default), GtkRange will
render the two sides before/after the current value with different style
classes, making it possible for themes to use different colors and
properties for the two areas.
This was possible in GTK 2 with style details, but got lost during the
road to 3.0.
https://bugzilla.gnome.org/show_bug.cgi?id=665140
In many cases we used to set focus_child to NULL all the way up
to the top and then to the right value, even if there was
a common ancestor, meaning these see a temporary NULL value for
focus_child. Only when the new focus widgets direct parent was
in the previous ancestor list did we stop early.
This fixes that by always stopping propagation when reaching
the common ancestor.
The casting used to calculate the child allocation is confusing MAX().
As a result, width and height end up with negative values, which makes no sense.
https://bugzilla.gnome.org/show_bug.cgi?id=666109
There was a corner case where the changed signal was not emitted.
If rows were built like this:
1 (not selected)
+ 2 (selected)
+ 3 (not selected)
And row 1 was removed, no signal would be emitted.
I like it when writing tests actually finds bugs that have been around
since 2003 - introduced by 4a03ea2334
actually. :)
We get certain cases, in particular with SELECTION_MULTIPLE, where we
cannot figure out in advance of real_set_cursor() if the selection will
actually change.
Previously, the cursor would just become invalid, which used to
reselect the first row in the treeview later on (without a
cursor-changed signal). This leads to a crash now with the recent
refactorings.
The patch is longer than I'd like it to be, but the situation is kinda
complicated, because we want to make sure to move the cursor to a good
row. It works like this:
1) From the deleted row, search forward for the first row that is not
going to be deleted and is not a separator.
2) If no such row exists, search backwards for a row that is not a
separator.
3) If no such node exists, clear the cursor.
Previously the code used a GtkTreeRowReference, which was (a) less
performant and more importantly (b) hiding errors.
The errors being hidden were the referenced row becoming invalid or
collapsed, because such rows would not be valid cursor rows and it would
be necesary to select a new row and emit a "cursor-changed" signal.
So if a crash bisects down to this commit, it is very likely that the
cursor has not correctly been updated and the cursor row is invalid.
Calling gdk_keymap_add_virtual_modifiers causes _all_ virtual
modifiers to be added, which causes problem when they are co-located
on the same real modifier (as Super and Hyper often are). Effectively,
this made it impossible to enter key combinations involving Super,
since they all turn into Super+Hyper.
Move code for child allocation into the child allocation function. Don't
keep it in the overlay allocation code.
See the next commit for why this is useful.
We used to only set the override color or font if it was different
than the existing value. However, that means you can't change it to
an override that is the same as the default value for the property.
With this fixed you can e.g. override with a color of 0,0,0,0 which
you couldn't before.
When gtk_render_arrow() is called, always add an ARROW style class to
the GtkStyleContext before rendering, so themes can specify a different
color for it.
https://bugzilla.gnome.org/show_bug.cgi?id=665420
Just always render the pixbuf ourselves and set it on the GtkImage in
the X11 case.
Code for other backends was already rendering the pixbuf manually before
translating it into a native type, so this greatly simplifies the code.
https://bugzilla.gnome.org/show_bug.cgi?id=665409
Instead of painting the window background on the grip_window we now
only paint it on the GtkWindow->window, and we make the grip_window
have a transparent background.
We can't really make transparent window handle background optional
via css atm, because the handle color is actually based on the
background color, so if that is set to transparent we won't draw
anything.
If no icon size is provided (e.g. when setting icon-name or stock-id
using the GObject property directly), use the default icon size. This
matches the previous GtkImage behavior.
The new function provides an API that takes the PangoLayout and index
as input params, this way it handles strong and weak cursors internally
factoring out all code duplicated in the widgets that need to render
cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
Explicitely check the split-cursor setting when drawing the textview
insertion cursor instead of relying on the cursor_direction set in the
textlayout. This makes the cursor drawin code more uniform with other
widgets in preparation to refactoring the cursor drawing code in a
shared function.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
Move the handling of primary/secondary cursors to gtktextdisplay, which
makes code simpler and more consistent to how GtkLabel and GtkEntry
draw cursors, which is useful in preparation to further refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=640317
