(*** This bug was imported into bugs.kde.org ***) Package: kdesktop Version: KDE 3.0.7 CVS/CVSup/Snapshot Severity: normal Installed from: Compiled sources Compiler: gcc version 2.95.3 20010315 (release) OS: Linux (i686) release 2.4.19-pre10-gentoo-r3 OS/Compiler notes: Cosmetics only. To reproduce: 1. Run Kicker aligned to the top of the screen. Have some icons on the desktop. 2. Hide/Unhide Kicker and watch those icons jump! :) (Submitted via bugs.kde.org) (Called from KBugReport dialog. Fields Application KDE Version manually changed)
Hi Jens, this is no bug, this isa feature... If we won't rearrange the icons, I'm sure there will be enough bug reports, that wants it this way, because it would be a waste of space if not doing so... Ciao, Tobias
Subject: Re: desktop icons move when kicker is hidden/unhidden Two objections against closing this bug: 1. It flickers like hell (Really, plain ugly. First the nice animation with Kicker sliding away sidewards, and then icons jump, *FLICKER*). 2. I don't think there is any waste of screen space, since the additional space only exists, as long Kicker is hidden. What happens to icons at the bottom of the screen when Kicker is unhidden? Compare this to what happens when Kicker is located at the bottom of the screen. Any icon moved to the area that is usually covered by Kicker will be moved upward when Kicker is unhidden. So this area actually is unusable. No waste of screen space here? I don't think this would produce lots of new bug reports, since Kicker positioned at the top of the screen isn't the default, and only few people will notice this change at all. bye J
Tobias, Seriously.. you are joking, right? This is clearly a bug since, like J
I have the same problem: The icons wander down a step each time I log in, and this is really annoying to place each 4th time the icons again on top. At least fix the problem at login, but I guess it is easier to remove this unneeded feature.
I have my kicker on the left side of the screen, and each time I log in all the icons shift one step to the right, until they finally shift out of the visible area.
This is ridiculous, the icons actually move UP when you hide the kicker, even though if they are compensating for new space they should move DOWN.
The icons don't just move out of the way ,they shift around each time you hide/unhide kicker. I get to watch my trash bin dance its way up the screen. I'm getting tired of having to continually move it back DOWN where I want it. Feature? More like a pain!
I've getting the same behaviour (icons moving upwards after starting KDE or changing the position of the Kicker panel) since KDE 3.3.0. The fact that it only started back clearly shows that it's not a feature. Further, no one can really expect users to manually rearrange their desktop everytime they log in. This is highly annoying. Please fix.
> I've getting the same behaviour (icons moving upwards after starting KDE or changing the position of the Kicker panel) since KDE 3.3.0. The fact that it only started back clearly shows that it's not a feature. Further, no one can really expect users to manually rearrange their desktop everytime they log in. This is highly annoying. Please fix. We have already. This was fixed on 20-Sep-2004, in kdiconview.cc 1.132 and 1.126.2.3 (KDE_3_3_BRANCH) (bug report #82800) ... which means the fix is in KDE-3.3.1.
My upgrade to KDE 3.3.1 isn't fully complete as kdemultimedia and kdenetwork missing, but the relevant Debian packages (kwin - http://packages.debian.org/unstable/kde/kwin, kdesktop - http://packages.debian.org/unstable/kde/kdesktop, please correct me here if I'm wrong) are clearly 3.3.1. So either the bug is caused by some other package, or there is a packaging problem, or the bug presists. Thanks a lot for spending time on trivial stuff like this.
I have installed kde-3.3.1 on my Gentoo box and it seems to be fixed now. I think it depends on some other packages then.
OK, then it really seems to be a problem with the Debian packages. I'll bug them about it. Thanks for your time.
The fix is in kdesktop, this doesn't rely on another package. But maybe the debian package isn't really 3.3.1, dunno.
I've just upgraded to KDE 3.3.2 from Debian experimental (see http://lists.debian.org/debian-kde/2004/12/msg00150.html) and while most of the issues mentioned above are indeed fixed, the icons still do move up by one square on the "grid" each and every time I start KDE. Worth mentioning is that Kicker is on top of the screen and that Icons -> "Align to Grid" in the desktop RMB menu is checked. This really doesn't look like a Debian packaging problem. Can anybody reproduce this? (For the Debian side of things, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279993)
This bug STILL exists in the the KDE 3.4 preview packages for Debian. I moved my ~/.kde directory away to make sure it's not a configuration issue, and started KDE, then used all the default options in the setup wizard. All the icons on my desktop still dance around every time the kicker is hidden or unhidden. I even recorded a video of it using gvidcap, for anybody who still wants to mark this bug "closed": http://home.erin.utoronto.ca/~jbonham/kdesktop-bug.avi
Forgot to mention, I also made sure icon alignment was turned on. If icon alignment is turned off then this obviously doesn't happen.
This bug is present in KDE 3.4 with Gentoo. My kicker panel is at bottom. When kicker is minimized, _all_ icons in the desktop move up a little. When kicker is maximized, _only_ the icons in the upper half of the desktop move down to the original position: the icons in the lower half move up. At login the same thing (as if kicker is maximized) happens. The result is that I can't keep icons in the bottom half of the desktop. They slowly walk up...
Also here the bug is present, using KDE 3.4 and Gentoo
Please reopen this bug, it is obviously still in the code having been reported by separate users from separate distributions.
reopening then...
3.4 slackware 10.1 At each hide/unhide the bottom icons go one step up. This problem doesn't apear if the Configure Panel -> hiding -> Allow other windows to cover panel is enabled. It is really annoying that in the "Next generation computer gui" the icons don't stay in the place the user sets them. This is growing to a pain in the #$%^ ever since kde 3.2 If it is that hard make the code leave the icons in peace at least provide a lock setting that would make the icons stick in their place! This was one of the uglyest things in the 3.3 series and it should really have been fixed in 3.4 I mean it... you cannot exmplain to someone migrating from windows you know linux is better, it's more stable but you know ... the damn icons won't stay in their place no matter how hard you try... Please...please please do something about it!
I see no mention of any improvement in KDE 3.4.1 :( Aline to Grid has been a mess for it's users since 3.3 was released. There have been a number of bugs posted about the different problems it has caused, http://bugs.kde.org/show_bug.cgi?id=79932 http://bugs.kde.org/show_bug.cgi?id=94126 are just two. They are marked as resolved but clearly are not. If we could just go back to the pre 3.3 grid system most of these problems would be corrected. I was using the DesktopGridSpacing=x,y hack of the kdeglobals file to keep things reasonably set where I wanted them but the change in 3.4 to the kcontrol-background-advanced dialog system broke that as well. As user should be able to arrange icons where he likes them, click aline to grid to get them perfectly lined up and then just forget about it. They shouldn't get moved around every time he hides/unhides the task bar or logs out/in. Nor should the grid spacing for the icons put a huge gap vertically between the icons. Something needs to be done with the Aline to Grid system, Please. Sal
OK the description confused me for a long time. This isn't the same as the bug that was fixed in 3.3.1. That one was about handling workarea size changes. The new bug, though, is about the "auto-align" feature. The problem is that lineupIcons isn't idempotent, i.e. when being called more than once it moves the icons again, which obviously it shouldn't do. I was afraid of that when I saw the auto-align feature being added, which only exposes even more than before the lineupIcons deficiencies. lineupIcons is from Tim Jansen. Tim? Interesting in having a look at it again?
Sorry, I don't even have KDE installed anymore.
*** Bug 108258 has been marked as a duplicate of this bug. ***
They move not only when kicker hidden/unhidden, but everytime KDE starts and sometimes they can't find their previous location. The move not only up and down like when the kicker hidden/unhidden, but they also move from side to side for no reason. ------- Original message ------- From: owner@bugs.kde.org To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 28 Июнь 2005 16:00 [bugs.kde.org quoted mail]
Good to see that I'm not alone. But since the first bugreport is dated 2002-09-08, I doubt that the developers even made an attempt to fix it. Seems they simply like this icon freestyle movement at thats all. In GNOME the icons always stay where the users put them. Is it so hard to take a look at the GNOME's source codes. I know it use different engine, but maybe it will help a bit. I using Linux since KDE 3.1. but this bug still here in every distribution I've tried before (SuSE, Mandrake, Debian, Slackware, UHU, Fedora). ------- Original message ------- From: Serja <mekoc@inbox.ru> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 28 Июнь 2005 16:23 [bugs.kde.org quoted mail]
This is outrageous ! I mean it is something extremely simple: icons should NOT move by their will ! It's been like that since I saw Windows 3.0. I'm using linux since 98 - used window maker at first and then gnome for a while but never really liked it.(personal taste - no point flaming here). Kde has been a bless ever since version 2. But this is the most annoying thing I encountered in linux since I can remember ! Like in war - man should learn from the enemies ;) Experiment with how icons line up in windows (be that 98 2000 or XP - in any it happends corectly!), check out gnome sources - I mean watch ANY window manager. Until kde3 I never saw icons with their own will. Thank you for your time.
Is this bug present in KDE2? If not then maybe the developers should use the codes from KDE2 or find some bertayer from m$. Please fix it! Do something! It's very idiotic situation: the award winning desktop environment unable to make the icons obey to their masters (I mean KDE-users). I don't know, maybe the developers just develop, develop, develop and have no time to use their PC-s for everyday use and therefore they don't understand whats so annoying if the icons are dancing at the screen. But believe me, It's a very annoing thing for everyday use. ------- Original message ------- From: icebox <icebox@miv.directnet.ro> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 28 Июнь 2005 17:33 [bugs.kde.org quoted mail]
Please calm down instead of saying nonsense. Thanks. We know about the bug, and we are about to have a look at it. Our problem is among other things the fact that the author of the lineup-icons code isn't active anymore, so we have to take over that code, understand it, and bugfix it. Patience, OK?
Ok! I'm a patient man. But please remember that this bug present in KDE for years and was reported many times by different users. Please do not just close it again sometimes later like it was before without really fixing it. I'll be watching it. Thanks. ------- Original message ------- From: David Faure <faure@kde.org> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 28 Июнь 2005 19:07 [bugs.kde.org quoted mail]
I think if the kicker hidding/unhidding feature will be removed, it will help to fix this bug. If I understand it correctly the kicker hidding/unhidding feature was added because the windows are relatively often won't fit in to the screen. Maybe the bugfixing process should be started by fixing windows positions and not by simply reduce this bug with kicker hidding/unhidding, which may cause newer bugs. ------- Original message ------- From: icebox <icebox@miv.directnet.ro> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 28 Июнь 2005 17:33 [bugs.kde.org quoted mail]
It seems I've find the temporary solution how to avoid "icon jumping". in $HOME/.kde/share/apps/kdesktop there is a file called "IconPositions". If after placing all the icons you'll need on the desktop you block the access to this file by making it read-only, the icons won't jump anymore. Well it's true on 90%, because newer icon placement may cause "icon jumping" again. It seems some applications write to this file. Currently I use 1024x768 resolution, but if I open some application which use for example a lower resolution (e.g. 800x600), after closing this application the icons change their position. But if I made the "IconPositions" file read-only the applications can't write it and change the icons position. Disabling the panel hiding buttons may also help. I hope this information should help the developers.
I forgot to mention: before making this file read-only I've edited it manually by removing all lines which try to place the icons using a lower resolution than the default resolution. Here comes an example: [IconPosition::Home.desktop] X=21 X 800=value -- REMOVE THIS LINE!!!!! X 1024=21 Y=10 Y 600=value -- REMOVE THIS LINE!!!!! Y 768=10 ------- Original message ------- From: Serja <mekoc@inbox.ru> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 21 Июль 2005 11:46 [bugs.kde.org quoted mail]
*** Bug 98244 has been marked as a duplicate of this bug. ***
SVN commit 444002 by mkoller: BUG: 91575 BUG: 47627 Kicker now has the capability to tell kdesktop an area to place desktop icons in. This area is different from the workArea (which is used by windows/the window manager). The desktopIconsArea is not modified when a panel/extension is hidden/shown - only when a new panel/extension is created or an existing one is moved. M +5 -0 container_extension.cpp M +1 -0 container_extension.h M +81 -0 extensionmanager.cpp M +9 -0 extensionmanager.h M +16 -0 kicker.cpp M +7 -0 kicker.h --- branches/KDE/3.5/kdebase/kicker/kicker/core/container_extension.cpp #444001:444002 @@ -141,6 +141,9 @@ _layout->setRowStretch(1,10); _layout->setColStretch(1,10); + connect(this, SIGNAL(layoutUpdated(ExtensionContainer *)), + ExtensionManager::the(), SLOT(extensionSizeChanged(ExtensionContainer *))); + // instantiate the autohide timer _autohideTimer = new QTimer(this); connect(_autohideTimer, SIGNAL(timeout()), SLOT(autoHideTimeout())); @@ -542,6 +545,8 @@ // kdDebug(1210) << "PanelContainer::updateLayout()" << endl; resetLayout(); updateWindowManager(); + + emit layoutUpdated(this); } void ExtensionContainer::enableMouseOverEffects() --- branches/KDE/3.5/kdebase/kicker/kicker/core/container_extension.h #444001:444002 @@ -114,6 +114,7 @@ signals: void removeme(ExtensionContainer*); + void layoutUpdated(ExtensionContainer*); protected slots: virtual void showPanelMenu( const QPoint& pos ); --- branches/KDE/3.5/kdebase/kicker/kicker/core/extensionmanager.cpp #444001:444002 @@ -209,8 +209,11 @@ } else if (m_menubarPanel) { + int screen = m_menubarPanel->xineramaScreen(); delete m_menubarPanel; m_menubarPanel = 0; + + emit desktopIconsAreaChanged(desktopIconsArea(screen), screen); } } @@ -353,6 +356,9 @@ tmpmenu.insertItem("Aaron Seigo"); m_menubarPanel->setSize(KPanelExtension::SizeCustom, tmpmenu.sizeHint().height()); + + emit desktopIconsAreaChanged(desktopIconsArea(m_menubarPanel->xineramaScreen()), + m_menubarPanel->xineramaScreen()); } bool ExtensionManager::isMainPanel(const QWidget* panel) const @@ -397,6 +403,9 @@ connect(e, SIGNAL(removeme(ExtensionContainer*)), this, SLOT(removeContainer(ExtensionContainer*))); + + emit desktopIconsAreaChanged(desktopIconsArea(e->xineramaScreen()), + e->xineramaScreen()); } void ExtensionManager::removeContainer(ExtensionContainer* e) @@ -410,6 +419,9 @@ _containers.remove(e); e->deleteLater(); // Wait till we return to the main event loop saveContainerConfig(); + + emit desktopIconsAreaChanged(desktopIconsArea(e->xineramaScreen()), + e->xineramaScreen()); } void ExtensionManager::removeAllContainers() @@ -660,4 +672,73 @@ return m_panelCounter; } +void ExtensionManager::reduceArea(QRect &area, const ExtensionContainer *extension) const +{ + if (!extension) + { + return; + } + + // reduce given area (QRect) to the space not covered by the given extension + // As simplification: the length of the extension is not taken into account + // which means that even a small extension e.g. on the left side of the desktop + // will remove the available area with its with + + switch (extension->position()) + { + case KPanelExtension::Left: + { + area.setLeft(QMAX(area.left(), extension->frameGeometry().right())); + break; + } + case KPanelExtension::Right: + { + area.setRight(QMIN(area.right(), extension->frameGeometry().left())); + break; + } + case KPanelExtension::Top: + { + area.setTop(QMAX(area.top(), extension->frameGeometry().bottom())); + break; + } + case KPanelExtension::Bottom: + { + area.setBottom(QMIN(area.bottom(), extension->frameGeometry().top())); + break; + } + default: ; // ignore KPanelExtension::Floating ... at least for now + } +} + +QRect ExtensionManager::desktopIconsArea(int screen) const +{ + QRect area = QApplication::desktop()->screenGeometry(screen); + + reduceArea(area, m_mainPanel); + reduceArea(area, m_menubarPanel); + + for (ExtensionList::const_iterator it = _containers.constBegin(); + it != _containers.constEnd(); + ++it) + { + reduceArea(area, (*it)); + } + + kdDebug(1210) << "ExtensionManager::desktopIconsArea() = " << area + << " screen = " << screen << endl; + return area; +} + +void ExtensionManager::extensionSizeChanged(ExtensionContainer *extension) +{ + // we have to recalc the available space for desktop icons + if (!extension) + { + return; + } + + emit desktopIconsAreaChanged(desktopIconsArea(extension->xineramaScreen()), + extension->xineramaScreen()); +} + #include "extensionmanager.moc" --- branches/KDE/3.5/kdebase/kicker/kicker/core/extensionmanager.h #444001:444002 @@ -52,10 +52,18 @@ QRect workArea(int XineramaScreen, ExtensionContainer* container); int nextPanelOrder(); + // return the space available for all icons on the desktop + // subtracts all panels from XineramaScreen's geometry + QRect desktopIconsArea(int xineramaScreen) const; + public slots: void removeContainer( ExtensionContainer* ); void initialize(); + void extensionSizeChanged(ExtensionContainer *); +signals: + void desktopIconsAreaChanged(const QRect &, int xineramaScreen); + protected: friend class KStaticDeleter<ExtensionManager>; @@ -73,6 +81,7 @@ private: void migrateMenubar(); + void reduceArea(QRect &area, const ExtensionContainer *panel) const; ExtensionList _containers; ExtensionContainer* m_menubarPanel; --- branches/KDE/3.5/kdebase/kicker/kicker/core/kicker.cpp #444001:444002 @@ -145,6 +145,9 @@ // the panels, aka extensions QTimer::singleShot(0, ExtensionManager::the(), SLOT(initialize())); + + connect(ExtensionManager::the(), SIGNAL(desktopIconsAreaChanged(const QRect &, int)), + this, SLOT(slotDesktopIconsAreaChanged(const QRect &, int))); } Kicker::~Kicker() @@ -389,3 +392,16 @@ return m_kwinModule; } +QRect Kicker::desktopIconsArea(int screen) const +{ + return ExtensionManager::the()->desktopIconsArea(screen); +} + +void Kicker::slotDesktopIconsAreaChanged(const QRect &area, int screen) +{ + QByteArray params; + QDataStream stream(params, IO_WriteOnly); + stream << area; + stream << screen; + emitDCOPSignal("desktopIconsAreaChanged(QRect, int)", params); +} --- branches/KDE/3.5/kdebase/kicker/kicker/core/kicker.h #444001:444002 @@ -59,7 +59,13 @@ void showConfig(const QString& config, int page = -1); void showTaskBarConfig(); void configureMenubar(); + // return the region on the desktop, which is not covered by panels + // and therefore allowed to be used by icons placed on the desktop + QRect desktopIconsArea(int screen) const; +k_dcop_signals: + void desktopIconsAreaChanged(QRect area, int screen); + public: static Kicker* the(); KDirWatch* fileWatcher(); @@ -109,6 +115,7 @@ void slotDesktopResized(); void paletteChanged(); void setCrashHandler(); + void slotDesktopIconsAreaChanged(const QRect &area, int screen); private: static void crashHandler(int signal);
But this icon jumpung not only depends on kicker, because something else tell the icons that they should move. So is the codes you post here fix the icon jumping or this is a one more new option which may help and may not? ------- Original message ------- From: Martin Koller <m.koller@surfeu.at> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 8 Август 2005 12:21 [bugs.kde.org quoted mail]
On Monday 08 August 2005 15:02, Serja wrote: > ------- Additional Comments From mekoc inbox ru 2005-08-08 15:02 ------- > But this icon jumpung not only depends on kicker, because something else > tell the icons that they should move. > So is the codes you post here fix the icon jumping or this is a one more > new option which may help and may not? The mentioned bug is about "desktop icons move when kicker is hidden/unhidden" but you're right, there was another one https://bugs.kde.org/show_bug.cgi?id=91575 which was about what you said "Icons get rearranged on login". I also fixed this one in kdesktop.
wow, thats sounds great! thanks! ------- Original message ------- From: Martin Koller <m.koller@surfeu.at> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 8 Август 2005 16:08 [bugs.kde.org quoted mail]
And can this patch be applied against 3.4.0? ------- Original message ------- From: Martin Koller <m.koller@surfeu.at> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 8 Август 2005 12:21 [bugs.kde.org quoted mail]
On Tuesday 09 August 2005 08:27, Serja wrote: > And can this patch be applied against 3.4.0? Probably yes, I didn't try it and as I don't have a 3.4 workspace anymore, I won't do it. If you like, I can send you the patch files and you try it.
> If you like, I can send you the patch files and you try it. That would be nice. Thank you. ------- Original message ------- From: Martin Koller <m.koller@surfeu.at> To: mekoc@inbox.ru Subject: [Bug 47627] desktop icons move when kicker is hidden/unhidden Date: 9 Август 2005 10:51 [bugs.kde.org quoted mail]
Running Kde 3.5 beta 2 (3.4.92) and the bug is still present, although there is a workaround - enabling Lock in place. This must be one of the oldest and annoyng bugs I'm aware of... BTW 3.5beta2 looks and feels great - always a pleasure upgrading the software not the hardware to get more speed and features ;)
But I've told the developers that not only the kicker cause this bug, but the applications which use different resolution than the default one. Hey, KDE developers, please take a look at some other open source codes for desktop icons and fix this 3 years old bug! Please respect the users of your software - stop just adding new features without fixing old bugs.
On Thursday 03 November 2005 14:25, Serja wrote: > Hey, > KDE developers, please take a look at some other open source codes for > desktop icons and fix this 3 years old bug! Please respect the users of > your software - stop just adding new features without fixing old bugs. Serja, I can understand your frustration, but comments in this way don't help. I've fixed this bug in August this year to my best knowledge. If it still does not work for you, then please provide as much useful information as possible, so that I can try to reproduce and fix it. Otherwise please give only advice if you know what you are talking about. If you do know C++ programming, then you're free to have a look at the KDE source (or whatever other source you think might be appropriate) and fix the bug. If you think it helps to look at a complete different code to fix a particular problem in KDE, then you might also think you can drive a Formula-I car when you know how to drive a family car. Believe me, you can't!
Actually I don't have KDE 3.5, so can't give any usefull information about how this bug "work" in the latest version. I have only 3.3.X and 3.4.X versions, so I can explain how and when this bug appear in this versions: 1. Usually when I start KDE, but not always. 2. My daughter play full-screen games (gcompris, etc.) and some of those games use a lower resolution (for example 800X600) and the default is 1027X768. This also affect the icons, because they change their position, but IMHO this shouldn't happen. As I understand something write to the ~.kde/share/apps/kdesktop/IconPositions file and rearrange the icons according to the lower resolution of the full-screen application. And when the application is exited the icons are unable to rearrange themself back to their original place. 3. Probably something else too. That is why I've placed all the icons I need at the desktop and made this file read-only, so none of any applications can't write this file. It's look a quite stable workaround. And sorry for the previous post.
On Friday 04 November 2005 14:56, Serja wrote: > Actually I don't have KDE 3.5, so can't give any usefull information about > how this bug "work" in the latest version. Thanks, but as I said, the bug has already been fixed for 3.5. AFAIK I sent you a patch for 3.4. Did it work ? > And sorry for the previous post. ok.
Using a three week old svn checkout, I'm happy to report it works well now. Thanks! :) (I'm the original reporter)
>Using a three week old svn checkout, I'm happy to report it works > well now. Thanks! :) > > (I'm the original reporter) Is thats mean icebox was wrong? >>------- Additional Comments From icebox miv directnet ro 2005-11-03 09:41 >>------- Running Kde 3.5 beta 2 (3.4.92) and the bug is still present, >>although there is a workaround - enabling Lock in place. >> This must be one of the oldest and annoyng bugs I'm aware of... > Thanks, but as I said, the bug has already been fixed for 3.5. Is thats mean icebox was wrong? > AFAIK I sent you a patch for 3.4. > Did it work ? No, I'm not checked out the patch yet - I'm better gonna try to download 3.5 beta and check if out how this work. Is 3.5 beta2 is stable enough to run on a productivity desktop?
On Friday 04 November 2005 17:17, Serja wrote: > ------- You are receiving this mail because: ------- > No, I'm not checked out the patch yet - I'm better gonna try to download > 3.5 beta and check if out how this work. > Is 3.5 beta2 is stable enough to run on a productivity desktop? Yes, it's stable enough. I use it every day.
Ok, then I'm gonna download it today or tomorrow, install and check it out. > Yes, it's stable enough. I use it every day.
I've downloaded the KDE 3.5 beta2 packages for Slackware and have tested them a bit. For now I can confirm, that I didn't noticed any icon-jumping. Good work! Thanks! > > Yes, it's stable enough. I use it every day.
Just a quick FYI, have installed 3.5rc1 on a PCLinuxOS P.92t3 partition that is updated to full unstable branch with a 2.6.13-oci3 kernel. No issues or problems to report. For me a MAJOR cause of celebration here, for the first time in I don't remember how long it appears KDE finally has the bouncing desktop icons issue fixed! I can aline desktop icons anyway I want, log out and in, hide and unhide the taskbar and the icons stay where I put them. Woo Hoo. Thanks everyone that has worked so hard and long on these desktop icon problems! Sal
Yes, after about 1-2 week of testing KDE 3.5 beta2 I didn't noticed jumping icons. Again: great work! Champagne anyone? :)
Of note for this bug.. I have been experiencing some xinerama regressions since these corrections.. the screenshots in bug 111961 demonstrates 2 of the regressions.. one is explained in the bug report, the other is noticeable in this attachment (http://bugs.kde.org/attachment.cgi?id=12462&action=view) where the icons are overlapped by the top panel
Bug closed. Kdesktop is no more mantained.