Bug 152052 - make kickoff freely resizable
Summary: make kickoff freely resizable
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Unclassified
Component: widget-kickoff (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist with 36 votes (vote)
Target Milestone: ---
Assignee: Stephan Binner
URL:
Keywords:
: 154104 158203 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-09 15:38 UTC by Thibaut Cousin
Modified: 2008-12-29 13:00 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Kmenu too small (128.14 KB, image/png)
2008-12-26 21:01 UTC, Dotan Cohen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thibaut Cousin 2007-11-09 15:38:46 UTC
Version:            (using KDE KDE 3.95.0)
OS:                Linux

In KDE3, Kickoff was resizable and this was very convinient. In KDE4 (3.95.2), I can't find any handle to resize it, so I'm always scrolling and scrolling to reach menu entries that I'm looking for...

Will Kickoff be resizable (at least in height) in KDE 4.0?
Comment 1 Aaron J. Seigo 2007-11-26 18:30:11 UTC
eventually, yes. not sure about 4.0. we'll see.
Comment 2 Jason Stubbs 2007-12-15 16:52:35 UTC
*** Bug 154104 has been marked as a duplicate of this bug. ***
Comment 3 Sebastian Sauer 2007-12-16 21:04:28 UTC
commit r749204 does introduce an option to define how much items should be displayed what in turn defines the height. So, the wish is solved :)
Comment 4 Robert Knight 2007-12-16 21:47:02 UTC
> commit r749204 does introduce an option to define how 
> much items should be displayed what in turn defines the height

> So, the wish is solved :) 

Not really, a spinbox is a somewhat cumbersome way to manage the visual size of something.  I think a resizing grip would be much easier to work with if you have the time to implement it.  


Comment 5 Sebastian Sauer 2007-12-16 21:58:05 UTC
Hi Robert,

yes, I was thinking of a grip as well, but;
* it should be enabled only if "lock widgets" is disabled
* it needs to work in the different directions
* I am not sure, if it's easier then to just allow to define the numbers of displayed items.

so, myself doesn't really see the need to implement a grip atm. Maybe something for past 4.0 ? Maybe change the bugreport into a "reminder" then?
Comment 6 S. Burmeister 2007-12-16 22:34:17 UTC
opensuse uses a grip and it works very well. Why would it be disabled if widgets are locked? The menu does not look like a widget, it does not have handles like one and hence should not be treated like it 1:1.

A grip is not a handle and further it has nothing to do with the number of items in kickoff, because defining its size by number of items will not work.

There are tabs with a fixed size of items, i.e. the applications one. Yet 10 of those items do not have the same height/width as 10 in the computer-tab because that tab contains more than one category. Further one should not force the user to a fixed sizer defined by item-number but leave it to the user how wide and high he likes his menu.

What kickoff needs is a "number of items" for the recently used docs and apps and a grip for the user to adjust the size, that's it.
Comment 7 S. Burmeister 2007-12-16 22:36:34 UTC
To the bug-reporter: please reopen.
Comment 8 Thibaut Cousin 2007-12-16 22:38:35 UTC
Your wish is my command. ;-) Reopened it is.
Comment 9 Sebastian Sauer 2007-12-16 23:36:42 UTC
@Sven
re "Why would it be disabled if widgets are locked?"
well, widgets are locked || desktop locked || "read-only" mode like e.g. at a kiosk-system || how to prevent messing up stuff with wrong clicks :)

btw, does it make sense to be able to change also the width or just the height?
Comment 10 S. Burmeister 2007-12-16 23:54:11 UTC
Why would you restrict the users' abilities to change the size? Apart from that translations make the text on the tabs differently wide, hence, even if you would know the widest application-name possible, there is not perfect width.
Comment 11 Sebastian Sauer 2007-12-20 01:25:39 UTC
ah, sorry for the late reply, sven. Seems I did miss to add myself to the CC-list :-/

> Why would you restrict the users' abilities to change the size?

It's "optional" restrict in whatever way. imho it's still important for enterprise-usage to be able to lock-down the desktop in a way that prevents users from changing anything. That's what Kiosk is about. So, to just be able to resize is imho not enough but it's needed to be able to switch  between "use-only" and "use-and-be-able-to-do-changes" somehow. Anyway, that are just implementation-details and probably it was a bit to early to name one of my fav KDE3-features ;)

> Apart from that translations make the text on the tabs differently wide, hence, even if you would know the widest application-name possible, there is not perfect width. 
 
true but how is this related to the question how such a resizing grip should behave (aka resize only the height or also the width) and where it should go to (at the bottom right just like at normal windows may a problem since it makes increasing the high if kickoff is displayed at the bottom of the desktop rather difficult)? I mean, with a resizing grip the user does define the size of kickoff and therefore there is not really that much "auto-resize according to item-height and/or button-width" logic needed imho.

So, my questions where more how an implementation should/could look like since I am absolute unsure there how to get it done in a way that does not suck :-/
Comment 12 Robert Knight 2007-12-20 05:55:59 UTC
> true but how is this related to the question how 
> such a resizing grip should behave

If in doubt, copy the design used in SuSE's implementation for KDE 3.
Comment 13 Vladislav Blanton 2007-12-20 18:25:39 UTC
In order to be as clean and neat as possible, I think that being able to increase the kickoff height is the best.  As an example, there could be a resizing grip along the top of kicker.  This would then be an easier-to-use solution than the drop box implementation above.

It is up to you whether or not it increases in a locked item-height fashion or smoothly.  Lastly, having it not react to an increase in height until one pulls it above a certain point will protect kickoff from accidental clicking (ex: when going for the search bar).

hope this helps
Comment 14 Aaron J. Seigo 2008-02-22 07:23:55 UTC
*** Bug 158203 has been marked as a duplicate of this bug. ***
Comment 15 Stephan Binner 2008-02-27 16:16:11 UTC
Proposed patch: http://mattr.info/r/228/
Comment 16 Stephan Binner 2008-02-29 11:09:55 UTC
Submitted.
Comment 17 Dotan Cohen 2008-12-26 21:01:42 UTC
Created attachment 29647 [details]
Kmenu too small

I do not see how to resize the Kmenu, even with the panel unlocked there are no grippies. As can be seen in the screenshot the Kmenu is way too small on this system. How can I resize it? KDE 4.2. Thanks.
Comment 18 S. Burmeister 2008-12-29 13:00:00 UTC
Just drag the top corners of the menu.