thunar merge requestshttps://gitlab.xfce.org/xfce/thunar/-/merge_requests2020-12-20T17:16:14Zhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/1Freeze new copy where source or target device is shared with another running one2020-12-20T17:16:14ZCyrille PontvieuxFreeze new copy where source or target device is shared with another running onepreferences for freeze on same source/target device or notpreferences for freeze on same source/target device or nothttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/2Option to rename a file when existing copy conflicts.2020-05-30T08:42:37ZCyrille PontvieuxOption to rename a file when existing copy conflicts.https://gitlab.xfce.org/xfce/thunar/-/merge_requests/3Job response enum2020-05-02T12:49:47ZCyrille PontvieuxJob response enumTHUNAR_JOB_RESPONSE_REPLACE(_ALL) and THUNAR_JOB_RESPONSE_SKIP(_ALL) added for clarity
ask_create and ask_delete still uses YES(_ALL) and NO(_ALL) responses.THUNAR_JOB_RESPONSE_REPLACE(_ALL) and THUNAR_JOB_RESPONSE_SKIP(_ALL) added for clarity
ask_create and ask_delete still uses YES(_ALL) and NO(_ALL) responses.https://gitlab.xfce.org/xfce/thunar/-/merge_requests/4Add checks for 0 handles (Bug #14122)2020-09-09T07:26:03ZafdwAdd checks for 0 handles (Bug #14122)Bugzilla: https://bugzilla.xfce.org/show_bug.cgi?id=14122.Bugzilla: https://bugzilla.xfce.org/show_bug.cgi?id=14122.https://gitlab.xfce.org/xfce/thunar/-/merge_requests/5Add checks for 0 handles (Bug #14122)2020-05-10T11:12:46ZAlexander SchwinnAdd checks for 0 handles (Bug #14122)(cherry picked from commit 98394ef960884af83b801824757a9a69b9bd8da0)(cherry picked from commit 98394ef960884af83b801824757a9a69b9bd8da0)https://gitlab.xfce.org/xfce/thunar/-/merge_requests/6Added the expansion of "$HOME" in address bar (Bug #12165)2020-05-21T13:51:17ZRobert StefanicAdded the expansion of "$HOME" in address bar (Bug #12165)Using the variable "$HOME" in the address bar will be expanded to the home directory.
https://bugzilla.xfce.org/show_bug.cgi?id=12165Using the variable "$HOME" in the address bar will be expanded to the home directory.
https://bugzilla.xfce.org/show_bug.cgi?id=12165https://gitlab.xfce.org/xfce/thunar/-/merge_requests/7Replace GtkAction, GtkActionEntry and Remove GtkUiManager2020-06-11T11:27:30ZAlexander SchwinnReplace GtkAction, GtkActionEntry and Remove GtkUiManagerClosed in favor of !10
!10 is rebased on master, squash fixes of !7 when possible and fixed comments in order to reference gitlab issues
Closed in favor of !10
!10 is rebased on master, squash fixes of !7 when possible and fixed comments in order to reference gitlab issues
Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/8Use xfce filename input2020-10-17T00:11:45ZReuben GreenUse xfce filename inputA short while ago, a new widget, XfceFilenameInput, was added to libxfce4ui. This widget is designed to be a "smart" replacement for the GtkEnty widget, specifically designed for the entry of filenames. See commit 8f0ad0c23947545abf249aa...A short while ago, a new widget, XfceFilenameInput, was added to libxfce4ui. This widget is designed to be a "smart" replacement for the GtkEnty widget, specifically designed for the entry of filenames. See commit 8f0ad0c23947545abf249aac56124cde74cdeb0a in libxfce4ui for details.
The first commit on this branch removes the whole thunar-create-dialog module from thunar, and replaces it with a single function in the thunar-dialogs module. I don't think that thunar-create-dialog needed to be an independent module, as its public interface really just consisted of a single function (which has been replaced by the new function in thunar-dialogs). The only reason there needed to be multiple functions to implement the create dialog was that a callback was used to check the validity of the entered text, and with XfceFilenameInput this is now redundant.
The second commit replaces the filename input functionality in the create dialog, the rename dialog, and the properties dialog with the new widget. This provides a unified implementation of filename entry rather than three separate ones. I have bumped the required libxfce4ui version to 4.15.1
Key points to note/for review:
1. The only change I have made to the "autotools files" are removing the two lines for thunar-create-dialog.c/.h from Makefile.am. I have however added new #include statements to some files, but it builds ok, so I assume that automake handles all the dependency generation? (my autotools knowledge is exactly zero, sorry)
2. Have I covered all of the places where thunar asks the user for a filename, or have I missed some?
Also, do let me know if I have done anything wrong/bad with the gitlab stuff.
Comments and criticism are very welcome! Thanks!https://gitlab.xfce.org/xfce/thunar/-/merge_requests/9Use XfceFilenameInput2020-05-30T08:50:43ZReuben GreenUse XfceFilenameInputA short while ago, a new widget, XfceFilenameInput, was added to libxfce4ui. This widget is designed to be a "smart" replacement for the GtkEnty widget, specifically designed for the entry of filenames. See commit 8f0ad0c23947545abf249aa...A short while ago, a new widget, XfceFilenameInput, was added to libxfce4ui. This widget is designed to be a "smart" replacement for the GtkEnty widget, specifically designed for the entry of filenames. See commit 8f0ad0c23947545abf249aac56124cde74cdeb0a in libxfce4ui for details.
The first commit on this branch removes the whole thunar-create-dialog module from thunar, and replaces it with a single function in the thunar-dialogs module. I don't think that thunar-create-dialog needed to be an independent module, as its public interface really just consisted of a single function (which has been replaced by the new function in thunar-dialogs). The only reason there needed to be multiple functions to implement the create dialog was that a callback was used to check the validity of the entered text, and with XfceFilenameInput this is now redundant.
The second commit replaces the filename input functionality in the create dialog, the rename dialog, and the properties dialog with the new widget. This provides a unified implementation of filename entry rather than three separate ones. I have bumped the required libxfce4ui version to 4.15.1
Key points to note/for review:
1. The only change I have made to the "autotools files" are removing the two lines for thunar-create-dialog.c/.h from Makefile.am. I have however added new #include statements to some files, but it builds ok, so I assume that automake handles all the dependency generation? (my autotools knowledge is exactly zero, sorry)
2. Have I covered all of the places where thunar asks the user for a filename, or have I missed some?
Also, do let me know if I have done anything wrong/bad with the gitlab stuff. The new workflow has already caught some errors I made in an earlier version of this merge request, so I like it!
Comments and criticism are very welcome! Thanks!https://gitlab.xfce.org/xfce/thunar/-/merge_requests/10Replace GtkAction, GtkActionEntry and Remove GtkUiManager2021-03-02T13:10:10ZAlexander SchwinnReplace GtkAction, GtkActionEntry and Remove GtkUiManagerFinally here the review for that never-ending WIP branch.
Thanks alot to Reuben and AndreLDM, for early testing ! You helped me alot to find and fix the worst regressions.
(Though I am almost sure there still are some hidden ones here a...Finally here the review for that never-ending WIP branch.
Thanks alot to Reuben and AndreLDM, for early testing ! You helped me alot to find and fix the worst regressions.
(Though I am almost sure there still are some hidden ones here and there)
If you have the time to review and/or test, I would be very happy!
My **main mission** was: Replace the deprecated GtkAction, GtkActionEntry and the strongly coupled GtkUiManager
Here a **rough overview** on what I did:
- re-wrote `thunar-launcher` in a way so that it uses XfceGtkActionEntry instead of the deprectaed GtkActionEntry. I extended the responsibility of that widget to manage most MenuItems which are used in multiple places to follow [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) ( E.g. copy/paste/trash/delete/..). I introduced a simple API to activate files and open folders
- I completely dumped the usage of GtkUiManager and all *ui.xml files which were used for menu-creation. I dont see any advantage in porting that to GtkBuilder. IMO GtkBuilder makes sense for whole GUI's, but not to define the order of tiny menu fragments. That is done in the code now. I think that removes alot of complexity.
- The creation and show/hide of menu-item is not done on selection any more, but whenever the menu is displayed. That solves some flickering menu bug and improves the performance on rubberbanding
- Added the widget `thunar-menu-item`, which simplifies and unifies the creation of menu-fragments, which are re-used on different places with slightly different parameters
- Dumped all widgets which implemented a GtkAction, like thunar-history-action, thunar-trash-action, etc. and moved the logic to thunar-launcher or thunar-window
- Usage of thunar-menu / thunar-launcher as well for the window menu. XfceGtkActionEntries which are only used in thunar-window are defined there. Some internal logic was changed accordingly.
- Make use of new widget "thunar-menu" for location buttons instead of providing a foreign menu (Thats actually not part of Bug #16654, though it directly relies on the previous work)
thunar runs on each commit of this branch, though apperently it spits alot of Gtk CRITICALS on some commits.
As well functionallity is cropped between commits.
libxfce4ui master will be required to build this branch ( I guess that's the reason why the pipeline fails)
So I anyhow will have to wait for the next libxfce4ui release before merging.
The git history is now okish I think .. if you insists, here and there I possibly could do more granular commits.
Suggestion and critic would be very welcome !Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/11Add new app icon and switch to rDNS icon name2020-06-11T01:06:15ZSimon SteinbeißAdd new app icon and switch to rDNS icon nameSo here goes the final iteration (hope you like it) of the new Thunar icon.
We currently didn't provide any 64px icons for any Xfce applications in the first run, so I hope you're ok with losing that size (and 24px, but that one proba...So here goes the final iteration (hope you like it) of the new Thunar icon.
We currently didn't provide any 64px icons for any Xfce applications in the first run, so I hope you're ok with losing that size (and 24px, but that one probably matters less) for now. We may add those later to each app.
I also dropped the pixmaps folder with the old about logo, which may have been "borrowed" from some school.
**Caveat:** I only replaced all the instances of the thunar icon I could find in the code, please double-check if I didn't overlook anything...https://gitlab.xfce.org/xfce/thunar/-/merge_requests/12Move duplicated code from concrete views into a single standard-view method2020-06-12T08:11:28ZAlexander SchwinnMove duplicated code from concrete views into a single standard-view methodLike Proposed by @DarkTrick on !10Like Proposed by @DarkTrick on !10Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/13deduplicates code in thunar-application2020-06-09T07:23:49ZCyrille Pontvieuxdeduplicates code in thunar-applicationhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/14Small fixes following ReplaceGtkAction merge2020-06-10T20:42:26ZReuben GreenSmall fixes following ReplaceGtkAction mergeSo I've carried on reading through the changes from the ReplaceGtkAction branch merge. I have mainly focussed on finding small local memory leaks and similar issues (I hope that one day I will know enough about Thunar to be able to usefu...So I've carried on reading through the changes from the ReplaceGtkAction branch merge. I have mainly focussed on finding small local memory leaks and similar issues (I hope that one day I will know enough about Thunar to be able to usefully review the substance of changes like these!). This branch contains fixes for the few issues I found in thunar-launcher.c and thunar-window.c (plus one fix in thunar-menu.c, which I have not read properly yet).
In particular several of the fixes consist of adding calls to g_list_free to match calls to [gtk_container_get_children](https://developer.gnome.org/gtk3/stable/GtkContainer.html#gtk-container-get-children), as this method is transfer-container.
Thanks!https://gitlab.xfce.org/xfce/thunar/-/merge_requests/15Use numbering on label "open new window/tab" only for multiple2020-06-12T07:44:42ZAlexander SchwinnUse numbering on label "open new window/tab" only for multiplewindows/tabs (regression introduced within !10)windows/tabs (regression introduced within !10)Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/16Adding class doc for thunar-launcher and thunar-menu2020-06-13T21:18:01ZAlexander SchwinnAdding class doc for thunar-launcher and thunar-menuAlexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/17Adding class doc for thunar-launcher and thunar-menu2020-06-22T19:51:04ZAlexander SchwinnAdding class doc for thunar-launcher and thunar-menuA good place / good format for class specific doc ?
I just used the same scheme like gtk .. e.g.: [This one](https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtkaccessible.c)A good place / good format for class specific doc ?
I just used the same scheme like gtk .. e.g.: [This one](https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtkaccessible.c)Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/merge_requests/18MR for Bug 303: "Menu -> Edit -> cut/copy/paste does not work for location en...2020-07-11T15:57:08ZDarkTrickMR for Bug 303: "Menu -> Edit -> cut/copy/paste does not work for location entry"https://gitlab.xfce.org/xfce/thunar/-/merge_requests/19Per directory settings2022-03-31T09:50:07ZReuben GreenPer directory settingsSo here is the latest version of my attempt to add support for per-directory viewing settings to Thunar, as requested in issue #8. Thanks to everyone who has given feedback and suggestions on previous versions!
This MR implements per-...So here is the latest version of my attempt to add support for per-directory viewing settings to Thunar, as requested in issue #8. Thanks to everyone who has given feedback and suggestions on previous versions!
This MR implements per-directory saving of view type, sort column, and sort order. I do intend to implement per-directory support for the other features requested (zoom level, column width, hidden files), but I think that view type, sort column, and sort order are the most important ones for now.
A quick summary of the new features
* view type, sort column, and sort order can be set individually for each directory
* the use of per-directory settings is enabled/disabled by a new checkbox in the preferences dialog (Display tab)
* when per-directory settings are disabled (the default option), everything *should* work as it does before these changes
* per-directory settings are only saved/changed in response to an explicit action from the user, not simply by opening a folder
* any saved settings for the current directory can be deleted via an option in the view menu
It is possible that you may see errors like
`Gtk-CRITICAL ... gtk_tree_selection_path_is_selected: assertion 'GTK_IS_TREE_SELECTION (selection)' failed`
`Gtk-CRITICAL ... gtk_tree_selection_get_select_function: assertion 'GTK_IS_TREE_SELECTION (selection)' failed`
These are caused by (what I think is) a bug in exo which can be easily fixed. However, I have not seen them while testing this version of the code, so they might have been solved (?).
I have set these new features to be off by default, as this causes the least change from the user's point of view, but it would be very easy to have them on by default.
A technical point. @alexxcons suggested in response to a previous version that the metadata attributes should not be prefixed with `::thunar` (eg `metadata::thunar::view-type`), as then other file browsers can use these settings. I have not implemented this suggestion in this MR, since two of the three metadata values saved (`view-type` and `sort-column`) take Thunar-specific values (eg `ThunarCompactView` or `THUNAR_COLUMN_DATE_MODIFIED`) which (I think?) would not be useful to other file browsers. `sort-order` does take a generic value provided by GTK, but it seems bad having different prefixing schemes for different attributes. Maybe there is some standard for exchanging this kind of information (?). I am very open to changing this design, however!
Also, I have implemented the function thunar_gvfs_metadata_is_supported (in thunar-gio-extensions) to test whether gvfs metadata is available by querying DBus. I based this function on a few code scraps I found, some experiments, and the comprehensive (but not always easy) GIO documentation. The function detects the presence of gvfs metadata support correctly in tests on my system, but I do not know how well it will function on other systems. Any advice or comments from people who know about GIO or DBus would be very welcome!
As always, comments, criticisms, and suggestions are very welcome!https://gitlab.xfce.org/xfce/thunar/-/merge_requests/20Fixed the SEGV when the side pane is hidden (Issue #335)2020-06-25T21:26:15ZKazuki OikawaFixed the SEGV when the side pane is hidden (Issue #335)Fixed the SEGV occurs under the following conditions.
* last-side-pane is "void", thunar startup always failed in SEGV.
* after startup, hide sidepane and toggle "Show Hidden Files" caused SEGV.
Fixes #335Fixed the SEGV occurs under the following conditions.
* last-side-pane is "void", thunar startup always failed in SEGV.
* after startup, hide sidepane and toggle "Show Hidden Files" caused SEGV.
Fixes #335