Bug 152696

Yeah, I can confirm this on Kubuntu/7.10 KDE 3.97. Putting the panel on the top of the screen helps if you are 2m tall as it makes for less frequent  visits to the physio - reduction in up and down neck movement! :)

Marking as a wish because plasma is new software rather than a kde4 port of kicker & friends.

Resizing, moving, adding and removing panels are all on the to-do list.

It should be possible to move plasma panel, to remove it or to have two different instances (in order to have a mac tab) of the panel. Should be more like any plasmoid

It should be consider as a regression compared to 3.5

It's a pain that that didn't make it in the 4.0.0 release. Hopefully it will be added very soon! I like to have a "tiny" taskbar, with no 5px border and just one row of applications.

Created attachment 22961 [details]
[PATCH] panel size from plasma-appletsrc

This is a semi-functional implementation of a configurale panel size, it's
still a little bit rough, in particular it must be configured by editing
plasma-appletsrc and i still didn't get on how to move the panel, so with
horizontal panels it's still aligned to the left and it's aligned to top for
vertical panels.
oh and some applets sets a too big minimum size.

*** Bug 155503 has been marked as a duplicate of this bug. ***

Marco: have you tested this with no plasma-appletsrc? i don't see any default settings in the Panel containment so i wonder how that'd work with a fresh start up. i imagine we might need to have a setSize(48, 48) in the ctor.

without a plasma-appletsrc seems to work rather well both if there is setSize(48, 48) in the constructor or not.
a little side note: if i will commit that i would leave this open until there is a config ui

Marco: so what size does it get when there is no appletsrc? and is this simply because of the happy circumstance of the kmenu icon being set to 48px or some-such? because i don't see any default size anywhere, which leads me to worry about two cases: one where there are no applets added (try commenting out the applets added to the panel in loadDefaultSetup) and two where there is an applet that decides to get really freaking huge.

Created attachment 22979 [details]
For developers - shows plasma-panel resizing dialog on startup

[PATCH] I've implemented KConfig configuration of panel resizing (height in
pixels and width in percents of the screen). There is also simple dialog to set
it up, but I'm not sure what's the best way to invoke this dialog (maybe it
would be nice to have this in context menu), so it simply appears automaticaly
on startup. I know this is stupid, but this patch is for hackers and fans, not
for "regular users".
Please, take a look at it and tell me wheather the use of KConfig is correct,
and I'll improve it later.
PS: I'm sorry for my coding-style, but I'm not experienced in KDE developement.

cool patch; the coding style looks fine. a couple of comments:

* you have a dialog and a kconfigxt object. here's what's really cool: you can skip all the setting of values if you just name the widgets the same as the kconfigxt items and prefix them with kcfg_ .. so instead of heightSpinBox kcfg_Height. 

* i usually don't add the type of widget to the name (heightSpinBox) because then when you change the widget later .. sucks. =) it also doesn't work nicely with kconfigxt

* unfortunately, this uses a separate config file. that's a no-go. sadly kconfigxt hasn't been updated to work with KConfigGroup objects, so that needs to get done in kdelibs.

* i'm really unconvinced we want the width in %. we need a special value for full width, but other than that i think pixel values are easier to manage, tbh.

* anchor points are missing (flush left, flush right, pixel x) as are expanding directions, but as you note this is not a full patch

* you don't delete the config dialog in the dtor so you have a memory leak =)

* interesting gotcha that pretty much everyone misses: if the dialog is already created, then you move desktops, the dialog will show on the desktop it was last on not necessarily the current desktop. it may also be under other windows. you can fix this with:

KWindowSystem:::setOnDesktop(m_dialog->windId(), KWindowSystem::currentDesktop()));
KWindowSystem::activateWindow(m_dialog->windId());

long term we don't want to do this with a dialog anyways, but provide a toolbox on the panel sort of like the desktop one.

thanks for the patch all the same, i hope you enjoyed working on it (that's the best reason to do it, after all =). if you want to keep hacking on plasma stuff (it has a way of being slightly addictive ;) please consider joining the panel-devel@kde.org mailing list if you haven't already.

*** Bug 155629 has been marked as a duplicate of this bug. ***

Created attachment 22996 [details]
nicer version

second attempt, this should be a little bit safer now.

Created attachment 23000 [details]
[PATCH] Improved panel-resize ui

I've improved the panel-resize ui:
 * memory leak bugfix
 * dialog appears on the current desktop and is active
 * renamed widgets to kcfg_, but i still dont know how to use it with kconfig
automatically.
 * i failed on implementing left/center/right alignment, does anybody know why
it doesnt work? setGeometry(geo) only resizes panel, but doesnt move it.
 * i think width in percents is more friendly to users imagination than in
pixels - they want "full size", "half of a screen" or something like that (not
exactly 600px)

@Marco: i don't think it's any more safer like that; in fact it's likely to be less safe as it now relies on the proper geometry always being in the config object even when first created or when moved to another screen. seems a bit brittle. i'll ponder how to do this without assumptions.

@Matej: 

* re kconfigxt: you're looking for KConfigDialog. see http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT#Use_and_Dialogs

* left/right/center alignment; yes, that'll take a bit more work indeed as it'll need to move around on geometry changes. while these alignment concepts are familiar to a kde3'er, i also don't think they are really what we want in kde4 anyways. i think we want an anchor point and expansion directions. this will allow easily emulating left/right/center while also allowing for far more interesting and complex arrangements, such as three panels on the same side starting a different locations along the screen. this is related to why i don't think percentages work.

* percentages: so if i say i want a 40% panel because that fits my items but then switch screen resolutions to a smaller screen, should the panel stay big enough to view my items or shrinks and not show them? as screens and resolutions both get bigger, how do we handle the inevitable rounding errors? you're right that people will want "a panel that's half the screen" but we can do this easily by providing "magnetic" points, just as we do with rotating and resizing applets.

anyways ... interesting stuff.. i need to get back to working on my presentations for the release event before i can work on this stuff with the time and attention it deserves.

wouldn't be enough to add some checks like no negative sizes and no more than current screen resolution?
btw best wishes for the release event, hope it will be great :D

Would it be possible to implement auto-hide of the panel like in KDE 3.5.x? Some people like to maximize screen estate even on large monitors ...

Since KDE has a good compositing engine now, some nice looking auto hide related effects could also be implemented.

http://techbase.kde.org/index.php?title=Projects/Plasma/FAQ#How_to_change_the_height_of_the_Panel_at_the_bottom.3F

btw, I am sorry for not taking up the work done by Marco or Matej but wrote something on my own. I just like to let you both know, that it was my fault cause I was to lame to look before through bugs.kde.org :-/
Anyway. There is now something in trunk (mainly to have it somehow working) that could be for sure extended/replaced/whatever with something more nice/logical/etc.

So it will be in 4.0.2 but without the menu if I read it right. Looking forward! Is it possible to have a single row? In the screenshot there was a small pannel but everything was still in two rows (tasks, pager, clock with date)

On Saturday 02 February 2008 11:00:06 Michael wrote:
> So it will be in 4.0.2 but without the menu if I read it right. Looking
> forward! Is it possible to have a single row? In the screenshot there was a
> small pannel but everything was still in two rows (tasks, pager, clock with
> date)


If everything fits fine, it'll use one row, if there are too many tasks, it'll 
try to use both rows, but that depends on the height of the panel and the 
taskbar fontsize.

Two comments:

1) Resizing panel is now implemented in svn but the interface is somewhat 
not intuitive: you have to choose the size that you want from a menu:
small, large, etc.
Wouldn't be possible to adjust it dynamically by draging the border 
of the panel by sliding the mouse ? This would be much more intuitive to
users.

2) It would be nice if one could actually hide the panel (like it was
possible in kde 3.5.x)

Ad.#23) I know that plasma and other parts are new but it would be good to take into account old reports so there would be no need to make the same problematic design decisions again and again.

There is really old report asking for explicit setting of rows. So the user does not set huge/small etc. but -- 1 row, 2 rows, etc.
https://bugs.kde.org/show_bug.cgi?id=77407

But this a bit off-topic since as I can guess taskbar is just an applet for panel, right?

Have a look at bug 155974, which I opened a few weeks ago.
If you look at the changeset that closed it you will find this line:
"const qreal ratio = 2.25; //maybe this should not be hardcoded"

I already played a bit with it, works pretty well. A setting of 10 at standard panel size will give you two rows of tasks after more than 2 tasks are open.

So it shouldn't be too hard to get what bug 77407 asks for.

I think this goes in quite opposite way. imho user should set the size of the panel and number of rows.
The font size is the result of those two settings -- not the other way (i.e. number of rows should be not effect of panel size and fontsize).

+1 on Comment #27

*** Bug has been marked as fixed ***.