| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Related: exo#82, libxfce4util!24
|
|
|
|
|
|
|
|
|
|
| |
Only like that 'gtk_accel_groups_activate' will correctly return TRUE if the related accelerator was activated.
Most likely this patch only is required because of a glib bug: https://gitlab.gnome.org/GNOME/glib/-/issues/753
See as well: apps/xfce4-terminal!33
MR: !179
|
|
|
|
|
| |
Triggers `-Wincompatible-pointer-types`, see documentation of
`g_once_init_leave()`.
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes duplicated files in `recent:///`
Support sorting by `Recency`
Add the recent location to the sidepane and go menu
Automatically add opened files to `recent:///`
Add a `Remove from recent` option for files in `recent:///`
Issue #257
MR !115
|
|
|
|
|
| |
MR !114
Issue #418
|
| |
|
| |
|
|
|
|
| |
Implements the saving of sort-column and sort-order for each directory.
|
|
|
|
|
|
| |
Allows the view type (details, icon, compact) to be saved individually for each directory.
This requires some significant changes to the way thunar-window handles changing directories
and creating new views.
|
|
|
|
|
| |
- exo-csource is deprecated and moved to xdt-csource
- Bump minimal xdt version
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Bug #14685)
g_icon_to_string() is not meant to return an icon name, it returns a
"textual representation of the icon", which is mostly "proprietary to
GIcon" (in GIO documentation's own words).
In particular the reverse function to get a GIcon back from this
representation is g_icon_new_for_string().
The reason why it used to work was because of a special casing (which
happens to be the most common case: when you create an icon with a
single name); yet even if the most common, relying on special cases is a
bad idea. The special case is about to be reinstated in GLib so it will
work again as expected, yet only until the next time a widget uses a not
special-cased GIcon, for instance if using fallback icons. It is better
to really fix the code.
Now the menu properly recreates the icon using g_icon_new_for_string(),
not assuming what type of icons it was (it could be an icon name, a
path, a list of icon names, or whatever else proprietary representation
any type of icon may use now or in the future).
Also update the doc of thunarx_menu_item_new() to explicitly states that
the icon parameter is a textual representation as returned by
g_icon_to_string(). In particular this won't break any plug-ins as
single icon names and icon paths are proper representations for icons
too.
|
| |
|
| |
|
| |
|
|
|
| |
"make dist" (Bug #14070)
|
| |
|
| |
|
| |
|
|
|
|
| |
Also refactoring some menu related code into thunar-menu-util.c
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Instead use the new ThunarxMenuItem class and keep all
the deprecated stuff internally, away from the extensions
API.
|
|
|
|
|
| |
- Taken from old sgml template
- Less compilation warnings now
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Optional plugins are not ported yet. We use a shitload of
deprecated Gtk APIs now. Not all features work.
It doesn't look great yet. There are bugs.
But, well, it's a first step.
|
|
|
|
| |
This is a prerequisite for Gtk3 which removes all the fields.
|
|
|
|
| |
Remove them or replace them with vim modelines where appropriate.
|
|
|
|
| |
Also remove another occurrence of SVN $Id$.
|
| |
|
|
|
|
|
|
| |
Some files that were not readable locked the interface
(/proc/kmsg as root for example). So only do fast-type-checking
(no reading).
|
|
|
|
|
| |
This saves a lot of search and reading file content when
loading large folder. Still in experimental stage.
|
| |
|
| |
|
|
|
|
| |
Could technically overflow.
|
|
|
|
|
| |
There were 2 versions used. Use the one in thunarx
and use marcos for deep appending/prepending.
|
|
|
|
|
|
| |
When compiler with low lever debugging, these warnings
can result in an abort. Use g_printerr to avoid this,
warnings are harmless anyway.
|
|
|
|
|
|
|
|
| |
This saves a lot of md5 hash creations, also make
the code a bit more efficient.
Drop thumbnail::* namespace collection, since we don't
use that.
|
|
|
|
|
| |
We already require GVFS for a trash implementation, so
why ot rely on the metadata storage too.
|
| |
|
| |
|
| |
|
| |
|
| |
|