Like proposed here: https://bugzilla.xfce.org/show_bug.cgi?id=11266#c123
Inside each *.rc file, one could store the path to the wallpaper, the related icon grid for the screen, the icon-size for the screen and possibly more.
This would have multiple benefits:
Proper fix for icon reorder problem: Bug #11266
Fixes "seperate icons for different screens" Bug #9774
Background image not saved per monitor - Bug #12385
This would be a bigger change and possibly require a separate development branch.
Version: Unspecified
Edited
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Forget about *.rc files .... there are already per monitor settings of xfdesktop inside xfconf. Just add the grid settings there. Possible to add them even per workspace. E.g:
As proposed in Bug #11266, as well in xfconf there should be some link to "latest", so that e.g. plugging in a different monitor will still load the latest configuration. Possibly sufficient to always load the config fo "monitor0" in this case.
Hm, I never designed xfconf to be a generic "database" type store, and reading and writing icon positions could get pretty "chatty" over dbus. Using GridItem_X_Y as the keys seems a bit noisy, but storing all the data (perhaps as a JSON blob) in a single property feels pretty inefficient (and prone to update races) as well. Also, I always planned to support free (non-grid-snapped) positioning on the desktop, so using fixed (x,y) cell positions wouldn't work anymore.
I guess an alternative would be to have the xfconf key be the filename/identifier (URL-encoded, if necessary). That would allow for free positioning and probably be more efficient when it comes to looking up positions anyway. The annoying bit there, though, would be that it'd be harder to remove keys when files disappear (I guess that would work ok while xfdesktop is running, as xfdesktop sees the file being removed, but if someone moves/removes files when xfdesktop is not running, we'd end up with stale keys after a while). With the rc file approach, every time something changes, the whole file is rewritten, which automatically drops missing files.
The icon positions also feel like "state data" to me and not "configuration". Compare to, say, .DS_Store on macOS, which holds (among other things) the positions of icons in Finder. Not sure how Windows stores them, though.
But yeah, I'm just not really sure how I feel about this yet. Xfconf does have a bulk-get-with-prefix method, so at least we could populate all positions on startup with a single round-trip. And icon positions probably don't change that often; each change would just be a single round-trip (which is probably comparable to a full file rewrite and rename, which is what happens now). And a possibly-nifty side-effect of this would be that you could move icons on the command-line with xfconf-query.
(Sorry about my stream-of-consciousness evaluation of this, but let's keep going!)
Ok, so what would this look like in practice? We'd put all positions under its own prefix, like /file-icons/positions. The per-icon key under that would be /${IDENTIFIER_OR_LABEL}. And then we could have one of two approaches. The probably "more optimized" approach would be to have that single key, and store the position -- say, [ row, col ] as an array of values. Downside there is that if we want to put more information (like say, screen or monitor number) in the future if more features are added, then that might not work so well (especially if the extra data needed is of a different data type; I don't believe xfconf supports mixed types in arrays). Other option is to have sub-keys under the main key, so /row, /col, etc. That's more flexible, and also would allow us to easily switch to /x & /y for free-positioning, but is pretty inefficient storage-wise inside xfconf. Actually, scratch that; I just refreshed my memory as to what xfconf's XML output looks like, and it actually is more efficient to store separate keys than an array of values under one key (almost certainly uses more memory for separate keys, though).
But the rc file also includes the screen number and screen resolution in the filename. So how would we represent that? I guess we could do key names that look like /file-icons/positions/${IDENTIFIER_OR_LABEL}/screen${N}/${RESW}x${RESH}/row. The issue there is that when the screen resolution changes, we want to know what "latest" config was used in order to try to start off the new resolution with icons as close to their prior positions as possible. If the resolution changes while xfdesktop is running, we get notified of the change, so that's not an issue, but if the resolution changes when it's not running... I guess we could store the last-used resolution somewhere, like /file-icons/screen${N}/latest-resolution; then if we start up and there's nothing at all under the key for the current resolution, we could check the last-used resolution.
I would also like to make sure this doesn't make it hard to implement possible new features. I believe there's a feature request to allow different icon positions on different screens (that is, "X screens", not "monitors"), for example.
So... yeah. I think I'm feeling more convinced than I was when I first started writing this comment. But also I do question what the benefit is: what do we gain by moving this data into xfconf? Not only does this have the potential for new bugs, but we'd also have to write migration code. Aside from the idea that keeping everything configuration-like in one place is probably a nice goal, the only user-facing feature this could enable is the ability to use xfconf-query to move icons around on the screen, but I'm not sure anyone even cares about doing that (technically we could monitor the rc file for external changes and reload it if we wanted to, though). I see in the original bug that doing this could potentially fix some other bugs, but I don't see why this is a prerequisite; those bugs could (and probably should) get fixed in the current rc file implementation. Is there something else I'm missing?
Before that patch, e.g. if you only increase the size of the panel by 1px, a new *.rc file was searched. If not available, an empty grid was used. Now instead the most recent *.rc is re-used for loading the grid, but the new grid is saved at a new location. (Still is a bit silly, to create a new \*.rc if I only change the size of the panel by 1px. In addition the fix seems not to fix all use cases. See #58 (closed) )
So iirc, my idea was, to fix such problems by storing the grid only per-screen (or per monitor).
Since the xfce4-desktop xfconf channel already now stores background, color gradient and stuff per screen/monitor. And since as well all other xfdesktop settings are stored via xfconf, I thought it would be a good idea to as well store the grid inside that structure (considering things anyhow need to be changed).
Though yes, just removing the ${RESW}x${RESH} from the filename as well should fix the actual problem.
However I suppose using ${RESW}x${RESH} as part of the filename was introduced for some reason .. probably for dockable additional displays ? To support that, I suppose it could make sense to have an icon-grid per monitor, and not only per screen.
On the other hand, if I swap a monitor for a different one, I would expect to see the same grid than before. So we probably still need some kind of pointer, pointing at the latest valid configuration which could be used as template for that new monitor.
So using icons.${screen}.rc or icons.${screen}-${monitor}.rc files might be a different approach over the usage of xfconf properties.
The second one would be a rather drastic change, since it would require loading one grid per monitor in a multi-monitor setup. and it would require interaction between multiple grids (e.g. for DnD)
If you think that makes sense, I can open a fresh issue for further discussion. This old issue actually missed the point.
(Sorry, I suppose I should have explained my reasoning better in the first post 3 years ago)
Edit:
Also, I always planned to support free (non-grid-snapped) positioning on the desktop, so using fixed (x,y) cell positions wouldn't work anymore.
As well for free positioning you somehow need to store the x/y coordinates of each icon. So I suppose that is not directly related to this issue.
I feel like we should look at what other DEs (and OSes) do here. I actually wonder if they handle this situation all that well either.
I wonder if we can sorta eliminate the idea of caring about resolution all that much, at least from the perspective of not storing resolution as a part of the config. This would apply to a single monitor changing resolutions, or even plugging in or removing secondary monitors, which may be different monitors at different resolutions. In the case where a "new" resolution is larger than the old, then we don't really do anything: icons stay in the same position. In the case where it's smaller than the old, icons that still have valid positions in the new size stay, and everything else gets repositioned to new, valid locations.
Ok, so then what happens if the resolution gets larger again? As you mention, maybe it does make sense to expect the icons to move back to the positions they were in when the setup was last in that larger resolution. But I could also see the argument for the opposite: the icons have already been repositioned somewhere else, so maybe it'd actually be confusing to see them move back?
I'm also a little uncertain about how to handle multi-monitor here. (I also kinda don't remember how all this currently behaves with more than one monitor, will need to test it out when my partner isn't using the second monitor in our office.) Does it even make sense to allow icons on the non-primary monitor? If someone puts icons on a secondary monitor, and then unplugs that monitor, we of course have to reposition those icons back on the primary monitor. But then does it actually logically follow that plugging that monitor in should move the icons back to the secondary monitor? Maybe, maybe not.
Again, I'm curious how other OSes/DEs handle this. Do they just move the icons back to the primary when the secondary is removed, and then keep them on the primary if the secondary is plugged back in? Do they even allow icons to be split between primary and secondary monitors? Or do they just duplicate the full set of icons on each monitor (and perhaps allow different per-monitor positioning for each icon)? I'm frankly having trouble guessing what user expectations would be here, or how users use desktop icons in multi-monitor setups.
I think I really just want to go back to the fundamentals and examine how this should work, completely ignoring the current behavior. Maybe our current behavior is the right thing to do (well, if we can fix the bugs), but maybe it isn't.
(Of course, if we do decide to change the behavior, I'm sure a bunch of existing users will be upset, and want it to be an option...)
You are right, it's probably a good idea to check how it is done for other desktops.
will need to test it out when my partner isn't using the second monitor in our office.)
We have alot of money on https://opencollective.com/xfce-eu and https://opencollective.com/xfce and dont know what to do with it 🙂 ... so if there is space left on your desk, best buy an additional monitor and submit an expense on the page to get it paid. (I plan to do the same when I have time to work on some high-res issues)
Regarding resolution changes:
As you said, if one plays with the resolution, it might happen that some icons dont fit in any more. So these probably should be repositioned. I think that is expected by users. (Though there are maybe better options .. see below)
Regarding unplug / plug additional monitors:
We currently support having icons on multiple monitors .. I dont think we should drop that feature (At least I think that would probably upset a good amount of users).
Here I have a personal story to tell 🙂 After carefully positioning all my desktop items into clusters cross both of my monitors (sometimes I am a bit pedantic), I had to unplug one of them for some reason which I do not remember. I bootet with a single monitor and gnah all my carefull icon positioning was gone :F
On the other hand, I can imagine that there are use-cases where it is desired to automatically reposition the icons ... e.g. if I want to permanetly remove a monitor.
I think a good solution for all that could be: Let the user decide what he wants to do, instead of presuming something !
E.g. how about a Notification: "Some desktop icons currently are not visible. Do you want to move them to the main monitor ? [yes] [no]" simnilar to this one from xfce4-power-manager.
so if there is space left on your desk, best buy an additional monitor and submit an expense on the page to get it paid.
Hehe, thanks for the offer, but it's not a matter of money... just of physical space, and my lack of desire for having so much stuff around :)
I think a good solution for all that could be: Let the user decide what he wants to do, instead of presuming something ! E.g. how about a Notification...
That could work, but I do worry about "notification fatigue" and people clicking through notifications just to dismiss them, without taking the time to understand what is being asked of them. A desktop environment should do its best to stay out of the user's way, not bother them with questions.
So yeah, my goal here would be to just "do the right thing". Sometimes the right thing isn't the same thing for everyone, and for those cases I think settings are fine.
After carefully positioning all my desktop items into clusters cross both of my monitors (sometimes I am a bit pedantic), I had to unplug one of them for some reason which I do not remember. I bootet with a single monitor and gnah all my carefull icon positioning was gone :F
Ok, ok, you've convinced me that we should try to preserve such meticulous layout work :D In all seriousness, I think the issue here is that it might not be intuitive to many people that removing (even temporarily) a monitor could be a "destructive" action that might undo some careful manual configuration work. You obviously immediately realized what had happened, but I suspect most people would not.
Going back to your prior comment about the case where someone changes the height of a panel by a few pixels, and that requires us to create a new configuration since technically that's a "resolution change"... I wonder if we can recognize these sorts of changes as somehow special and not important. Like, if I'm fiddling around with the panel settings, trying to find the exact height I want, once I'm done, I probably don't care about the icon settings for any intermediate "resolutions", or even the old resolution before I started tweaking the panel size. But switching screen resolutions might be a case where we want to preserve things. As an example from my own usage, I have a somewhat odd-sized HiDPI laptop screen, and I've settled on a convoluted scaling setup that (among other things) includes xrandr --output eDP-1 --scale 1.2x1.2. Unfortunately, I have to switch it back to 1x1 whenever I play some fullscreen games, as otherwise the resolution and input handling is all screwed up. So yeah, when I've switched to 1x1, xfdesktop should probably move any offscreen icons to valid locations, but when I switch back to 1.2x1.2, I definitely would want icons to go back to their original positions.
So anyway -- I wonder if maybe a simplifying bit of this would be to just discard prior configurations when the "resolution" changes due to struts or workarea, but keep configurations around for actual screen resolution changes and monitor plug/unplug. Not sure if that helps anything, though, or just makes things more complicated. I do wonder about multi-monitor setups, and if the configuration needs to track more than just the resolution. I guess in practice the resolution might be enough, since it "encodes" things like "this monitor is to the right of the other one" differently from "this monitor is above the other one". But I could maybe see a situation where the total resolution between two setups is the same, but the monitors are positioned relative to each other slightly differently, in a way that matters.
At any rate, I think I'm hitting the limits of the speculation I can do without some real-world testing, and re-familiarizing myself with how the code all works.
That could work, but I do worry about "notification fatigue" and people clicking through notifications just to dismiss them, without taking the time to understand what is being asked of them. A desktop environment should do its best to stay out of the user's way, not bother them with questions.
So yeah, my goal here would be to just "do the right thing". Sometimes the right thing isn't the same thing for everyone, and for those cases I think settings are fine.
Imo that sounds like a good use-case for some "do not ask again" checkbox 🙂 .Though not sure if that could be part of an notification or if we than would need some dialog instead. (A notification probably would be less distractive).
If the user wants to get missing icons later on, there is always the menu item "Arrange Desktop Icons" in the context menu.
As an example from my own usage, I have a somewhat odd-sized HiDPI laptop screen, and I've settled on a convoluted scaling setup that (among other things) includes xrandr --output eDP-1 --scale 1.2x1.2. Unfortunately, I have to switch it back to 1x1 whenever I play some fullscreen games, as otherwise the resolution and input handling is all screwed up. So yeah, when I've switched to 1x1, xfdesktop should probably move any offscreen icons to valid locations, but when I switch back to 1.2x1.2, I definitely would want icons to go back to their original positions.
I suppose we could use the same notification/dialog for screen resolution changes (just every time some icon cannot be displayed any more because it does not fit on the available space). When the resultion is back to normal, we could close pending notifications/dialogs.
I do wonder about multi-monitor setups, and if the configuration needs to track more than just the resolution. I guess in practice the resolution might be enough, since it "encodes" things like "this monitor is to the right of the other one" differently from "this monitor is above the other one". B
You are probably right ... having a grid per monitor would require rather deep changes, while at least now we dont see a clear benefit. So yea, lets rather not go for that change, in order to keep things simple.
So anyway -- I wonder if maybe a simplifying bit of this would be to just discard prior configurations when the "resolution" changes due to struts or workarea, but keep configurations around for actual screen resolution changes and monitor plug/unplug.
I am not sure if it will be possible to figure out the cause of a workarea size-change. Possibly that is not required: We actually just need to check if all icons still fit into the new workarea. Only if that is not the case, we need to do something about it (A dialog / auto-refit / new *.rc file)
At any rate, I think I'm hitting the limits of the speculation I can do without some real-world testing, and re-familiarizing myself with how the code all works.
Haha .. yea, that probably would help :D. I am as well not familar with the related code myself. Sorry, I dont want to force you to look into this issue ... If you like, I as well can take a try on a MR by the beginning of next year, after the 4.18 is done.
To me, it helps already alot to talk with someone else about it. Meanwhile I have a much more concrete picture on what is actually wrong and how it could be fixed.
Since there are actually two separate thing to further discuss, I opened #208 (closed) and #209 (closed) in favour of this one (which was rather missleading ... a port to xfconf actually is not required) .. hope it's fine for you like that @kelnos ?