Version: 1.1 (using KDE 3.0.8 (KDE 3.1 beta2)) Installed from: SuSE Compiler: gcc version 3.2 OS: Linux (i686) release 2.4.19-4GB In an already closed bug you argued that it is by design popping up at a seemingly random location. I propose the following: If there is no K-Button available choose a convenient default location ( for example lower left, where the K-Button is per default ) If there is one K-Button open it there If there are more K-Buttons ( which is most unlikely IMHO ) pick one, but pick always the same. It is really irritating seeing the menu pop up in different places everytime.
Currently it always opens in the middle of the screen.
*** Bug 50510 has been marked as a duplicate of this bug. ***
*** Bug 56882 has been marked as a duplicate of this bug. ***
it is really annoying that it appears close to the mouse pointer, and not nearby the KMenu button(if there is any) i think before 3.x series it worked good, but now it really sucks!
*** Bug has been marked as fixed ***.
Should be re-opened, since the fix was reverted: "Partial revert of previous commit since this was allegedly intended behavior: Alt-F1 pops up menu in middle of screen again." (http://lists.kde.org/?l=kde-cvs&m=106709727527477&w=2) I don't see why opening the menu in the middle of the screen should be the correct behavior when there is a kmenu-button.
> I don't see why opening the menu in the middle of the screen should be the correct behavior when there is a kmenu-button. I don't either. The shortcut is for opening the kmenu. The kmenu, physically is located in the kicker. If we hold down alt and a letter to open up an application's menu, does it open up where the current mouse cursor is? If it is a mouse based action, then sure, open up the kmenu where the cursor is (if you configure kdesktop to do this, for example) If the revertion isn't going to be reverted, then probably should be marked as WONTFIX.
I also support re-adding Waldo's changes, for the following reasons: 1) More room for menus to expand without having to overlap backwards, especially on smaller screens. Even on 1024x768 some of the first child popups open to the left because there's not enough room on the right; not to mention 800x600. 2) This is the same behaviour as actually clicking the button with the mouse (consistency) 3) I would contend that it's the expected behaviour (KDE 2.x; Win; every other menu that I know of barring context popups) http://lists.kde.org/?l=kde-usability&m=102076290713964&w=2
Reopening since the wish is still valid, considering changing severity to normal since the usability complications is pretty obvious (kmenu pop up in the middle of the screen while there is a kmenu button to which it is logically but no longer visually connected).
I also feel that This is very annoying, I want it on the bottom left side, as it used to be in kde 2.2. This is a bug not a feautre... It should not be in Wishlist category. Though this bugging feature can be allowed using configuration of kmenu/kpanel.
This is a really needed thing. The best would be a little Control Center dialog where you can change your option for menu ALT+F1.
I don't agree with the last comment. The "some people disagree about this, so let's just make it an option" way doesn't work - the Control Center already contains enough options that we don't want to create another option for something as trivial as this (IMHO). I totally agree with the original bug report: in the 99,999999% of use cases where there is exactly one K-button (which is the default), open the menu there. Otherwise, open it in the middle. I must admit that I can not see a reason why people would not want it to be that way? Why is popping up in the middle 'intended behavior'? Looking at the amount of votes for this bug, I would guess that quite a lot of people think this should be changed...
I want the menu open at the K Menu button ... somebody maybe wants an option!
>I want the menu open at the K Menu button So do I. At least if the K Menu is activated by ALT+F1, no menu item should be selected - so if I hit ALT+F1, then cursor up the last item will be selected or the first with cursor down, respectively.
In KDE 3.1.94 (Beta 2) the K Menu is also opened when the user presses the Tux-key (aka Windows-key), and then correctly placed under the K-Button. But with ALT+F1 it is still opened in the center of the screen.
CVS commit by aseigo: handle multiple kmenu buttons properly BUG:49601 M +2 -2 buttons/kbutton.cpp 1.21 M +44 -3 core/menumanager.cpp 1.4 M +6 -4 core/menumanager.h 1.3 M +2 -2 ui/service_mnu.cpp 1.89 M +1 -1 ui/service_mnu.h 1.35 --- kdebase/kicker/buttons/kbutton.cpp #1.20:1.21 @@ -43,5 +43,5 @@ KButton::KButton( QWidget* parent ) setPopup(MenuManager::the()->kmenu()); - MenuManager::the()->setKButton(this); + MenuManager::the()->registerKButton(this); setIcon("kmenu"); } @@ -49,5 +49,5 @@ KButton::KButton( QWidget* parent ) KButton::~KButton() { - MenuManager::the()->setKButton(0); + MenuManager::the()->unregisterKButton(this); } --- kdebase/kicker/ui/service_mnu.cpp #1.88:1.89 @@ -419,6 +419,6 @@ void PanelServiceMenu::activateParent(co else { - PanelPopupButton *kButton = MenuManager::the()->KButton(); - if (kButton && (kButton->popup() == this)) + PanelPopupButton *kButton = MenuManager::the()->findKButtonFor(this); + if (kButton) { adjustSize(); --- kdebase/kicker/ui/service_mnu.h #1.34:1.35 @@ -44,5 +44,5 @@ typedef QMap<int, KSycocaEntry::Ptr> Ent typedef QPtrList<QPopupMenu> PopupMenuList; -class PanelServiceMenu : public KPanelMenu +class KDE_EXPORT PanelServiceMenu : public KPanelMenu { Q_OBJECT --- kdebase/kicker/core/menumanager.h #1.2:1.3 @@ -32,4 +32,6 @@ class KickerClientMenu; class PanelPopupButton; +typedef QPtrList<PanelPopupButton> KButtonList; + /** * The factory for menus created by other applications. Also the owner of these menus. @@ -53,7 +55,7 @@ public: void popupKMenu(const QPoint &p); - // TODO: this is totally unuseful for multiple KMenu buttons - void setKButton(PanelPopupButton *button) { m_kbutton = button; } - PanelPopupButton* KButton() { return m_kbutton; } + void registerKButton(PanelPopupButton *button); + void unregisterKButton(PanelPopupButton *button); + PanelPopupButton* findKButtonFor(QPopupMenu* menu); public slots: @@ -73,5 +75,5 @@ private: static MenuManager* m_self; - PanelPopupButton* m_kbutton; + KButtonList m_kbuttons; }; --- kdebase/kicker/core/menumanager.cpp #1.3:1.4 @@ -29,7 +29,9 @@ CONNECTION WITH THE SOFTWARE OR THE USE #include <dcopclient.h> +#include "client_mnu.h" +#include "global.h" #include "k_mnu.h" #include "kicker.h" -#include "client_mnu.h" +#include "panelbutton.h" #include "menumanager.h" @@ -90,4 +92,33 @@ void MenuManager::popupKMenu(const QPoin } +void MenuManager::registerKButton(PanelPopupButton *button) +{ + if (!button) + { + return; + } + + m_kbuttons.append(button); +} + +void MenuManager::unregisterKButton(PanelPopupButton *button) +{ + m_kbuttons.remove(button); +} + +PanelPopupButton* MenuManager::findKButtonFor(QPopupMenu* menu) +{ + KButtonList::const_iterator itEnd = m_kbuttons.end(); + for (KButtonList::const_iterator it = m_kbuttons.begin(); it != itEnd; ++it) + { + if ((*it)->popup() == menu) + { + return *it; + } + } + + return 0; +} + void MenuManager::kmenuAccelActivated() { @@ -95,8 +126,12 @@ void MenuManager::kmenuAccelActivated() { m_kmenu->hide(); + return; } - else - { + m_kmenu->initialize(); + + if (m_kbuttons.isEmpty()) + { + // no button to use, make it behave like a desktop menu QPoint p; // Popup the K-menu at the center of the screen. @@ -113,4 +148,10 @@ void MenuManager::kmenuAccelActivated() QTimer::singleShot(0, this, SLOT(slotSetKMenuItemActive())); } + else + { + PanelPopupButton* button = m_kbuttons.at(0); + m_kmenu->popup(popupPosition(button->popupDirection(), + m_kmenu, button)); + } }