! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Desktop icons rearrange themselves after reboot.
Status:
RESOLVED: MOVED
Product:
Xfdesktop
Component:
General

Comments

Description Piotr 2020-02-04 19:26:01 CET
Created attachment 9426 
temporary patch for desperate people

Hi.

Desktop icons bug is still present.
https://wiki.archlinux.org/index.php/xf … themselves
Solution from the link above does not work for me.

I have an idea how to fix it.
Write icons positions to a file ONLY(!!!) when user moves icon by mouse or by clicking autoplacement (sorry, don't remember english name for this function).

xfdesktop4-4.14.1 from xubuntu 19.10
Intel graphic card.
XFCE with single panel on the bottom.

Best regards
Piotr
Comment 1 alexxcons editbugs 2020-02-04 21:55:56 CET
(In reply to Piotr from comment #0)
> Created attachment 9426 
> I have an idea how to fix it.
> Write icons positions to a file ONLY(!!!) when user moves icon by mouse or
> by clicking autoplacement (sorry, don't remember english name for this
> function).

This would not solve a setup where you e.g. have a dockable laptop as monitor extension.
As well your grid would get messed up badly on a dual screen setup, if one screen is unpluged.

I would rather go for the "one icon grid per monitor id" solution .. specially since we already have per monitor (and per workspace) settings in xfconf.
I opened a bug for it a while ago .. though currently I dont have time to work on it: Bug #15344
Comment 2 Piotr 2020-02-04 22:43:03 CET
> This would not solve a setup where you e.g. have a dockable laptop as
> monitor extension.
> As well your grid would get messed up badly on a dual screen setup, if one
> screen is unpluged.

Why?
How is that related to saving positions?
It should not matter. If user not move icons on new desktop there will be mess anyway.
Comment 3 alexxcons editbugs 2020-02-05 00:39:58 CET
(In reply to Piotr from comment #2)
> > This would not solve a setup where you e.g. have a dockable laptop as
> > monitor extension.
> > As well your grid would get messed up badly on a dual screen setup, if one
> > screen is unpluged.
> 
> Why?
> How is that related to saving positions?
> It should not matter. If user not move icons on new desktop there will be
> mess anyway.
You have a icon grid for two monitors (A and B) saved in a file. Now you reboot with only one monitor connected .

You have the choice between:
A: (Current behavior): Shrink the grid, reposition the icons automatically, save as new setting for that workspace size
B: (Your proposal) Shrink the grid, reposition the icons automatically, overwrite old setting. Setup for two monitors is lost.
C: (Proposal Bug #15344) There is a grid per monitor .. just dont use the grid info for monitor B, since it is not connected.
D: Keep the old grid, dont show the items of monitor B. This would require manually setting the grid size, since xfdesktop cannot know if you possibly want to permanently remove a monitor. 

Afterwards you reboot again with both monitors connected. (Thats more or less the scenario for a dockable laptop).

Note that there is a similar problem with setting a lower resolution .. once you did it, your grid will be messed up if you dont store your grid per resolution.
Comment 4 Piotr 2020-02-05 10:02:24 CET
You misunderstood my idea.
Nothing should be overwritten. New setup will be saved to a new file ONLY when user move icons. Not at random moments like now.
I don't care about file format so you can modify this whatever You like, as long as it works.

My proposal is only about when save, not where and how.
Save positions ONLY when USER move icons. That's it.

I think now some race condition occurs and that make a mess with icons. But that's just a guess.
Comment 5 alexxcons editbugs 2020-02-06 10:16:16 CET
(In reply to Piotr from comment #4)
> You misunderstood my idea.
> Nothing should be overwritten. New setup will be saved to a new file ONLY
> when user move icons. Not at random moments like now.
> I don't care about file format so you can modify this whatever You like, as
> long as it works.
> 
> My proposal is only about when save, not where and how.
> Save positions ONLY when USER move icons. That's it.
Ok, thanks for clarification!  However you still need to think what would be the consequence on the mentioned scenarios. It is possible to do like you proposed, though you concept currently seems to be incomplete.

Lets just go through different scenarios having your proposal in mind.
Lets assume we have grid full of icons defined in our *.rc file, icon size 44px: Resolution 1024x768 and a single xfce4-panel which is 30px thick. This would result in a "workarea" of 1024x738px and, possibly something like a 12x10 icon grid

1. Increase resolution. Eg 1024x768 -->1920×1080 (FullHD)
No problem on that. We need to expand the available grid to e.g. 14x12, but we can draw the old items.

2. Decrease resolution:   Eg 1024x768 -->800x600 (e.g. use the fallback monitor)
- if we keep the icon sizes and distances, our grid will shrink to e.g. 10x8. Some items cannot be drawn.
- we could think about automatically shrinking the icon-size, e.g. to 32px, or the distance between icons, so that we still can draw our full grid.

3. Add a new monitor
No problem on that. We need to expand the available grid to e.g. 28x12, but we can draw the old items.

4. Remove the new monitor
We will not see any of the items we placed on  the new monitor .. same than the current behavior, (*.rc file for theold resolution is loaded) so I assume it should be fine.

5. Decrease Panel Size
Nothing special here, same as 1.

6. Increase Panel Size
Same as 2. either dont draw some of the icons, or shrink all of them
(Actually I think the current concept of "workarea" is real bad ... thats one of the reasons why I opened Bug #15344 ... I would just draw all the icons, no matter how thick the panel is, even if a panel is drawn on top of some icons .. users can sort that out on thair own)

A have to admit, that for the most usecases your approach looks good.
So the question would be, in your proposal, how you want to proceed with items which would fall off the screen ? You plan to display a shrinked grid ? Or just dont draw them ?

The-use case which could cause trouble is 2. ...e g. if your monitor broke, and your fallback monitor has a lower res .. than you would need to recover missing items by editing the *.rc file .. though that is realy a connercase.
If its only about choosing a lower res. ,than I guess it is apppropriate that the user goes back to the old res and re-places missing icons by hand.

> I think now some race condition occurs and that make a mess with icons. But
> that's just a guess.
Yes, for sure there is some problem with the current logic ... they question is, what would be the best approach for the future.
Comment 6 alexxcons editbugs 2020-02-06 11:23:49 CET
> Write icons positions to a file ONLY(!!!) when user moves icon by mouse or by clicking autoplacement (sorry, don't remember english name for this function).
Sorry, I missed the "autoplacement" part ... so yes, that would resolve as well (2.)  You would suggest a button in the configuration/symbols tab to launch auto-placement ?  

.. when dou you plan to start working on it ?  :)
( xfce lacks maintainers ... actually I am the thunar maintainer, afaik xfdesktop is unmaintained. If you want to have it in reasonable time, you will need to help )
Comment 7 Piotr 2020-02-06 11:43:44 CET
> 4. Remove the new monitor
> We will not see any of the items we placed on  the new monitor .. same than
> the current behavior, (*.rc file for theold resolution is loaded) so I
> assume it should be fine.

> So the question would be, in your proposal, how you want to proceed with items which would fall off the screen ?
> You plan to display a shrinked grid ? Or just dont draw them ?

Settings should be per configuration of monitors.
If user disconnect second display, settings for only one display should be loaded.
If there is no settings for single display, xfdesktop can copy last settings for this display (or maybe from display called "MAIN" ?).
If there are new icons and we have free space, icons should be auto placed there.
If no free space, don't display new icons or shrink grid like You proposed (let user choose).
If user disconnect >=3 display, icons should be moved  to main, and when no free space to second.....
You don't need to save new positions until user moves icon.


> The-use case which could cause trouble is 2. ...e g. if your monitor broke, and your fallback monitor has a lower res .. 
> than you would need to recover missing items by editing the *.rc file .. though that is realy a connercase.

It's not about saving, it's about loading, and probably without good answer.
Some users probably will be OK with alphabetic order, some prefer grid shrink, others cut what's fit.
Fortunately, this does not happen often.
If user moves icon on this smaller monitor, settings should be saved in new file.

Ooooo, and I have another idea.
New icons could be placed on right (maybe an option for left/right?) for easy placing on the left.
You don't have to move them first to the right to make a space.
Comment 8 Piotr 2020-02-06 11:57:07 CET
>You would suggest a button in the configuration/symbols tab to
> launch auto-placement ?  

No, I was talking about option between "search" and "desktop settings" in desktop menu.
Sorry, I don't know the name. I don't use english XFCE.


> .. when dou you plan to start working on it ?  :)

Hehe, No... Sorry... I only deal with microcontrollers and console stuff.
Comment 9 Git Bot editbugs 2020-05-26 00:34:31 CEST
-- 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/xfdesktop/-/issues/58.

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

Bug #16425

Reported by:
Piotr
Reported on: 2020-02-04
Last modified on: 2020-05-26

People

Assignee:
Xfce Bug Triage
CC List:
1 user

Version

Version:
4.14.1

Attachments

Additional information