Version: (using KDE KDE 3.3.0) Installed from: Compiled From Sources move the kmenu to the right run "kicker -reverse" press the windows key *only* the first time, the kmenu will be showed in the wrong location. the next times the kmenu will be opened in the correct location
i followed your description precisely, and this works in CVS HEAD properly =) this could well be due to the fact that we now use QLayouts in kicker rather than do it all by hand (which was error prone)
I can still see this bus in CVS HEAD. I quited kicker (dcop kicker MainApplication-Interface quit), then deleted all config files for kicker (rm -f ~/.kde/share/config/kickerrc) and then restarted kicker. Still happens.
i can still see this bug in currect CVS
CVS commit by nikolaus: Set the correct kmenu position, if we use a keyboard shortcut and if it wasn't shown before. BUG: 89890 M +6 -0 menumanager.cpp 1.5 --- kdebase/kicker/core/menumanager.cpp #1.4:1.5 @@ -150,4 +150,10 @@ void MenuManager::kmenuAccelActivated() else { + // We need the kmenu's size to place it at the right position. + // We cannot rely on the popup menu's current size(), if it wasn't + // shown before, so we resize it here according to its sizeHint(). + const QSize size = m_kmenu->sizeHint(); + m_kmenu->resize(size.width(),size.height()); + PanelPopupButton* button = m_kbuttons.at(0); m_kmenu->popup(popupPosition(button->popupDirection(),
actually it does not. Not with keyboard and not with the mouse. I still get the menu in the other side. I tested it also with -reversed (or --reversed) on LTR desktops and still I see the bug. __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Yes, the bug is still there. The previous commit didn't change anything. The problem is probably in share/global.cpp, in popupPosition(): --8<-- case( KPanelApplet::Up ): return QApplication::reverseLayout() ? QPoint( r.right() - popup->width() - (r.width() - p.x()) + 1, r.top() - popup->height() ) : QPoint( r.left() + p.x(), r.top() - popup->height() ); --8<-- When in an RTL layout, we rely on the menu's width to display it in the right location, but its width isn't set right the first time it's displayed. There's our problem...
Okay, the original report stated that the misplacement occured after pressing the window key. I have followed the description and could confirm that. With the patch this behaviour is corrected. Now, the misplacement should occur on both, mouse and key activation. I can't confirm that. I suppose the steps to reproduce should be the same, shouldn't they? To #6: For key activation the kmenu's size is initialized before the popupPosition calculation, introduced by the shown patch. You blame the width for the problem. Is the kmenu shown the first time near the correct position and is only shifted horizontally?
http://bugs.kde.org/attachment.cgi?id=9419&action=view Just a guess: Does this picture show the problem?
The misplacement seems to occur regardless of the way the kmenu is brought up the first time. You can even issue 'dcop kicker kicker showKMenu'... The menu is shown at the right height, but it is at the far left edge of the screen, instead of above the k-button, which I have on the right in RTL mode. As to your screenshot, that seems to be it. I also get it when the panel's horizontal and the k-button's on the right. Did you get it this way with 'kicker --reverse' or without?
*** Bug 98326 has been marked as a duplicate of this bug. ***
It seems that I've misinterpreted the original post and stumbled over another issue, which is solved by my patch. I should switch my brain to fuzzy logic mode while reading bug reports. ;-) The reporters of the closed bug are using Gentoo 3.3.5-r1 and Fedora Core 3. I use SuSE 9.0. Which distribution do you use? Maybe this problem has something to do with the kmenu-patch for Qt living in qt-copy. I know that it is applied by SuSE in their packages. The screenshot was taken from the closed bug report.
I use qt-copy from CVS (quite outdated I need to admit), but I still see the problem. As Meni sayd, the problem accurs no matter how you open the k-menu. I will update qt-copy and report back. IMHO, if qt3.3.4 has a bug, hack arround it. I guess the trolls will not release a new version until Qt 4. __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
I've just compiled qt-copy (04.02.2005). Without the 0047-fix-kmenu-width.diff patch I can see the described behaviour in reverse mode. Applying this patch solves the problem for me.
Ok, I am using qt-copy and kde-cvs. I still see the bug... am I missing something? __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
I have reconfigured kdelibs and kdebase after applying the patches and the build of qt-copy, because the Qt directory changed on my system. After that I have compiled kdelibs/kdeui and kdebase/kicker again. That's maybe superflous, because the patch(es) does/do not break BC. Have you applied the patch(es)?
me? not. which patch are we talking about again? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
qt-copy/patches/0047-fix-kmenu-width.diff
cuco: It would be nice, if you could state wether it works for you with the applied patches. I don't want to close it again while it does not work for you. You can can apply all of the patches by calling ./apply_patches in your qt-copy directory. Or only the relevant one with patch -p0 < patches/0047-fix-kmenu-width.diff
be patient, i am a sttudent, on exams time... and I managed to complete qt locally, since I trying patching it in a way that it did not compile (nothing related to this patch). dont worry, i will try it... :) __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
it's been confirmed. it's the 0047-fix-kmenu-width.diff patch that must be applied. it's a Qt bug, and there's a fix for it.
*** Bug 102335 has been marked as a duplicate of this bug. ***
Just a note for any Gentoo users. You need to be running at least qt-3.3.4-r3 from portage to fix this problem. The 0047-fix-kmenu-width.diff is included in this version.
Well it's been some time since I came across this bug and I've been avidly waiting for Fedora to include appropriate KDE updates with the promised fix. I can now report that after upgrading to FC4, which included KDE 3.4.0, and subsequently updating to KDE 3.4.2, that this problem is not fixed for me. :-(
Ah haha - the folks at Fedora had not yet pushed that update into their queue. I finally got it today and the menu panel works just fine (in all 4 locations) !!! Thanx for fixing this!