Bug 106096

and at which point, exactly, do we end up with too much uneccessary configuration? kicker already probably has 2 features for everyone one in the GUI config and this rapidly leads to configuration insanity. the current clock, for instance, is not only a huge beast in terms of resources and performance, but it is also pretty much completely unmaintainable because every whim of a feature that anyone could think of was added.

code path upon code path until it's a mess.

so... how necessary is this feature, really?
also note that this value is used by more than just the kmenu, but by many other menus in kicker now.

i'm going to leave the decision for now up to you, so i'd like you to consider the implications and the true value of the requested feature.

*** This bug has been confirmed by popular vote. ***

http://www.kde-apps.org/content/show.php?content=26424

Dear Aaron J., this feature is popular, and I love the advantages it brings. Like: Easy to see icons; easy to hover menus and submenus, and good appearing submenus with different sizes. This feature IMHO is not an insane wish. Please consider implementing it. 

a) i'm not impressed with vote spamming and have no desire to encourage it by rewarding it with action

b) if someone provides a patch that works and is of the required quality (which is well defined in kdebase/kicker/HACKING) then i will see about committing it for 3.5

hey, aaron, maybe just make this default? bigger icons for the 'base' menu, and smaller for the sub menu's. i agree with Mohd Asif Ali Rizwaan it is more usable. of course, it might be configurable in the kickerrc so distributions and advanced users can change it... but it won't add clutter, and make the Kmenu a bit more usable.

> but it won't add clutter

only in the code =)

I was looking for precisely this option when upgrading my dad's KDE box recently.  

*** This bug has been confirmed by popular vote. ***

..

*** This bug has been confirmed by popular vote. ***

Nice idea and I approve of the look, but I understand the concerns of 'too complex' etc. from Aaron

And another point. Wouldn't the height also have to take account of the # of items in the menu and the vertical screen resolution, otherwise it's possible to end up with a menu taller than the screen! (Unless the code already prevents this of course).

This said... maybe a small/medium/large is enough - kinda like the tiny/small/medium/large/xlarge for the kicker?

I tried bigger icons in the KMenu and it does not fit on the screen (1024x768). I must admit that I also have the most recently used apps in the menu.

This problem might be solved by re-organizing the KMenu: Create one entry called 'Applications' in the KMenu, and put all app categories in there. That really looks a lot cleaner, is easier to navigate (IMHO) and it fits easily, even with huge icons.

It`s a good idea. but i would not need another option for the submenus (there are just 1 or 2 submenu levels anyway in menus). quick browser icons are small by default and you can't change their size, can you, that's ok, too. but the menus to access the programs should really contain bigger icons. it's a better look and feel.

please code it, at least the configuration option for icon size in menus.

Created attachment 12402 [details]
kdebase-3.4.2-SubMenuEntryHeight.patch

(In reply to comment #5)
> b) if someone provides a patch that works and is of the required quality
(which 
> is well defined in kdebase/kicker/HACKING) then i will see about committing
it 
> for 3.5

Here is the SubMenuEntryHeight patch for KDE 3.4.2, if you are interested i can
try to implement against 3.5

Forget this patch, this cannot handle all situations :(

Kicker is currently unmaintained, you can look to your distribution for help, however.