| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
If informal date format is used, for future dates the today time format
has been used by mistake, instead of the general time format.
|
|
If informal date format is used, the yesterday/today ranges of 48/24
hours apply to the end of the current day, not to the current instant.
Fixes a regression introduced by 476f56a25be636970b336d525a7766b6d1eb3fff.
Fixes #1621.
|
|
based on https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/821/diffs
|
|
`p` actually could never be `0` (because of the NULL check on the
`memchr()` call), but the intended behavior is `*p == '\0'`: the
containing condition checks for either a truncated data (`*p == '\0'`)
or no geometry information (`*p == '\n'`).
I replaced the check to be `*p != '\n'` instead of `*p == '\0'` to
make this more robust as the actual issue is anything but a newline,
the fact it can only be a NUL otherwise is incidental to the enclosing
check, but not really relevant at this level. This is also in line
with the actual error message.
Found by cppcheck: https://caja.mate-desktop.dev/2022-11-23-174623-5790-cppcheck@ae663c369cf2_desktop-no-overflow/16.html#line-204
|
|
Properly update the icon data before placing the icon, because
positioning might depend on full icon contents on the desktop, whereas
updating contents don't care about position.
When an icon position overflows the desktop area, it is clamped to stay
in the visible area, but this computation depends on accurate icon and
label sizes, which is only available when the icon is fully loaded.
Fix the code to first load the contents and then position instead of
the other way around, which was actually trivial.
Note that visible positions were most often correct anyway for two
reasons:
1. Most of the time icons do not overflow, as they are positioned on
the final desktop size anyway. It however can easily happen
reducing monitor resolution or increasing desktop view zoom.
2. A second layout pass happens most of the time (I'm not yet sure why
and when though), but not when an update is triggered before the
previous one terminated (e.g. quickly hitting F5 twice).
|
|
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/
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in /usr/share/applications
and asks user for confirmation on launch of desktop-files here
|
|
|
|
When creating a new file (using a template, for instance), file->
details->is_added could potentially be FALSE, and cause this file to
not be finalized along with other files if the view directory is
destroyed.
This can cause issues when re-entering that directory, with the file
being in an undefined state, and could prevent the view from fully
loading the location (this is identical behavior to that described
in https://github.com/mate-desktop/python-caja/pull/64.
To reproduce:
- Create an svg file and save in ~/Templates.
- Right-click, Create document-> svg file, name it whatever.
- Navigate out of the folder.
- Modify the file in a visible manner.
- Re-enter the folder, note that it never finishes loading.
Ref:
https://github.com/linuxmint/nemo/issues/2736
|
|
|
|
This is mostly useful on the desktop (which is the main user of the
free-placement icon view) to be able to lock the layout and avoid
unintentionally moving icons around. Especially useful for less
computer-literate users.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gio set PATH "metadata::caja-trusted-launcher" true
|
|
|
|
|
|
|
|
|
