| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is actually an opaque type, and there is no definition of struct
CajaIconData anywhere. This actually doesn't change anything as the
non-existent struct is equivalent to any other incomplete type, and
works fine so long as the pointers are not dereferenced using that
incomplete type.
However, change this to an explicit `void` to make it clear it's an
opaque pointer and stop people from looking for a struct CajaIconData
that is nowhere to be found.
|
|
Found by cppcheck: https://caja.mate-desktop.dev/2022-11-23-174623-5790-cppcheck@ae663c369cf2_desktop-no-overflow/18.html#line-630
|
|
Based on a cppcheck report: https://caja.mate-desktop.dev/2022-11-23-174623-5790-cppcheck@ae663c369cf2_desktop-no-overflow/
|
|
`name_row` is not needed since GTK2 support was dropped with commit
276eb145ce96d5f75f8d3901daf6310f60ddbb81.
Found by cppcheck: https://caja.mate-desktop.dev/2022-11-23-174623-5790-cppcheck@ae663c369cf2_desktop-no-overflow/73.html#line-101
|
|
This PR enables the displaying of Caja (as a file manager) for use in Budgie Desktop and XFCE. Prior to this commit, it would only be able accessible in MATE or with downstreams like Fedora patching in the support. The addition of these is important as file managers such as Nautilus adopt libadwaita and begin to directly come into conflict with user theming choices.
|
|
When zoom changes on a manual layout icon view, the available area
changes and can lead to some icons to either overflow or be able to go
back to their actually saved position.
This is done correctly when the view is reloaded entirely, but not
in response to zoom change, leading to disappearing icons (when zoom
increases) or unexpected empty space (when zoom decreases).
Fix this by re-computing actual positions based on saved positions when
zoom changes, to match what would actually happen when the view gets
loaded.
|
|
|
|
|
|
|
|
|
|
See https://gitlab.gnome.org/GNOME/nautilus/-/commit/7aef6be
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This patch resolves three related issues:
The first issue was that the GSettings schema for Caja did not include an
entry to sort by the "btime", or creation date, of files. If the user chose
such an option in the Caja Preferences, GSettings would produce a warning
(often out-of-sight, as it was usually redirected into the user's
.xsession-errors file), and Caja would not actually change the default
sort-order of files. This patch adds the btime as a valid setting in the
schema.
The second issue was that. because of the above (an entry in the settings
schema was missing), some of the alternative sort orders listed in the schema
(everything after and including "atime") were not assigned the same numbers
as the sort orders listed elsewhere in the Caja source code. Specifically,
in icon- and compact-views, if the default sort-order was "emblems", the
observed / actual sort-order would be the entry before "emblems", namely
"atime" -- so instead of sorting by the names of associated emblems, Caja
would sort by each file's access time. An array in the code for the
list-view also was missing many values and included some values out of order,
so the default sort-order setting affected directories viewed in list-view
mode seemingly randomly. The former is taken care of using the fix described
in the above paragraph; the latter is fixed in this patch by adding /
reorganizing the array for the list-view sort-orders appropriately.
The third issue (admittedly, a lesser issue) was that the documentation for
the default-sort-order setting was lacking -- it at least did not list all
the possible values that the setting could accept. In this patch, I resolve
this issue by listing all values in the setting's description, and also go
into more detail about what each value does. (However, perhaps I included
a little too much detail. It'll only benefit [supposed power users who may
already know this stuff] who use GSettings or DConf directly, and it'll
certainly be a headache for translators. I'll admit that.)
|
|
Instead of manually keeping tabs on the signals so we can disconnect
them before the data parameter gets destroyed, let GObject
automatically track lifetime of the data, which it can do as that data
is a GObject itself.
This does not change behavior in the normal case, but makes sure the
callback simply cannot get called with invalid/freed parameters, even
if we did screw anything up (which we used to).
This actually would have solved #1630 as well with using the target
widgets as data parameters as the signal would have been disconnected
as soon as the widget got destroyed, no matter whether we got finalized
ourselves or not.
The signal IDs were also use as guards to whether the monitor was set
up for the related files, but we can just as well use the state of the
file list ready handle which should only be NULL when we actually have
monitors set up. Even if it wasn't the case, worse case scenario would
be removing a non-existent monitor, which is perfectly OK anyway.
|
|
Fixes #1630.
|
|
|
|
|
|
This value is used to look up icons in the cache, but somehow was not
properly initialized.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
it was not handled correctly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* caja-places-sidebar: fix right-click menu height
- prevent error and right-click menu from appearing when clicking empty area
|
|
|
|
in /usr/share/applications
and asks user for confirmation on launch of desktop-files here
|
|
|
