| Summary: | make kickoff freely resizable | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Thibaut Cousin <kde> |
| Component: | widget-kickoff | Assignee: | Stephan Binner <binner> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | aos, james.ellis, mail, sven.burmeister |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Kmenu too small | ||
|
Description
Thibaut Cousin
2007-11-09 15:38:46 UTC
eventually, yes. not sure about 4.0. we'll see. *** Bug 154104 has been marked as a duplicate of this bug. *** 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 :) > 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. 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? 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. To the bug-reporter: please reopen. Your wish is my command. ;-) Reopened it is. @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? 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. 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 :-/ > 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.
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 *** Bug 158203 has been marked as a duplicate of this bug. *** Proposed patch: http://mattr.info/r/228/ Submitted. 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.
Just drag the top corners of the menu. |