User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty) Build Identifier: Currently it is not possible to make a particular directory to remember view settings. For example if my default view settings are View as compact list but I want some directories to display files as icons I cannot do it. Could be quite useful for dirs with images and so on. Reproducible: Always Steps to Reproduce: 1. Open Thunar 2. Enter any directory and change view 3. Leave the directory and see that all other directories have the new view settings Actual Results: All other directories have the new view settings Expected Results: There should be an option to have settings are changed only for this particular directory while other dirs retain the default settings set in the Preferences.
I am using 1.2.3. it's still a problem.
In version 1.6.3 it's still impossible to remember the view per folder. It would be very useful to have an option like this, because it's exhausting to set the view in every folder that you open. This is specially true when you work with different type of files in separate tabs or windows. I suppose that it could be implemented in 2 ways: either saving a hidden file in every directory that is configured (as Dolphin does) or saving the parameters in a configuration container (a hierarchy of directories, a small database...) The former is easier to implement I guess.
If I set the default view to be detailed list, and I later go to icons for a directory, all of the directory become icons. If I go back and try to reset the default, it still says it is detailed list. Really irritating. Thanks.
In my opinion, it would be necessary that this feature were implemented this way: 1. An option in the "Edit > Preferences..." menu to enable or disable the feature. 2. An option in the "Edit" menu that states something like "Apply current view to sub-directory". Although the most needed is the first point, I believe that having the second one would be useful for that times when one is working with a tree of directories and needs the same view in all them, in order to prevent having to visit the sub-directories one by one. I'm willing to offer $100 in BountySource providing that it's implemented as described here. If someone wants to collaborate with me, comment. Here it's the link: https://www.bountysource.com/issues/3547154-option-remember-view-settings-for-this-folder .
This would be very useful for the trash folder, because whenever I want to restore something, I need to order files by 'Date Modified' and then set back to 'Name'. This is annoying.
Let's group some other bugs under this one: * https://bugzilla.xfce.org/show_bug.cgi?id=4167 In the details view, the column widths and sorting method would be preserved for each directory * https://bugzilla.xfce.org/show_bug.cgi?id=5767 Make save/restore of view settings optional So, what needs to be stored per-directory * View mode (icons, compact, list) * Zoom level * Columns width * Sorting order * Hidden file display status (suggested in Bug 5767) Different directories may serve different purposes. For example, for a directory containing source code, you'll likely want to use List view with a low zoom. For a directory containing images, you'll want Icons view with high zoom. Sorting order should be remembered for use cases like André's. I'd not like this feature to litter my directories with config files; per-settings directory should ideally be stored in a config file or in xfconf. When no view options are set for the current folder, use the previous folder's settings by default. Confirmed on 1.6.3-2 on Debian
*** Bug 4167 has been marked as a duplicate of this bug. ***
*** Bug 5767 has been marked as a duplicate of this bug. ***
This is a pretty basic issue and the request has been open for almost ten years. Is the assignee still around? If not, can it be reassigned? There is also a cash bounty for this feature, see https://www.bountysource.com/issues/3547154-enh-usability-remember-view-settings-per-directory
I wouldn't wait for assignees, it's more likely to someone come up with a patch, but I don't think this feature will land before the GTK3 Port :/
:| Any very rough estimate on how long that port may take or where it's at? Maybe this could be included as part of the port. It's *very* basic functionality. Anyway, if it can't be included as part of the port, I will put a reminder in my calendar to bump this feature request even if it's a couple years out. This is very annoying behavior.
I can't speak for the devs, but the port is still going to take a little while, being pretty optimist we might have an 4.14 alpha by the end of the year. Here is how it's currently (a bit outdated): https://wiki.xfce.org/releng/4.14/roadmap Unfortunately, thunar, xfdesktop and xfwm are the ones lagging behind. It was settled that this was to be a 1:1 port, no big new feature, but if someone spare some time I think the patch will be more than welcomed. I can't promise anything, currently I'm porting xfce4-screenshooter and I'm not really knowledgeable of thunar's code.
*** Bug 14547 has been marked as a duplicate of this bug. ***
This feature has my emphatic up-vote!
maybe soon ?
Having a set of Thunar CLI options to select view style, order, etc... (overriding xfconf settings for the CLI launched instance) : would allow to play with launchers, and even to write external scripts that read a "per folder desktop file" containing view style directives .... just my 2 cents ;) JP
Just to provide an example of user experience caused by lack of this feature: I use XFCE on a HTPC box. Whenever I want to watch my tv-series, I go to the network drive (1 click), right-click (2) to choose 'sort by date modified' (3), then right-click again(4) to choose 'sort descending' (5), enter the right folder (6), then right-click again (7) to 'sort by name' (8) to find the episode I want. That's 8 mouse clicks where it should be 2 if sorting order for the top folder was remembered.
12 years have passed and this improvement has not yet been implemented. Please, could any dev consider this to improve XFCE?
Hi, It's a MUST HAVE feature : please could you work on it ? thanks jp
*** Bug 7107 has been marked as a duplicate of this bug. ***
A recent blog post about Xfce 4.16 mentions "storing view settings per directory" under Thunar section. https://simon.shimmerproject.org/2019/10/19/xfce-4-15-development-phase-starting/
In order to implement this, I believe that using directory attributes appears to be a good way to go. The most common file systems (ext4, btrfs, zfs and xfs) support extended attributes without much limitations. I can think of two main implementation possibilities: 1st option: Given that, I believe we could store directory metadata inside `$HOME/.config/Thunar/dirMetadata/` and store that location in the directory's user attr space alongside a token. E.g. For a directory in `/home/xfce/Documents/work/provided` Store a file at `$HOME/.config/Thunar/dirMetadata/home/xfce/Documents/work/provided..directory` (yes, two dots) <- Compatibility for file systems that don't support attr or have it disabled. Then store that metadata location in the directory's attr. <- Support in case the directory is moved around. Main advantage: 1. Limited compatibility with old or obscure file systems that don't allow custom user attr. Main disadvantage: 1. Mirror file system that requires everything to stay in place, including mounts, at the time the attributes have changed (if cannot store attributes in the directory itself) 2nd option: If we can just assume that "no user-level attr implies no custom attributes to directories" Store all in a directory's attr. I'd recommend trying to namespace the attributes with `@@Thunar_attr_` or equivalent Advantages: 1. Goes everywhere with the directory Disadvantages: 1. Hidden data that uses disk space -> Although it shouldn't be a problem to most people. Shared advantages: 1. No ".Directory" (or whatever equivalent) file which has already been source of problems to programs like firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=944918 2. No risk of deleting ".Directory" (or whatever equivalent) when cleaning the directory of all files. Any opinions?
I would prefer using a 3rd option: g_file_info_get_attribute () / g_file_info_set_attribute () (available for different concrete types) That will make use of the gvfs (GNOME Virtual File System) metadata concept. Afaik GVFS already builds a parallel file-tree where it stores all sort of file related metadata. Thunar already relies on gvfs (trash, removable media, remote locations ) ... so IMO we should make use of it as well here. (that should simplify things alot) Here some console snippets to read/write file attributes for testing: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/using-gvfs-metadata Advantages: - afaik works on all file systems, as well on remotes - Will save us a hell of work Disadvantages: - only works when gvfs is available (some people out there dont like gvfs) This bug already is on the xfce 4.16 shortlist (https://wiki.xfce.org/releng/4.16/roadmap/thunar). However currently I dont have time to work on it / I am working on Bug #14410 which will keep me busy the next months. So if you want to make sure that "view settings per directory" will make it into thunar xfce4.16 : Patches are always welcome !
OK. Nvm my options. Yours clearly wins by a lot. Whether I have time to contribute... Sadly... I don't have any experience with thunar... I'm trying to get some by making a couple plugins I'm keen to have. Maybe I'll start helping after I have those done and I get some confidence.....
Hehe, sorry, (In reply to brunoaiss+xfce from comment #24) > OK. Nvm my options. Yours clearly wins by a lot. Hehe, sorry, I should have added these ideas for implementation details before, instead of only keeping them in my mind :) > Whether I have time to contribute... Sadly... I don't have any experience > with thunar... I'm trying to get some by making a couple plugins I'm keen to > have. > Maybe I'll start helping after I have those done and I get some > confidence..... As you like .. though I am not sure if thunar plugin development will be much simpler than to fix this bug ;) IMO the way to fix this bug is more or less straight: On loading a folder, check if it has a meta-file-attribute for each view-setting. If so, load the value of it. If not, do like it is now (use the xfconf value). If a view-setting on some folder is changed and differs from the default (or always?), save it as meta-file-attribute. However like always: For sure there will be some unexpected problems ;)
>Hehe, sorry, I should have added these ideas for implementation details before, instead of only keeping them in my mind :) No worrries. I become like that when I'm the only one working on it too. Would it help if I try doing the main case and show a patch here and you try dealing with the edge and uncommon cases? If so, I may have time in mid next month to try this....
(In reply to brunoaiss+xfce from comment #26) > Would it help if I try doing the main case and show a patch here and you try > dealing with the edge and uncommon cases? > If so, I may have time in mid next month to try this.... That would be awesome ! I can take care for edge-cases later on. Were to start for the different settings: * View mode (icons, compact, list) --> "last-view" in thunar-window.c thunar_window_set_current_directory / thunar_window_action_view_changed * Zoom level --> PROP_ZOOM_LEVEL in thunar-standard-view (note that each view has a "last-*-zoom-level" property) * Columns width --> thunar_column_model_init (width, visible columns, order ) * Sorting order --> thunar_standard_view_sort_column_changed and thunar_standard_view_constructor * Hidden file display status (suggested in Bug 5767) --> PROP_SHOW_HIDDEN in thunar-standard-view If required to encapsulate g_file_info_get_attribute () / g_file_info_set_attribute (), "thunar-gio-extensions.c/.h" would be the right place. It would be nice to have one commit per setting. Here some overview on the "inheritance" structures of the thunar views: https://docs.xfce.org/xfce/thunar/software_architecture
I was trying to start making this but the distro I chose has too many old packages for me to handle updating manually. I'm expecting a fully system update which will include those needed packages in apt later this year. I'll pick this up when that happens so I don't waste time compiling them. Sorry about the delay.
(In reply to brunoaiss+xfce from comment #28) And wouldn't it be more practical to use a distro with updated packages like, for example, Arch Linux?
(In reply to Juan Simón from comment #29) > (In reply to brunoaiss+xfce from comment #28) > > And wouldn't it be more practical to use a distro with updated packages > like, for example, Arch Linux? If you want to use bleeding edge stuff, yes. Though to compile thunar from source it is sufficient to have something like debian stable. It helps if the distro provides *-dev packages (or similar) so that you dont need to build the dependencies, like libxfce4ui, libxfce4util, etc. from source.
Created attachment 9280 After compilation, there's no icons I was able to compile now but, when I start thunar, there's no icons for directories, drivers, etc.... Am I doing anything wrong with the compilation? Do I need to run something else for them to be available (e.g. thumbler)?
(In reply to brunoaiss+xfce from comment #31) > Created attachment 9280 > After compilation, there's no icons > > I was able to compile now but, when I start thunar, there's no icons for > directories, drivers, etc.... > Am I doing anything wrong with the compilation? > Do I need to run something else for them to be available (e.g. thumbler)? Looks wired, so far I did not run into that problem. I dont know what it is, though my guess would be that it could be related to an old libexo. Worth a try to install libexo from source.
(In reply to alexxcons from comment #27) > * Hidden file display status (suggested in Bug 5767) --> PROP_SHOW_HIDDEN > in thunar-standard-view I wouldnt recommend saving hidden file state on a per-directory basis, as it is a very sensitive feature. If it were implemented, would Ctrl + H work on a folder or global level?
I think CTRL+H would be per directory. However, there would be a tab in the preferences or a submenu in the "view" menu to apply the current sorting to all directories which do not have a behavior configured and an option to forget all custom ordering and wether to show hidden files. Maybe we provide CTRL+ALT+H for that. Opinions?
> I think CTRL+H would be per directory. Agreed ! > However, there would be a tab in the preferences or a submenu in the "view" menu to apply the current sorting to all directories which do not have a behavior configured and an option to forget all custom ordering and wether to show hidden files. I would not make it that complicated. IMO for the first go it should be sufficient to have a single "store setting per directory" toggle. I would not foresee any "walk a file-tree" features to forget some special attribute for a complete folder. IMO that would be overengeneering. If we find out later that more granularity is required, we might need to add xfconf flags per setting .. though I would not foresee that in the first run.
Hi all, so as I have a bit of time at the moment I'm going to look and see if I can implement this, unless anyone else is already working on it or intends to do so soon - if so please drop a comment here to let me know so we don't duplicate effort. If no one says they are working on it, I'll have a go. I'm going to take the outline in comment #27 as a starting point, unless anyone has strong feelings against that - if so let me know!
Thank you Reuben. I only did investigation and tried to compile so far. Feel free to pick it up.
(In reply to alexxcons from comment #35) > > I think CTRL+H would be per directory. > Agreed ! Just to put it out there, most file manager don't saves hidden file status on a per directory basis, including Nautilus, Nemo, Caja, Finder, and Windows Explorer. The only one that does is Dolphin. Seems Dolphin went down the route of using a .directory hidden file to save per-directory preferences. > I would not make it that complicated. > > IMO for the first go it should be sufficient to have a single "store setting > per directory" toggle. Yep that is the best option. Here is how it looks in Dolphin. https://imgur.com/rUywsrt.png Nemo has a 'Inherit view type from parent' option, if that is wanted to be considered - https://imgur.com/iXc0Csu.png On a separate note, which likely may need a separate bug report, Nemo and Caja have a View > Reset View to Defaults option to clear the per-directory preferences.
(In reply to Jay Philips from comment #38) > (In reply to alexxcons from comment #35) > > > I think CTRL+H would be per directory. > > Agreed ! > > Just to put it out there, most file manager don't saves hidden file status > on a per directory basis, including Nautilus, Nemo, Caja, Finder, and > Windows Explorer. The only one that does is Dolphin. Seems Dolphin went down > the route of using a .directory hidden file to save per-directory > preferences. > I see... I don't know how people would prefer that I can only know well my own personal preference... (In reply to Jay Philips from comment #38) > (In reply to alexxcons from comment #35) > > I would not make it that complicated. > > > > IMO for the first go it should be sufficient to have a single "store setting > > per directory" toggle. > > Yep that is the best option. Here is how it looks in Dolphin. > https://imgur.com/rUywsrt.png > Nemo has a 'Inherit view type from parent' option, if that is wanted to be > considered - https://imgur.com/iXc0Csu.png > > On a separate note, which likely may need a separate bug report, Nemo and > Caja have a View > Reset View to Defaults option to clear the per-directory > preferences. I think the best we can do is having Nemo's options style. Choose one of: -> All shared same (default) -> Inherit from parent The question I leave here is whether inheriting from the parent is a slow process. Usually, users transverse, which is fast. However, reading many files for a whole inheritance can be slow. Those are my opinion.
I've had a bit of a look at this now. I think that this will not be too difficult to implement from a technical standpoint, but I'd like to get an idea of how people think this should be presented to the user. I have an initial idea of how to do this, but I don't know if it is the best way. My proposal is as follows. We put a single new check box in the "View" menu, entitled "Save settings for directory" or something like that. We also have, as we do at the moment, a collection of "currently active settings" which are used to display any directory that does not have custom settings stored. The "Save settings for directory" box controls whether any changes the user makes to the viewing settings affect the "currently active settings" (such changes would then affect the viewing of all directories without custom settings) or else are saved as custom settings for this directory (which will persist between visits to this directory but won't affect how other directories are displayed). When a new directory is loaded, we check whether there are any stored setting for this directory (via gvfs as discussed above). If not, then we set the "Save settings for directory" box to be unchecked, and display the directory with the "currently active settings". If there are saved settings, we set the "Save settings for directory" box to be checked, and use the custom settings. The user can check or uncheck the box. If they change the box from checked to unchecked, then the custom settings are deleted. If they change the box from unchecked to checked, then the current settings are saved and any further changes affect the saved settings. I hope that makes sense. I'm going to start working on a demonstrator patch for this to give people a better idea of what I mean, and I'll try to get that up soon. What do people think of this plan? If what I've written above is confusing, ask me and I'll try to clarify.
Clarification: so if the user changes the "Save settings for directory" box from checked to unchecked, the viewing settings are not changed, but the settings stored via gvfs are removed so that subsequent visits to this directory use the "currently active settings".
(In reply to Reuben Green from comment #40) Z If there are saved settings, > we set the "Save settings for directory" box to be checked, and use the > custom settings. The user can check or uncheck the box. If they change the > box from checked to unchecked, then the custom settings are deleted. (In reply to Reuben Green from comment #41) > Clarification: so if the user changes the "Save settings for directory" box > from checked to unchecked, the viewing settings are not changed, but the > settings stored via gvfs are removed so that subsequent visits to this > directory use the "currently active settings". I disagree. I believe that unchecking that box should produce immediate results and the settings should not be deleted. 1. Deleting the directory-specific settings should require an explicit action. The checkbox should only control the enabled state of the functionality, IMO. 2. Checking and unchecking the box should produce immediate results. Users expect to see changes when they do an action that creates a change. Not producing immediate results will make many users ask if the uncheck broke something or if Thunar is broken. Applying these two can also allow for "peeking" as an additional use-case. As if there were two profiles to see each directory where one is globally shared. That's my opinion
Thanks for the thoughts, brunoaiss! Yes, on reflection I think you are right. So maybe we should have a pair of radio buttons to toggle between the two profiles, with one labelled something like "Use custom directory settings" and the other "Use shared settings" (although these are not good names for them, hopefully we can come up with something better)?
Checkboxes are fine, though. No need for radio buttons if it's a toggle ideology. Actually, a checkbox is more in line with the logic where the idea is to be on or off. In this case, "on" means to have special config for that directory and "off" being using general config. However, if you want to use the 3 stage possibility I proposed or expecting extended functionality from addon/extension developers, then radio buttons start making sense.
(In reply to brunoaiss+xfce from comment #42) > I believe that unchecking that box should produce immediate results and the > settings should not be deleted. Yes this is ideal, though it wont produce immediate results if you arent in a folder that has directory-specific settings saved. > 1. Deleting the directory-specific settings should require an explicit > action. The checkbox should only control the enabled state of the > functionality, IMO. We should have a View > Reset View similar to Nemo and Caja when directory-specific settings are being saved and a button in the dialog to delete all saved directory-specific settings. (In reply to Reuben Green from comment #43) > So maybe we should have a pair of > radio buttons to toggle between the two profiles, with one labelled > something like "Use custom directory settings" and the other "Use shared > settings" (although these are not good names for them, hopefully we can come > up with something better)? Dolphin has radio buttons called * Use common properties for all folders * Remember properties for each folder Nemo has a checkbox called 'Ignore per-folder view preferences'. Looking at thunar's preferences dialog, i think a checkbox would be sufficient and could be called something like 'Remember folder view preferences'. mockup - https://i.imgur.com/YxvuTZN.png
> 'Remember folder view preferences'. Sounds ok to me. > "Save settings for directory" I would rather go with "Save settings per directory" .. Reuben, since you are the one doing the work, pick what you like the most :) Generally I think we should toggle the preference of all folder, not only the current folder with that setting. - If any folder does not have custom settings, the default is used. - Only when a setting of the default is changed, it is written to gvfs. A toggle of "Save settings per directory" would than toggle between "write to xfconf" and "write to gvfs only for that folder". Though I have to admit that your first idea would allow more granular control, I dont think that it is required to decide on the usage of custom-settings per directory.
My 2 cents, start simple: a global toggle, hidden files visibility is still global, only store View Type, Zoom Level and Selected Column as well as their Widths (for detailed view). (In reply to Jay Philips from comment #45) > We should have a View > Reset View similar to Nemo and Caja when > directory-specific settings are being saved and a button in the dialog to > delete all saved directory-specific settings. This can be address later if Reuben feels that's too much to do. I have an idea for this: Thunar can keep a sort of version counter, whenever those settings are reset that counter is increased, if the settings of a directory is not equal to the current version, discard them. This way Thunar doesn't need to go over the entire file tree, unless gvfs already deals with this efficiently. (In reply to alexxcons from comment #46) > Generally I think we should toggle the preference of all folder, not only > the current folder with that setting. > - If any folder does not have custom settings, the default is used. > - Only when a setting of the default is changed, it is written to gvfs. > A toggle of "Save settings per directory" would than toggle between "write > to xfconf" and "write to gvfs only for that folder". And how would one define the default state? Disabling "Save settings per directory", making changes and enabling?
> And how would one define the default state? Disabling "Save settings per directory", making changes and enabling? Yes, that would be the way to change the default. Not perfect, though so far no better solution crossed my mind.
(In reply to Andre Miranda from comment #47) > My 2 cents, start simple: a global toggle, hidden files visibility is still > global, only store View Type, Zoom Level and Selected Column as well as > their Widths (for detailed view). As long as the hidden files can be added to the set in the near future, I can accept such compromise. > (In reply to Jay Philips from comment #45) > > We should have a View > Reset View similar to Nemo and Caja when > > directory-specific settings are being saved and a button in the dialog to > > delete all saved directory-specific settings. > > This can be address later if Reuben feels that's too much to do. > I have an idea for this: Thunar can keep a sort of version counter, whenever > those settings are reset that counter is increased, if the settings of a > directory is not equal to the current version, discard them. This way Thunar > doesn't need to go over the entire file tree, unless gvfs already deals with > this efficiently. I believe the resetting is meant to be directory by directory basis. At least, that's my interpretation. With that, you can just delete also because there's not much to delete. (In reply to alexxcons from comment #48) > > And how would one define the default state? Disabling "Save settings per directory", making changes and enabling? > Yes, that would be the way to change the default. Not perfect, though so far > no better solution crossed my mind. I still wasn't able to find a good alternative to that. I've been thinking about a submenu that shows the same options except it applies globaly. I don't know how better that is.
Thanks for the comments, everyone! So I think I have an idea of how to proceed now. For the first try, I'll implement a single global toggle to either use per-directory settings or not, with all the properties except hidden files being saved per-directory if the toggle is enabled. Then we can see how that goes. Hopefully I'll have a patch soon.
Hello all. I'm still working on implementing this, but it is proving to be rather more complicated than I thought. In particular, in order to implement the per-directory view settings, I am having to understand the rather intricate way that several functions in thunar-window.c interact, and this is taking some time. Thus I might not be able to get a patch up as soon as I had hoped. Watch this space!
Quick update. alexxcons is currently working on replacing all the deprecated GtkAction related stuff in Thunar, see https://github.com/alexxcons/thunar/tree/ReplaceGtkAction2. Since this change affects parts of the code related to this feature, and this new code should hopefully be in Thunar master soon, I have switched from working on a patch based on the current master to one based on Alex's new work. I hope to have something soon.
Created attachment 9701 draft patch to demonstrate per directory view type So here is a *draft* patch to implement per directory saving of view type only. Please take a look if you can and tell me if the way I have implemented this feature is what people want. If people like this, then I will add the saving of other properties (eg zoom level). So as I mentioned above, this is a patch against this branch https://github.com/alexxcons/thunar/tree/ReplaceGtkAction2, as this branch is the future for thunar. So the changes are as follows. In the view menu, I have added a check box to save the view settings per directory (and of course the state of this box is saved between sessions). If this box is unchecked, then everything should work as it does at the moment in thunar: there is one shared view type that is set using the radio buttons in the view menu. If the check box is checked, then when a new directory is loaded, a check is made for a saved view type. If a saved view type is found, then that is used, and if not then the current shared view type is used. If the check box is ticked, then the view setting is saved individually for each directory. So this patch is the end result of a lot of experiments, fiddling, and mistakes, so it probably has bad bugs in it. I will probably rewrite it from the start for the final version and take more care, but I wanted to get this version up now for people to look at, so I've posted this draft version now. In particular, the code I have added to thunar-file.c is a quick hack to get this working: it is not at all integrated into the existing thunar/thunarx file properties system as it should be. If anyone can give me some tips on how to do this in a better way, that would be great. Let me know what you think!
Hi, I cannot comment about the code itself, a few questions about the implementation: - shouldn't this option be in the file manager preferences https://docs.xfce.org/xfce/thunar/preferences, rather than in the menu? There are already folder view settings there - doesn't it interact/conflict with these prefs? (notably the "Last active view" mode) - if the box is checked, and you load a new directory, which does not have a saved view type, the default view type is loaded -> is it also saved for this directory? props for the patch, I am very interested in this feature
(In reply to Julien [nodiscc] from comment #54) Thanks Julien! To answer your points > - shouldn't this option be in the file manager preferences > https://docs.xfce.org/xfce/thunar/preferences, rather than in the menu? Yes, it could certainly go there. That might make more sense actually, since this setting is not one people would want to change much so maybe it does not need to be under "view" > - doesn't it interact/conflict with these prefs? (notably the "Last active > view" mode) It does interact with those prefs, but it uses them in (I think) the same way as they were used before - to determine the view used when a new window opens its first view. > - if the box is checked, and you load a new directory, which does not have a > saved view type, the default view type is loaded -> is it also saved for > this directory? Yes, that setting would be saved, and now I think about it that is a problem because if you switch off per directory settings and visit some directories with saved settings, those saved settings will get overwritten. So I see now that I need to add a mechanism to only save settings when they result from the user actually changing the view with the radio buttons (I think that might require some large modifications to the existing code...) > props for the patch, I am very interested in this feature Thanks! I hope to get it done soon.
note: I didn't read the code yet. Didn't get the time but I don't want this to be forgotten (In reply to Reuben Green from comment #55) > (In reply to Julien [nodiscc] from comment #54) > > - if the box is checked, and you load a new directory, which does not have a > > saved view type, the default view type is loaded -> is it also saved for > > this directory? > Yes, that setting would be saved, and now I think about it that is a problem > because if you switch off per directory settings and visit some directories > with saved settings, those saved settings will get overwritten. So I see now > that I need to add a mechanism to only save settings when they result from > the user actually changing the view with the radio buttons (I think that > might require some large modifications to the existing code...) I give emphasis to that. There should be no interaction with the stored directory-specific settings when that option is inactive. When the option is activated, thunar should load the settings currently stored regardless of the global view settings (and continue loading for future accesses). I think if the user doesn't change any settings for a directory, no directory-specific settings should be stored regardless of this new setting.
Julien, brunoaiss - sorry guys, I've been an idiot. My patch *does not* in fact change the stored settings for each directory when the option is switched off. Sorry, I answered in a hurry and did not think about it. On the other hand, the good news is that this means that the patch does not have the bug we were worried about!
thunarx-private.h:36: Warning: Thunarx: symbol='I_': Unknown namespace for symbol 'I_' GICOMP Thunarx-3.0.gir make check-TESTS make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' ============================================================================ Testsuite summary for thunar 1.8.13git-UNKNOWN ============================================================================ # TOTAL: 0 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' make[1]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' Making check in thunar make[1]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make check-am make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make[2]: *** No rule to make target 'thunar-marshal.c', needed by 'thunar-thunar-marshal.o'. Stop. make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make[1]: *** [Makefile:2501: check] Error 2 make[1]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make: *** [Makefile:764: check-recursive] Error 1 make all-recursive make[1]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2' Making all in icons make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons' Making all in 16x16 make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/16x16' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/16x16' Making all in 24x24 make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/24x24' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/24x24' Making all in 48x48 make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/48x48' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/48x48' Making all in 64x64 make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/64x64' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/64x64' Making all in 128x128 make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/128x128' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/128x128' Making all in scalable make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/scalable' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons/scalable' make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons' make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/icons' Making all in pixmaps make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/pixmaps' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/pixmaps' Making all in po make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/po' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/po' Making all in thunarx make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunarx' Making all in thunar make[2]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make all-am make[3]: Entering directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make[3]: *** No rule to make target 'thunar-marshal.c', needed by 'thunar-thunar-marshal.o'. Stop. make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make[2]: *** [Makefile:896: all] Error 2 make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2/thunar' make[1]: *** [Makefile:764: all-recursive] Error 1 make[1]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction2' make: *** [Makefile:591: all] Error 2
great, then. I still don't know if I can compile thunar... However, I'd like to be able to use a docker container (or similar) to compile thunar without affecting the host
(In reply to HYPERION from comment #58) Humm, my patch does not touch thunar-marshal.c. Can you try compiling the ReplaceGtkAction2 branch without my patch to see if you get the same error?
--enable-maintainer-mode is needed :)
It builds, I get the new checkbox, but view settings are still always global even with box checked
(In reply to HYPERION from comment #62) > It builds, I get the new checkbox, but view settings are still always global > even with box checked So when I run the patched thunar, I can do the following (with the check box checked) 1 - create a new empty directory, dir_a, and navigate there 2 - create a new empty directory, dir_b, in dir_a 3 - create a new empty file in dir_b (to see the effect of the view changes) 4 - in dir_a, set the view to Icon 5 - in dir_b, set the view to Details. Then going up and down between dir_a and dir_b, I see dir_a in icon view and dir_b in details view. Does this not work for you?
OK, I misunderstood the feature : it works ! What I was expecting is to set the sorting order (by Name, by Modification, ..) per directory. It seems more important to me than setting list/icon view per directory What do you think about it ?
(In reply to HYPERION from comment #64) > OK, I misunderstood the feature : it works ! > > What I was expecting is to set the sorting order (by Name, by Modification, > ..) per directory. > > It seems more important to me than setting list/icon view per directory > > What do you think about it ? Yes, I intend to implement the saving of sort-order, zoom-level, and the other settings discussed above, but this patch is just a demonstrator that can only do the view type, just to get some initial feedback on the implementation before I go ahead and do all of those other features (I picked view type for the demonstrator as I guessed it would be the hardest to implement, so if this patch works for view-type then I think it should be easy to add the other features). But anyway, thanks for testing!
Ctrl-A makes Thunar segfault
(In reply to HYPERION from comment #66) > Ctrl-A makes Thunar segfault My system gives a warning rather than a segfault, but yes this is definitely a bug. Thanks!
Created attachment 9872 patch to implement per directory storing of view type and sort order So here, finally, is the next version of my fix for this. I'm sorry it has taken sooooo long - implementing per-directory view types turned out to require some changes to how thunar handles views/tabs which took me a long time to figure out. So this patch implements per-directory saving of view type and sort order. I am going to start work on the other features (zoom level, column width, hidden files) soon, but I wanted to get something up for people to look at. This patch is based on the branch at https://github.com/alexxcons/thunar/tree/ReplaceGtkAction45 A quick summary of the new features (*) 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, everything *should* work as it does without this patch (*) per-directory settings are only saved/changed in response to an explicit action from the user, not simply by opening a folder (*) the patch does not implement a way to delete the stored settings for a directory: you can overwrite them with new settings or turn off per-directory settings, but not delete them (I intend to add this but have not thought about how it should work yet) Known bugs/issues (*) if you run this patched thunar in the terminal, you will see lots of errors of the form GLib-GObject-CRITICAL ... g_object_unref: assertion 'G_IS_OBJECT (object)' failed these errors are due to an issue on the ReplaceGtkAction45 branch (but my patch causes more of them to appear) (*) you may see errors like Gtk-CRITICAL ... gtk_tree_selection_path_is_selected: assertion 'GTK_IS_TREE_SELECTION (selection)' failed and 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 (*) the way I have implemented the saving of file attributes in thunar-file.c is very crude, see the comments in that file - any help from people who know how to do this better would be very welcome! Let me know what you all think. Comments, criticisms, and suggestions are very welcome!
I'll give you some if I can compile it this time.
So the latest version of the ReplaceGtkAction branch is now here https://gitlab.xfce.org/xfce/thunar/-/tree/ReplaceGtkAction52. The patch in comment 68 applies without problem on this new branch, so you should use that to test my patch. Thanks!
/usr/bin/ld: thunar-thunar-abstract-icon-view.o: in function `thunar_abstract_icon_view_connect_accelerators': thunar-abstract-icon-view.c:(.text+0xbfc): undefined reference to `xfce_gtk_accel_map_add_entries' /usr/bin/ld: thunar-thunar-abstract-icon-view.o: in function `thunar_abstract_icon_view_disconnect_accelerators': thunar-abstract-icon-view.c:(.text+0xbd2): undefined reference to `xfce_gtk_accel_group_disconnect_action_entries' /usr/bin/ld: thunar-thunar-abstract-icon-view.o: in function `thunar_abstract_icon_view_connect_accelerators': thunar-abstract-icon-view.c:(.text+0xc1c): undefined reference to `xfce_gtk_accel_group_connect_action_entries' /usr/bin/ld: thunar-thunar-details-view.o: in function `thunar_details_view_connect_accelerators': thunar-details-view.c:(.text+0xd7c): undefined reference to `xfce_gtk_accel_map_add_entries' /usr/bin/ld: thunar-thunar-details-view.o: in function `thunar_details_view_disconnect_accelerators': thunar-details-view.c:(.text+0xd52): undefined reference to `xfce_gtk_accel_group_disconnect_action_entries' /usr/bin/ld: thunar-thunar-details-view.o: in function `thunar_details_view_connect_accelerators': thunar-details-view.c:(.text+0xd9c): undefined reference to `xfce_gtk_accel_group_connect_action_entries' /usr/bin/ld: thunar-thunar-launcher.o: in function `thunar_launcher_append_accelerators': thunar-launcher.c:(.text+0x1bdc): undefined reference to `xfce_gtk_accel_map_add_entries' /usr/bin/ld: thunar-launcher.c:(.text+0x1bfc): undefined reference to `xfce_gtk_accel_group_connect_action_entries' /usr/bin/ld: thunar-thunar-menu.o: in function `thunar_menu_hide_accel_labels': thunar-menu.c:(.text+0x7b8): undefined reference to `xfce_gtk_menu_item_set_accel_label' /usr/bin/ld: thunar-thunar-standard-view.o: in function `thunar_standard_view_finalize': thunar-standard-view.c:(.text+0x1937): undefined reference to `xfce_gtk_accel_group_disconnect_action_entries' /usr/bin/ld: thunar-thunar-standard-view.o: in function `thunar_standard_view_set_property': thunar-standard-view.c:(.text+0x432b): undefined reference to `xfce_gtk_accel_map_add_entries' /usr/bin/ld: thunar-standard-view.c:(.text+0x4345): undefined reference to `xfce_gtk_accel_group_connect_action_entries' /usr/bin/ld: thunar-thunar-window.o: in function `thunar_window_init': thunar-window.c:(.text+0x193e): undefined reference to `xfce_gtk_accel_map_add_entries' /usr/bin/ld: thunar-window.c:(.text+0x195b): undefined reference to `xfce_gtk_accel_group_connect_action_entries' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:981: thunar] Error 1 make[3]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction52/thunar' make[2]: *** [Makefile:896: all] Error 2 make[2]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction52/thunar' make[1]: *** [Makefile:765: all-recursive] Error 1 make[1]: Leaving directory '/data/Zenwalk/sources/z/thunar/tmp/thunar-ReplaceGtkAction52' make: *** [Makefile:592: all] Error 2
(In reply to HYPERION from comment #71) > /usr/bin/ld: thunar-thunar-abstract-icon-view.o: in function >... > make: *** [Makefile:592: all] Error 2 You need the latest version of libxfce4ui master to compile the ReplaceGtkAction52 branch - sorry, I should have mentioned this. Thanks!
Sorry, I had some trouble with https://gitlab.xfce.org/xfce/thunar/-/tree/ReplaceGtkAction52 generating many emails / bugzilla comments when using the official repo. So I moved it to my private repo: https://gitlab.xfce.org/alexxcons/thunar/-/tree/ReplaceGtkAction52 I did some modifications on #52 .. patch does not apply there for me. So I used #45, which still seems to work fine. Sorry for the fuzz .. hope I will have time later this day to test the patches !
(In reply to alexxcons from comment #73) > Sorry, I had some trouble with > https://gitlab.xfce.org/xfce/thunar/-/tree/ReplaceGtkAction52 generating > many emails / bugzilla comments when using the official repo. So I moved it > to my private repo: > https://gitlab.xfce.org/alexxcons/thunar/-/tree/ReplaceGtkAction52 > > I did some modifications on #52 .. patch does not apply there for me. So I > used #45, which still seems to work fine. > > Sorry for the fuzz .. hope I will have time later this day to test the > patches ! No worries! The patch applied ok to ReplaceGtkAction52 in the official repo last night - I'll have a look now.
(In reply to alexxcons from comment #73) > I did some modifications on #52 .. patch does not apply there for me. So I > used #45, which still seems to work fine. So I've just freshly cloned your private thunar repo, checked out ReplaceGtkAction52, and the patch from comment 68 applies cleanly to that branch on my system. Maybe I am doing something wrong? Anyway, there's no rush with this, so take your time! Meanwhile I will try to get myself set up with the xfce gitlab so that I can join the future too :)
Just tested the patch, very nice ! A minor thing: I would move the checkbox in the preferences as an additional item below "Standard view". That saves some space, and IMO it would fit well there. A thing to fix: If gvfs is not available, the preference item should be insensitive. ( Would be good to mention in the tooltip that gvfs is required) Currently settings are not kept, when testing with gvfs disabled, no matter if "use per directory settings" is enabled. Here some lines on how to disable: https://wiki.xfce.org/thunar/dev/temp_disable_gvfs > * The implementation of the following two functions is a hack to get this > * patch to work to demonstrate the concept. I have not used GFile attributes > * before, and I could not find any good example code to copy, so these functions > * are probably badly implemented. Also, in the final fix, these functions should > * be better integrated into the existing file attribute system in thunar and > * thunarx - any help or advice on how to do this would be most welcome! There is: thunar_file_get_emblem_names / thunar_file_set_emblem_names So far we did not prefix the attributes with ::thunar . E.g. for "metadata::emblems", the benefit is, that as well nautilus/nemo will show the emblem. So I guess it would be nice to re-use nautilus attribute-names/values, whenever possible. Maybe there is some guideline on attribute naming .. though so far I found nothing. There is as well THUNARX_FILE_INFO_NAMESPACE .. as far as I get this correct, adding your attributes there leads to having them automatically loaded by "thunar_file_load" and "thunar_file_get_async" .. though I dont know why it is not done like that for the emblems. Afaik till now only for emblems the attributes actually are used. > Meanwhile I will try to get myself set up with the xfce gitlab so that I can join the future too :) For a code review later on, gitlab is really a game changer :) .. whenever you feel the patch is ready for that.
Patch applied, Thunar #ReplaceGtkAction52 built, killall -9 Thunar; thunar& : no new button, nothing !! I'm going to rebuild on another version, to see if it helps..
(In reply to HYPERION from comment #77) > Patch applied, Thunar #ReplaceGtkAction52 built, killall -9 Thunar; thunar& > : no new button, nothing !! > > I'm going to rebuild on another version, to see if it helps.. Thanks for taking the time to test this! The check box to enable/disable this is in the "Display" tab of the preferences dialog, not in the view menu as with the previous version (in case you were looking in the view menu)
So I have found a bug in my patch - if you set the arrange-by options in a directory and then navigate to a directory without saved settings, that directory is displayed with the arrange-by options you set in the previous directory, not the global settings. So the "last-*" properties are being set when they should not be. This *should* be easy to fix.
Obviously I found the check box where you placed it :) It's nice... can't wait to test your next patch with above fix ..
(In reply to alexxcons from comment #76) Thanks for the comments! I'll implement them in the next version. > A minor thing: I would move the checkbox in the preferences as an additional > item below "Standard view". That saves some space, and IMO it would fit well > there. I can't see "Standard view" anywhere in the preferences - do you mean "Default view"? Maybe we should retitle "Default view" to something else, as per-directory settings aren't really a "default" option? > There is: > thunar_file_get_emblem_names / thunar_file_set_emblem_names Indeed there is! I have no idea how I missed those functions... :) Thanks!
(In reply to Reuben Green from comment #81) > I can't see "Standard view" anywhere in the preferences - do you mean > "Default view"? Maybe we should retitle "Default view" to something else, as > per-directory settings aren't really a "default" option? Ops ... I am using LOCAL=german here, where it is called "Standardansicht" :) I did not check the code for the original name. Yes, I agree that we should than rename this section e.g. to "Standardview" ... its anyhow not really about defaults.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/8. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev