Version: (using KDE Devel) Installed from: Compiled sources OS: Linux In desktop selecting right click mouse and then selecting icons->Align to Grid, then the icons are organized, but each time i logout/login the icons apepar in a different place when at some point the icons form a triangule in the left upper corner, but all this can be viewed with 2 snapshots that i will attach.
Created attachment 20749 [details] desktop snapshot when selecting option "Align to Grid" This is a desktop snapshot that shows icons after clicking with right mouse click in desktop "Icons"-> "Align to Grid", where icons appear like they should.
Created attachment 20750 [details] desktop snapshot after some reboots This desktop snapshot shows how icons were modified after some reboots, and this should never happened. it can be easily see that the icons are forming a triangule from the upper right corner, so why where the icons changing place just because the desktop icons option "Align to Grid" was select?!
Duplication of bug 138296?
Being a duplicate or not, what matters is that when the option "Align to Grid" is selected, the icons after a reboot change place and this is very annoying when you want to have your desktop arranged.
I understand it is annoying, no need to stress that. I'd like an answer to the question instead.
Doesnt seam to be a duplicate, he doesnt make any reference to option "Align to Grid" that is what causes the bad behaviour of desktop icons.
I guess this is a duplicate of a bug that is said to be RESOLVED, but its NOT, so I created a patch (along with other tweaks) for openSUSE 10.2: http://www.kde-apps.org/content/show.php/openSUSE+KDE+Tweaks?content=59337
> I guess this is a duplicate of a bug that is said to be RESOLVED, but its NOT, so I created a patch (along with other tweaks) for openSUSE 10.2: http://www.kde-apps.org/content/show.php/openSUSE+KDE+Tweaks?content=59337 Thanks for submitting the patch here (I don't monitor kde-look), but that patch has a number of problems. - m_pDesktop->iconView()->setAutoAlign( KDesktopSettings::autoLineUpIcons() ); + bool startup = true; m_pDesktop->iconView()->setAutoAlign( KDesktopSettings::autoLineUpIcons() ); This defines a local variable, which is not used. in krootwm.h: + bool startup; This defines a member variable, which is not initialized (so your patch has random behavior) The kdiconview.cc gives a hint about what the problem might be, though, so I came up with the attached patch; can you give it a try? Thanks. The call to lineUpIcons in updateWorkArea() remains (your patch had removed it, but it's needed in case of work area size change, like when moving kicker around). Is the problem that it's called before there's any icons? We could test for that. Created an attachment (id=20782) kdesktop.diff
The patch you have attached isnt giving much improvements, i have aligned icons in desktop and activated option "Align to Grid" but after 2 reboots i have 2 icons out of the original place, but ill attach 2 screenshots for a better understanding.
Created attachment 20787 [details] desktop with icons aligned desktop with icons aligned
Created attachment 20788 [details] desktop icons after 2 reboots desktop icons after 2 reboots
Thanks for checking out the patch at kde-looks. From the problem you have found in my patch I guess it is obvious how "well" I understand C++ :-) But I have not observed unexpected behaviour (I guess uninitialized bool variables tend to be automatically set to FALSE?). I have downloaded your modifications and I will try it today. What I think the problem is (that I have tried to solve with my patch) that the icons get realigned (I think the grid is changed) whenever the desktop size changes due to kicker. On my setup the kdesktop loads before kicker (when logging in), and when the desktop size changes due to kicker, the icons are realigned to the new grid. This effect can be reproduced by killing and restarting kdesktop. IMO changing the grid size/position should occur only after a certain % of change and not when moving around kicker.
I have to correct something in the previous comment: This effect can be reproduced by killing and restarting kicker...
On Wednesday 06 June 2007, Bartha Istvan wrote: > But I have not observed unexpected behaviour (I guess uninitialized bool variables tend to be automatically set to FALSE?). No they don't. They point to uninitialized memory, which could be anything (and usually is random indeed). Actually, with a bool, you have more changes of getting TRUE (anything non 0) than FALSE (0). > I have downloaded your modifications and I will try it today. > What I think the problem is (that I have tried to solve with my patch) that the > icons get realigned (I think the grid is changed) whenever the desktop size changes due to kicker. I see. > On my setup the kdesktop loads before kicker (when logging in), and when the desktop size > changes due to kicker, the icons are realigned to the new grid. This effect can be reproduced by > killing and restarting kdesktop. IMO changing the grid size/position should occur only after a certain > % of change and not when moving around kicker. Well, what if you move kicker to an area where there are icons? Surely they need to move out from under kicker so that they are not covered by it. From what you say: 1) my patch is not enough (although it's still a good half-fix ;) 2) we should indeed listen to workarea changes only after the startup sequence is complete. For this a "bool startup" is not enough, since the workarea change signal from kicker happens some time after kdesktop startup... We could wait for the first workarea change signal and eat that one (but I'm not sure we only get one?). Or we could do this time-based. Or waiting for kicker's dcop registration (but that might be too early still). Or simply waiting for the end of the startup sequence (like ksplash gets notified, too). I need someone who knows workarea stuff and the startup sequence better :) Lubos? PS: do you want to add yourself to the CC list of this bug, to make sure not to miss emails?
The thing in the upper right corner, that is another Kicker panel, right? Does removing it affect this bugreport in any way?
Has nothing to do with the desktop icons behaviour.
Bingo! That was the right question. When Lubos asked Ze about the second panel on his screenshot, I realized that I have a second panel, too just that it is revealed only when the mouse is at the Bottom Right Corner. At home I have created a second user with the same settings as the normal one, and did not experience the random position effect until I had set up the 2nd autohiding panel. So the icons behave correctly until I set up more then one panel (autohiding or not). Rather than trying to make kdesktop adapt to the behaviour of kicker I have left kdesktop unmodified and patched kicker this time. readConfig() is called for each panel which calls actuallyUpdateLayout(); -> resetLayout(); ->extensionSizeChanged(); which then emits the desktopIconsAreaChanged signal for kdesktop. Avoiding to call resetLayout() a couple of times almost solved the problem, but this is not the best way to go, since it worked only for up to 2 panels. I think the best approach would be to avoid any call to extensionSizeChanged(); until the panels are completely loaded. I have tried to implement a timer for this but failed. What is your opinion? PS: I did try David's patch but the problem remained. I do get the emails (2 for each comment), but I am close to the net only once or twice a day on a windows machine
I don't understand why desktop size changes should affect this in any way. The icons should be in the same position (in absolute screen coordinates), so even panels (dis)appearing or desktop sizes should at most push all icons into some stable area that's always there, but shouldn't affect their position in that area. Perhaps the locations are done instead in relative positions (to workarea or whatever)? If yes then I think it should not be that way.
Please consider marking this a duplicate of Bug #118385 which has quite good description, more votes and attention. (and was posted before this)
As requested, thanks. *** This bug has been marked as a duplicate of 118385 ***
Bug closed. Kdesktop is no more mantained.