Version: (using Devel) Installed from: Compiled sources Plasma panel can now be resized, but it cannot be hidden like it was possible for the panel in kde 3.x I would like to be able to temporally hide it when I don't need it, by clicking at the left/right end of the panel, like it used to be possible in kde 3.x .
Count me in on this wish though I would also like to have an "auto-hide" feature. Low screen resolutions a pain to work with and every inch of screen real estate counts. ;)
It's been (just) resolved in the latest KDE4 trunk. You can now remove panels (Right-Click on panel->Remove this Panel).
Removing permanently is not the same as hiding temporarily. This is a separate feature that has not been implemented yet.
(as the reporter) I agree with comment #3, hidding temporily is not the same as permanently removing it. I want to the pannel to hide when clicking on its edge, as in kde 3.5.x
Sorry to be negative, but lack of auto-hiding is the most disappointing aspect of my first experience with KDE4 earlier today. I did not expect to lose really basic functionality like this - I only expect that from GNOME! Please make this a priority. I will be happy to beta-test.
> I only expect that from GNOME! what was the point of this part of your comment, exactly? -1. since i haven't commented on this report yet: i too want autohiding. =P
apparently the utility of panel auto-hiding is not well understood by some who don't use it. it is quite different than "temporarily hiding it by clicking on the left/right" or "turning it off". - it is like having a dial on your dashboard that you can place out of the way, but see almost at a glance - just by flick the mouse to the auto-expose area. - it is the best compromise between maximizing screen area for active windows and having easy access to the main desktop controls that the panel embodies personally, i've been compromising in the feature's absence by shrinking my panel - in kde 4.0, using the "custom" pixels-size setting, and in 4.1 beta and rc, the nicer, graphical size control. that's working ok, but i would much prefer to not have the clutter of and space occupied by the panel except when i actually need to glance at it...
I like to have two panels set to auto hide, especially on my Asus EEE where there is not much horizontal space left in the default kicker/panel for the window buttons. Without auto hide, I waste a LOT of space on the small screen that could be used by applications.
Get all the types of panel hiding back.
kriko: were you trying to add something new to the conversation, or was that just a random "me too"?
It was a "me too". It is the only feature I miss from 3.5.x in current 4.1.
Actually in trunk it has been implemented the auto hide feature :-)
It was, however someone is not closing bug reports. There are other things about plasma that are fixed, however bug reports are not marked as resolved.
It is still quite buggy, so waiting until it is fixed (including the "windows can cover panel" might make some sense.
Also please see Bug 164969. Closely related but not a duplicate. IIUC, the fix for this is in progress. I would leave it open till there is a release which contains the fix. AJS says to close wishlist items as soon as work starts on them. It would help if he had a status: "BEINGFIXED".
@James: no, there is no work currently being done to my knowledge to implement manual panel hiding (e.g. arrows you can click to hide the panel) as there was in kde3. only autohide is implemented. i've changed the name of the bug to make it really clear what this one is about.
Please can someone indicate which version (or at least, which svn revision) auto-hiding is or will be in? I have 4.1.1 and am about to upgrade to 4.1.2 ...
It is present in 4.1.2 (at least in opensuse 11.1beta3).
That's probably a suse-only feature, can't see this feature and I'm using KDE4:UNSTABLE (4.2 trunk) from opensuse 11.0 which is more or less recent.
Having it in KDE 4.1.x is a openSUSE feature. Yet trunk, i.e. KDE 4.2 and hence also openSUSE's UNSTABLE repos have it. It's buggy though, i.e. "windows can cover" rather makes the panel slide in and slide out, plus, if you hit the right spot at the edge of the screen it does so in an endless loop.
I was answering to Adam question about auto-hiding, sorry for not being specific ;-) Sorry late comment, I didn't get notification about your posts.
Maybe this could be achieved by creating special plasmoid (very big placement and customization possibilities without putting so many specific features into containment code) that could trigger behavior similar to that of auto hiding (by DBus calls or something?). But there is problem how to show unhide trigger, method used in kicker was useful but it was not so beautiful. Maybe also glow or something like that (kind of button maybe), not visible every time when panel is hidden, but shown only when mouse is nearly?
*** Bug 200010 has been marked as a duplicate of this bug. ***
*** Bug 191108 has been marked as a duplicate of this bug. ***
*** Bug 205010 has been marked as a duplicate of this bug. ***
> But there is problem how to show unhide trigger, > method used in kicker was useful but it was not so beautiful. Maybe also glow > or something like that (kind of button maybe), not visible every time when > panel is hidden, but shown only when mouse is nearly? I think that is the perfect solution: No visible unhide button until the mouse gets near the proper place, then is starts glowing like the autohide panels do. When the mouse touches the edge, instead of the panel appearing only the unhide button would appear. Thanks for the idea!
I don't agree -- it is (textbook) a11y abuse. Please don't go into this direction, there are already a lot of "discover" places. KDE is not a game, UI should be self-explanatory with surprise effect equal to zero. And I am afraid of acceptation level of such ideas -- go to Q to discover P, go to Z to discover X, user has already enough problems learning the mechanism of computer system, so please don't add another layer of UI complexity. Here you just added raised the learning curve -- not only user has to memorize how to show the panel but she/he would have to learn how to show the buttons to show the panel.
Maciej, I think that this is easiest possible solution, easiest to implement (only part to trigger hide state), easiest to use (if user know how use auto hide then he don't need to learn something new, only how to hide it) and prettiest, no ugly buttons that obscures screen like in kicker. I Think that showing button on glow bar is not needed, additional complexity, using solution used to show auto hidden panel is enough. By the way, there is already applet for that purpose in playground, but I'm only know that it uses "Window can cover" probably, not tested it.
With all respect, it is more difficult to learn than kicker. And it is not a matter of subjective taste, simple facts (unless someone start to claim that 1000<1). I agree with "cool" factor, but that's it. Plasma is already "cool" enough, maybe it is time for some a11y/u7y concerns?
So how it should look like? Of course something that would be doable and could be accepted by developers. And use of glow is not to make it "cool", only to make it as easiest as possible to implement, as similar to existing solution as possible and to not show that ugly button on screen edge that covers small, but part of screen (most hated drawback of kicker solution, at least for me).
Emdek, you got my vote. I still prefer kicker over plasma panel, but image you hide the kicker to have a nice fullscreen view to an application, then you normally don't want to see a silly button in the corner of the screen. I personally would prefer a button that appears only when the mouse is not far away from it.
It cannot be default behaviour (a11y & u7y). Btw. take a look at new gwenview, it has something similar, grips to panels (its panels). First it annoyed me ("ugly button") but then I realized how handy it is. No memorizing anything. So if there is strong desire to make showing panel two-steps instead of one, ok, but only if the straightforward way is also present (i.e. the grip is visible regardless the mouse position). > nice fullscreen view to an application, then you > normally don't want to see a silly button in the corner of the screen :-) It didn't happened before and nobody is saying to introduce such thing. Buttons were visible on desktop but not on active (focused) applications. For example now (I use KDE3) I have "show panel" button on the desktop but it is in the background, underneath 5 application windows or so.
I'll describe my idea again, with more details, because there is misunderstand with that button shown on mouse move. ;-) First unresolved part, how to trigger hide? It should be menu entry, special plasmoid (no static items like in the past) or keyboard shortcut (or combination of proposals). Hiding should look like in current auto hide (not hiding to corner like in kicker). Second, how show could be triggered: - user moves mouse to edge where panel was before hiding; - when he moves closer bar starts glowing; - when he moves enough close the panel is simply shown. Basically it could work identical like showing panel in auto hide. Additionally there could be rule that if user moves mouse for less than 3 seconds (for example to check date on clock etc.) then panel should be auto hidden (maybe as an option). This way is simplest to implement so there are at lest chances that this could be done (except that part about hiding before 3 seconds or many configuration options, panel controller is not friendly for adding options...).
While I must say that I do not agree with Maciej's stance that having the button hidden until the mouse goes nearby would be a usability issue, I know Maciej from other threads and bugs and he has a very, very keen eye for usability issues. If he says this is a no-no, then I take that as an authoritative voice on the matter.
i'm afraid this bug report is getting hard to follow. the original request, for hiding, has been implemented and the various bugs in it (e.g. the one Beat noted back in comment #20) have been addressed over time. now we're talking about manual unhiding as well as manual hiding, however afaict Emdek is talking about the manual hide feature that kicker had and Maciej seems to be talking about making unhiding autohidden panels easier? (which has never been a usability issue of any sort of severity) i have very little interest in making a button somewhere that must be clicked to unhide panels that have hidden themselves. it's not something many are likely to use (automatic hiding and manual unhiding? it's asymmetrical), though the idea of manually hiding a panel is a plausible feature, though i currently don't have any plans to personally implement it.
Aaron, I do not think that anyone was asking for manual hiding of automatically unhiden panels. It looks to me like everyone is asking for tha ability to manually hide and unhide panels. I find this to be a very useful feature, in fact, it was one of the features that drew me to KDE as I have different workflows and being able to show only the panels I need depending on what I am doing is very, very useful. Thanks for clarifying the confusion, Aaron!
@Dotan, exactly. I was pointing out that completely hiding "show" buttons and showing them on hover: a) is a11y/u7y abuse b) it is over complex, because not the whole process is divided into 2 steps (so for me it would even make more sense this asymmetrical behaviour) It is easy to say, but I think making buttons more nice, would solve the "ugly buttons" issue. And besides, they would be only visible on empty desktop.
> And besides, they would be only visible on empty desktop. How about this: The buttons are shown, but windows can cover them. They glow when the mouse comes near, and the glow _can_ be seen when there is a window covering them. If the mouse contacts the edge of the screen, then the buttons that are below the window pop up in the same manner as the automatically-hidden panels currently do. Thus, the buttons are not hidden any more than desktop widgets are hidden (they can be seen when there are not windows in their area), but they do not bother the user who has a window maximized (yet can _still_ be opened and found due to the glow). Aaron: is this technically possible, or do I have a pipe dream?
@Dotan, looks like acceptable compromise and should be doable too.
Might I suggest that the endwise hidding in KDE-3 is not really usefull. I think that length wise manual hidding (like auto-hide) would be much better. I think that the suggestion in #38, or something similar, would work for un-hide with a lengthwise strip to be clicked on to un-hide. I don't see that the "glow" is necessary since the strip only needs to be like 2 pixels. So, its being visible when the mouse reaches the edge of the frame is not going to be an issue. Simplest way to hide the panel manually would appear to have an icon on the panel. Perhaps there are other ideas. In KDE-3, there were discussions about using multiple panels on the same edge of the screen. Is this a wanted feature. If so, there needs to be a method that could hide and un-hide multiple panels.
(In reply to comment #40) > In KDE-3, there were discussions about using multiple panels on the same edge > of the screen. Is this a wanted feature. If so, there needs to be a method > that could hide and un-hide multiple panels. Maybe DBus interface for Plasma will give needed methods. :-)
Hello: I've read through the comment but do not want to go into any details. I just would like to emphasize that - as a 'conservative' KDE 3 user - I would like to have the same options in KDE 4 as in KDE 3. This inludes clickable, and always visible panel hide buttons located at the left/right/both edges of the panel bar. Regards, Istvan
I too want panel hiding (manually) like in 3.5. I am currently staying on 3.5 purely because of manual panel hiding. This is a simple way, which works (why else was it in kde3), and therefore it should still be available. The auto hiding is good, but I would like to be able to have a manually hide-able main bar, since sometimes I want to have everything available quickly (i.e. directly visble), but sometimes I want to completely hide the bar to get more space on screen. Auto hiding means I lose direct visibility of the main bar.
This is one of two stopper bugs keeping me on 3.5.
Thank, Felix, what is your usage scenario? Please be detailed and specific.
If you open http://fm.no-ip.com/SS/SC/ you can see a lot of screenshots in the listing. In discussions with other web developers I often find it necessary to make another. Typically as in http://fm.no-ip.com/SS/SC/sc-angfre01.png or http://fm.no-ip.com/SS/SC/sc-jennbe01.jpg it is some evolving web site and/or fonts issue that I want to show contextually. Usually I don't want Kicker to be part of the context, instead preferring that the image be of a full screen (so as to match screen resolution) web browser with other smaller windows laid over blank or unimportant areas. Autohide and I do not get along, so I need the manual hiding feature to prep for each shot.
I am sorry, Felix, but I do not understand you. I have looked at some of the screenshots but I do not understand your usage. Please try to describe in words what you _can_ do with manual hiding, that you _cannot_ do with autohide. I am, like you, of the opinion that there are valid use cases for manual hiding. That is why you need to state your usage case. Thanks.
"Manual hiding" hides the kicker when the *user* wants it to be hidden, as opposed to autohide when the *system* decides that it should be hidden. This feature is removed in KDE4, in 3.5 it was possible to manually hide the panel. The usage case is "worked fine" in 3.5 and "can't no more" in 4.X. In both versions, the reason is "because I said so". Why is this taking so long to fix?
On Tuesday 12 January 2010 20:55:02 Dotan Cohen wrote: > I am, like you, of the opinion that there are valid use cases for manual > hiding. That is why you need to state your usage case. Thanks. I'm not sure why you'd need exact descriptions of use cases. Obviously different users have different use cases, and it should be enough to understand that there *are* users who want this feature - for whatever reason should not really matter. Some of them, like me, are simply used to this nice feature from KDE3, and therefore now I feel it's missing. Still, I give you my use case: I have only one bottom panel (about 60pixel high), and my laptop has a weird resolution of 1440x900, which is a very small height. The panel contains the clock and the systray etc., so I always want to see the clock and also the systray (is there a new mail, etc.) - therefore I dislike autohide. Sometimes I need the full height when I start a specific application (our own company software having windows with fixed height but made for 1280x1024). So I need as much height as possible otherwise I can not see the bottom part of the window (which sometimes contains important information or even buttons).
(In reply to comment #48) > "Manual hiding" hides the kicker when the *user* wants it to be hidden, as > opposed to autohide when the *system* decides that it should be hidden. Use "windows can cover panel" then you decide when to hide by clicking on the window. > This > feature is removed in KDE4, in 3.5 it was possible to manually hide the panel. > The usage case is "worked fine" in 3.5 and "can't no more" in 4.X. In both > versions, the reason is "because I said so". Why is this taking so long to > fix? Because you are not willing to invest any time or money, why should somebody else spend his free time for something you want?
@S. Burmeister: windows-can-cover is pretty close, but it doesn't prevent other windows from covering it when maximized. i think Martin wants a panel that blocks -most- maximized windows from covering it, and a button that says "ok, now get out of the way of windows". right now that's 3 clicks (and a bit of a wait for the panel controller to appear; i really need to do an optimization run on that class, there's no way it should take as long as it does (a few 100 ms by my reconning?)), so i can understand the inconvenience there. still, we need to do the cost/benefit (where that inconvenience in this particular use case is an addition to the benefit side) ... see more below: @Martin Koller: "it should be enough to understand that there *are* users who want this feature" that would make it absolutely impossible to: * prioritize * figure out how to harmonize disparate feature requests with each other * deliver features that actually fit the actual needs * and yes, even decide which feature requests to pass on "simply used to this nice feature from KDE3, and therefore now I feel it's missing" class example of why we ask for use cases. because "i'm used to it" is not a valid use case to us. (though it may be for you. :) we require additional reasoning so that we avoid simply recreating all the flaws along with all the features of kde3. "Sometimes I need the full height when I start a specific application" interesting use case; it still doesn't solve it completely (the, obviously broken, application is still taller than your entire screen; that sucks :/). its seems like quite an edge case. we tend to weight the cost of a feature against such things, so if we can find a way to implement it at low cost (maintainability, final UI presentation, etc) then such use cases would certainly justify doing so. thanks for the input, it's very useful.
Hi Aaron, On Tuesday 12 January 2010 22:43:08 Aaron J. Seigo wrote: > --- Comment #51 from Aaron J. Seigo <aseigo kde org> 2010-01-12 22:42:57 --- > i think Martin wants a panel that > blocks -most- maximized windows from covering it, and a button that says "ok, > now get out of the way of windows". exactly (to be precise: I want _no_ maximized window to cover the panel) > right now that's 3 clicks how do you reach that in 3 clicks ? (note: my panel is locked) > @Martin Koller: "it should be enough to understand that there *are* users who > want this feature" > > that would make it absolutely impossible to: > > * prioritize What I was meaning with "there *are* users" is simply based on the number of comments in this bug issue and the number of votes it already has. And AFAIK at least the votes can give a hint for prioritization. > "simply used to this nice feature from KDE3, and therefore now I feel it's > missing" > > class example of why we ask for use cases. because "i'm used to it" is not a > valid use case to us. In principle I understand, but I hope you also know this is the reason why people are reluctant to move to "new technologies" (... Vista, KDE4, ...) As a developer, I can understand your reasoning, as a user I ask myself: Why should _I_ adapt my workflow to the software. The software should do what I want (and should at best continue to work how I was used to it for the last 7 years or so) > "Sometimes I need the full height when I start a specific application" > > interesting use case; it still doesn't solve it completely (the, obviously > broken, application is still taller than your entire screen; that sucks :/). yes, it sucks, but I can't change it. > its seems like quite an edge case. It's not that anybody can't live without such a feature (how would all the poor Win users survive otherwise ;-)) > thanks for the input, it's very useful. You're welcome.
My use case: Small laptop screen (1024x768). Usually I want the whole panel/bar visible for viewing the clock, email notification, menus, etc. Sometimes I don't want to have the panel visible, specifically when programming with Eclipse so that I can see various eclipse panels while having enough space to see a large enough portion of the code editing screen. I can increase screen space by hiding the panel. Another example is if I want to edit a large image using the Gimp, hiding the panel increases how much I can see. However I always want the panel visible when doing "normal" tasks such as internet browsing, email, anything required for school-work etc. This requires a manual method of hiding panels. Hiding panels is already possible (auto-hide). It shouldn't really be that hard to implement a button which calls the same routine that hides the panel? (+ a second button can then be shown when the panel is hidden.) Another suggestion is implementing it as an applet, or plasmoid (Sorry, don't know the current terminology), which calls the same code. Possibly simplest would be a simple key combo hiding/unhiding the panel, without any sign that there is panel hiding on the panel / no indication of a hidden panel, which would however still serve the same purpose, albeit with little user friendliness. (Currently I don't have time to try hack together my own solution to this, I don't have a clue about KDE's workings, but I might try in the summer if this isn't solved by then.)
@Dotan -- in short I hope you agree hidding panel is needed, right? So, the autohide does not fit always, because it (yes, it) decides when to show it, not me. With manual hiding/showing I can explicitly command when to show it (when I need it, not when I just move mouse near the edge while editing image in Gimp).
Maciej, I agree but that does not help. Aaron or another Plasma dev needs convincing and from experience, nothing convinces like a valid use case. Simply having been a KDE 3.x feature is not enough. My use case: depending on what I am doing, I may or may not need a particular wide panel to take up 10% of my vertical pixels. Switching activities is not a valid compromise, as I have many plasmoids and I do not want to reconfigure four activities each time I add or remove a plasmoid. I just want to _add_ another panel sometimes, not replace my whole setup.
It had this thought; what would make manual hiding of the panel unnecessary? I much prefer auto hiding, but it has a problem; the panels tend to pop up when you don't want them to. My proposed solution to the problem would require the assistance of the authors of the mouse drivers for X. My idea is to have the mouse extent be larger than the screen. Then there could be a margin, where the mouse would have to be moved a distance off screen before the auto hide panel appeared.
@56: Unfortunately, you're forgetting to take Fitts' law into account. It reduces productivity significantly if you can't just slam your cursor to the edge of the screen to position it. (Try acquiring the scrollbar on a browser on the left-hand monitor of a dual-head setup if you want a first-hand example) This is why Apple puts the menubar at the top of the desktop and Google Chrome's tab bar and scrollbars are integrated into the browser frame.
@56+57:Instead of this "invisble area" you could make the mouse sensing more intelligent, i.e. when you "slam" the cursor over to the side the bar appears, if you move it more slowly then it does nothing. This means those wanting the bar appearing have it appearing the same as usual (I tend to see people "slamming" the cursor to do so), whereas for those who just happen to be moving the cursor near where the bar is because there are some program buttons there, but who don't want the bar appearing, nothing changes, meaning they don't get annoyed at unnecessary bars appearing. However, I don't think you can make manual hiding unnecessary, apart from by forcing everyone to have a massive computer monitor. One option is having the program being able to go full screen (e.g. Firefox F11) which hides the bar, but that wouldn't work for multi-window programs such as The Gimp, or multiple programs either.
Just musing... how hard would it be to script a plasmoid that could toggle between windows-can-cover and windows-go-below ( or something like that ) for a panel? Then you would also get the ability to assign a keyboard shortcut for hiding the panel, and you would avoid extra configuration.
@Dotan, > Maciej, I agree but that does not help. Aaron or another Plasma dev needs > convincing and from experience, nothing convinces like a valid use case. I gave one -- I need hiding panel, but not at cost of showing it each time I pass mouse near the edge. If it not convincing I don't know what is -- it (in negative case) would be like saying that auto opening doors are useful in all cases. There are manual opened doors, and automatic. One does not rule out the other (yes, I know doors are not panels, just to avoid "you are comparing apples and oranges" ;-) ). @A It (slamming) would be a huge drawback for any handicapped person. Instead of having feature comfortable useful, now you would have to try hard to trigger it. @Chris, Let's say it is possible. How you would show the panel then? Using mouse.
Maciej, You can bind keyboard shortcuts to plasmoids i.e. Meta+F1 to pop up the application launcher, so you could do the same with a manual-panel-hiding plasmoid.
@Chris, I fully realize it is possible using keyboard, but my question was/is "how you do it using mouse?". To be valid solution it has to be possible with mouse.
Maciej, Ah, I misunderstood your question. To show the panel using the mouse, you would still have to make it visible by touching the screen edge if there is a window covering it. If there is not a window covering the toggle plasmoid, then you could simply click the plasmoid to toggle to windows-go-below mode. Short of convincing the plasma devs that there simply must be a handle to hide or unhide panels or creating an always-on-top panel/other containment in the corner to hold the toggle plasmoid, I don't think that you will be able to completely achieve the functionality you have described.
(In reply to comment #63) > I don't think that you will be able to > completely achieve the functionality you have described. But I already can, using the much less obtuse KDE 3 desktop. Until this bug gets fixed, KDE 4 will never constitute an "upgrade" for me or whatever users there may be like me. (In reply to comment #47) > I am sorry, Felix, but I do not understand you. I have looked at some of the > screenshots but I do not understand your usage. Please try to describe in words > what you _can_ do with manual hiding, that you _cannot_ do with autohide. I've been doing what I'm doing now for several years. I don't remember what is was, besides a general dislike for most things "automatic" automatic (e.g. I own only manual transmission cars), that made autohide a problem. What I do now I do mostly as routine, without having to think about it. The problem may have to do with the bottom of the workspace, and consequently the position of lower windows, moving according to whether Kicker is hidden or not. The screenshots must be made with the windows positioned just where I put them, and must not move when Kicker disappears after I use it to raise KSnapshot to start the shot.
@Chris, It means that using the mouse I would still get the unwanted panel if I touch the edge during normal work. So no progress here.
@Maciej: Your timing is perfect. Completely unrelated to this bug, I just filed this: Show auto-hide panels from the screen corners https://bugs.kde.org/show_bug.cgi?id=224008 I figured that it would interest some users here, and it seems that it does!
I am soon getting a new computer with large monitor, which means I don't *absolutely* need panel hiding and can therefore use KDE4 (which I otherwise prefer to KDE 3 now). Since I still want / need (for my laptop) the ability to hide panels manually, I will probably use the opportunity to code manual panel hiding, the same way it works in KDE3. I don't have much knowledge of the Plasma internals / APIs yet, but from what I've seen and thought out so far the code for the panel itself will have to be modified, as opposed to making a plasmoid, due to the requirement of still displaying a handle where the bar was hidden allowing it to be shown again. If I'm successful I'll post the patches and *try* get it integrated in the main kde branch. (Don't expect anything for a while from me though, I'm pretty busy with exam preparation until the beginning of June. And then I still need to learn C++, the KDE internals etc.)
I just discovered another use case for when I'd need the manual autohide feature: I have VmWare Player running on one virtual desktop and it runs Win-XP which I need for company work. When I now maximize the VmWare window, it shows the guest OS in a fullscreen mode, but the bottom panel of KDE is still visible on top of it - therefore it covers the (also bottom) taskbar from windows. The same happens when I run mythfrontend (from MythTV) in fullscreenmode. But maybe this is just a bug in plasma(?) and a fullscreen app should be on top of the panel ?
@Martin Koller: I would think that's a bug, since when an app requests fullscreen mode, plasma should disappear. But I'm not sure how that is implemented (i.e. whether the application needs to specifically request fullscreen, or whether plasma should automatically realise, etc.). I'm assuming you haven't had the bug in other desktops / kde 3.5? If so, it is a kde 4 bug, and should be reported. @all: I'm just getting round to implementing (or trying to implement) manual panel hiding. I think I will implement a simple "hideable panel" option whereby if this is selected (as opposed to selecting always on top, autohide, and windows can cover modes), the panel, when shown, behaves as per usual (windows can't cover) and two hiding buttons appear possessing the obvious behaviour (here there is the issue of the plasma logo at the right end of the panel being confusing if there is a button beside it, but I think that's minor issue to solve). I don't know whether I should implement the option of having only one hiding button if wanted? (An alternative would be for panels that are based in a corner, as opposed to centred, independent of width, having only one button at the opposite end, whereas any panel that is based in the centre would have two hiding buttons.) Does anyone have any other ideas regarding such functionality?
@Martin Koller: if the application requests that the window goes fullscreen, the panel does go under it (just tested). if the application simply makes it's geometry as large as the screen, that is a broken application. there's a fullscreen hint for x11 that ought to be used in such cases. if the panel is staying on top for you, perhaps you can provide further information such as: what window manager, what panel hiding settings (if any) and if this also happens when you put a kde app into full screen mode (e.g. okular) @A Hunt: the place to do this would be in kdebase/workspace/plasma/desktop/shell/panelview.cpp. the panel toolbox lives in the Containment, but this is a view issue and so should go there. this will also allow it to work properly with any containment without polluting other shells where this is an irrelevant feature.
(In reply to comment #69) > here there is the issue of the plasma logo at the right end of the panel > being confusing if there is a button beside it, but I think that's minor > issue to solve Very easy to solve. Get rid of the logo. Logos without an obvious function attached are nothing but clutter. Change the logo to a hide button when a hide button is desired. Or maybe make the logo always or optionally be a hide button? > I don't know whether I should implement the option of having only one > hiding button if wanted? If my panel hiding button cannot remain exclusively in the lower right as it is now in KDE3, it will be a very long time before I use KDE4 for anything other than target practice. I do a lot of screen shooting, and lower right is the only appropriate place. I cannot imagine why anyone needs two hiding buttons.
"Logos without an obvious function attached are nothing but clutter" the toolbox opens the configuration interface and ensures that there is also always a place that accepts right clicks no matter what an applet does. not only does it have a purpose, it has a critical function to serve. (note that is used to be wrench icon, but this was changed before 4.0 because the wrench was not only considered ugly by the designers but wasn't any more obvious to users i testing) "I do a lot of screen shooting, and lower right is the only appropriate place" in your opinion. there are others who use this software, and your attitude of "my opinion is the only one that matters" doesn't fly. i'd suggest that those who have a panel attached to the left edge of the screen (e.g. a left aligned 50% width panel) would probably find having only a right hider really, really odd. a simple heuristic could be: * if the right edge touches the screen edge, show the hiding on the right * else, if the left edge touches the screen edge, show the hiding button on the left * else, show the hiding button on the right p.s. Felix, your approach to this bug report is not very constructive or helpful to getting resolution. please visit KDE's code of conduct and consider how you can engage in a more positive manner that fits in with that: http://www.kde.org/code-of-conduct/
@Aaron: Thanks for correcting me, I was thinking along similar lines, but got the sides a bit mixed up. (Although for the third case, i.e. not touching either side, or full width panel, I think it might be better to show both buttons?) At first I'll just implement buttons on both sides for simplicity though, in order to get manual hiding working. (It's going to be a fun/difficult enough thing to get that in place, seeing as I haven't done any C++ before.) (Note on having two hiding buttons: I myself think its more aesthetically pleasing for a centred / full width panel to be symmetrical in terms of having two buttons, and I do in fact use both, so I think they should be kept? There aren't any important reasons for not having two?) With the Plasma (?) logo: if I make the buttons distinct enough I think the problem should be solved, i.e. all that is required is a distinct border between the logo and hide button?
(In reply to comment #72) > "I do a lot of screen shooting, and lower right is the only appropriate place" > in your opinion. there are others who use this software, and your attitude of > "my opinion is the only one that matters" doesn't fly. What I wrote was a demonstration of the logic inherent in KDE3 configurability generally, and for the panel hiding function specifically. It wasn't meant as authoritative specification. > i'd suggest that those who have a panel attached to the left edge of the screen > (e.g. a left aligned 50% width panel) would probably find having only a right > hider really, really odd. > a simple heuristic could be: > * if the right edge touches the screen edge, show the hiding on the right > * else, if the left edge touches the screen edge, show the hiding button on the > left > * else, show the hiding button on the right I could live with this, but I'd rather the simplicity offered in KDE3 settings. > p.s. Felix, your approach to this bug report is not very constructive or > helpful to getting resolution. please visit KDE's code of conduct and consider > how you can engage in a more positive manner that fits in with that: > http://www.kde.org/code-of-conduct/ That page (as the rest of kde.org) is rudely designed for viewing only, not for actually reading. The text is too small (disrespecting my browser default size *) and too pale, a combination which, besides being rude, is functionally illegible. Those who both wish respect, and chastise others for not giving respect, need to show respect themselves. * http://www.kde.org/media/includes/chihuahua/css.php contains on line 125 "#main {... font-size:10pt". Specifying web text size in pt this way totally disregards, and thus disrespects, visitor settings, needs and preferences. See also: http://www.w3.org/QA/Tips/font-size
> I could live with this, but I'd rather the simplicity offered in KDE3 settings. But KDE 4 isn't KDE3: I initially would have preferred to implement exactly the same functionality as in KDE 3 (in fact I initially though this KDE 4 thing was a load !^&$&*£"), but in hindsight the proposed solution seems much better, since that is exactly what the vast majority of people wanting panel hiding would need: with this the required settings would already be there, automatically. Having the same options as in KDE 3 just wouldn't fit into the idea of KDE 4. Yes, KDE 4 is taking (some) configurability away, but after more use I can see that it is in fact better, in that it better fits my needs right away without needing the extra reconfiguration (although I still have some gripes with some parts), despite my initial great misgivings / hate of KDE 4. If you aren't happy with KDE 4 then stay with KDE 3, develop it yourself, but don't criticise those who are giving up their time to make what is becoming a great desktop, just because it doesn't fit your ideas. This is something I initially did, and now regret. Yes I don't like some things about KDE 4, but I can modify those, and the developers are friendly when I want to do so. Instead of complaining I am now trying to improve things myself, which gives a lot more satisfaction. Also, please don't try starting wars about unrelated issues with web-page formatting. Instead, you could be constructive and suggest improvements to those responsible for the webpage. (On a side note I have no problems with the page, i.e. I can resize the text if I want, although that may be a browser-dependent feature/issue.) Lets get back onto discussing manual panel hiding now...
OK, I'm now properly working on manual hiding. I have added the configuration options (although I still need to make an icon to show for the option, would be good if someone with skills in that area were able/willing to help), and have made an unhiding button. However, I'm not quite sure where to place the hiding buttons, i.e. how do I get them to appear on the plasma panel? Do I need to implement the buttons as some form of permanent applet to be embedded on the panel? (I was trying to look for how the cashew is implemented: it seems DesktopToolBox / InternalToolBox are the classes to look at, but I haven't been able to discover how it gets painted onto the panel.)
they probably should not be put into the containment, but be part of the view itself. e.g. PanelView should probably place the hiding button a QWidget next to the actual QGraphicsView. we can style it nicely with the plasma theme later. by contrast, the toolbox is placed inside the Containment itself. it is controlled by the Containment and is Containment-specific. btw, further questions / patches / etc are probably more usefuly sent to plasma-devel@kde.org and/or on irc.freenode.net in #plasma (i don't always catch all updates to bugs)
A solution for the annoyances surrounding auto-hidden panels could be to make them only show up when they are needed, not when the cursor is 'in the neighbourhood'. I actually didn't make this up, but read it in the kde-usability mailing list in a post from Jos Poortvliet, and I quote > Really, it's a long read, but the PDF is worth it. Several of those ideas > REALLY make sense. Having to punch the side of a screen with the mouse to let > the panel pop up instead of just being there - brilliant, it's the exact > reason why I don't use auto-hiding panels. They show up when I don't want > them. And having them show already way on time when I want to drag & drop > something on them - even better! the links to both his post and the mentioned pdf: http://lists.kde.org/?l=kde-usability&m=126736436417036&w=2 http://www.gnome.org/~seth/zuhanden-gnome3.pdf
Three years is not enough to solve this serious bug? At least someone can explain how to create a keyboard shortcut? Thanks.
I've been having to use killall plasma-desktop to get the panels out of the way. As I have a custom keyboard shortcut menu system app-launcher setup (no thanks to kde4 killing multi-key hotkeys, so a kde-only hotkey solution simply won't work, but that's a different bug...) for my frequently used apps and as krunner still works without plasma, I can still launch stuff, and killing plasma, then restarting it when I'm done using the area the panel would take, is WAY easier than trying to navigate the fiddly panel properties popup, that unfortunately disappears if it loses focus (focus follows mouse), TWICE, once to unset always visible, once to turn it back on after I'm done. Plus, with windows can cover, the panel still pops up if the mouse happens to hit the edge, which is annoying if you didn't want it to, and it's a big panel. Better to just kill plasma and not worry about it, temporarily. But having a proper manual-panel-hide/show button option, as kde3 did, would eliminate the problem. I searched kdelook for a plasmoid that might do it, to no avail. =:^( Also see the following list thread discussion on the topic (including a post discussing other workarounds I've tried, as well, that others may find helpful): http://comments.gmane.org/gmane.comp.kde.general/25583
As reference: configurable delay for autohide/show of panels https://bugs.kde.org/show_bug.cgi?id=267277#c23
I can confirm https://bugs.kde.org/show_bug.cgi?id=158556#c68 Martin Kollers problem. The bottom KDE panel is hidden. When I start vmplayer with WIndows XP started in fullscreen mode, I am not able to use the Windows startbutton, because somehow this area is reserved by the KDE panel. I can see whats going on, because my Windows mouse cursor is white and my Xorg mouse cursor is black. As soon as I try to hover over the Windows panel the Windows mouse cursor turns into the black Linux mouse cursor. If I don't auto hide the KDE panel, this problem does not occur. vmplayer covers the whole dekstop then. I have Kubuntu 12.10 with all the latest upgrades, vmplayer 5.0.1 build-894247. Vmware tools are installed. Please tell me, what to do (which logfiles, etc.) if you need more information.
(In reply to comment #82) One more thing vmware tools 9.2.2 Maybe this is not a KDE problem at all, but it would be nice if someone checked it out. I am willing to test.
Markus: Could your symptom and mine: Bug 311974 - When I set the panel to auto-hide, the mouse does not reveal it (https://bugs.kde.org/show_bug.cgi?id=311974) be related?
Marco Parillo: I don't know, because I have the problem outside of vmwareplayer, and you seem to have the problem inside of vmware player?
Markus: Correct, so I am hesitant to mark mine as a duplicate, unless you had good reason to believe they shared a common root cause.
This bug is one big and old mess... Since convertible laptops, like Thinkpad Yoga, are not as rare as few years ago, this issue needs to be solved somehow. Convertible laptop usually has few buttons accessible when in tablet mode (touchscreen only, no keyboard, no mouse). This buttons are usually volume rocker, power button and one or two more buttons, which behave like ordinary keyboard keys. Since such devices usually have small screens, it is not practical to have panels visible all the time. Autohide is fine as long as mouse is available. It is easy to hit edge of the screen with mouse pointer to show the panel, but it is very hard to do so on touchscreen without clicking on near-edge objects. So here comes manual hiding of a panel. There should be option to assign keyboard shortcut to manually hide the panel in panel configuration dialog (not set by default). This will not allow user to hide panel without knowing the shortcut. Mechanism of hiding should be the same as used by autohide, but without leaving the screen edge active. Currently, it is possible to toggle dashboard using keyboard shortcut, however the dashboard cannot be used with on-screen keyboard plasmoid. This keyboard plasmoid behaves well when placed on panel. This feature is not about autohide. However, when autohide is enabled, the edge of the panel should remain active -- panel will toggle between autohide and visible states (instead of hidden and visible states). Additionally, there should be dbus interface to this feature, same as it is to dashboard. There is no need for a button on the panel nor a way to show the panel with mouse only. Mouse-heavy users can use autohide.
Can someone with permissions change the product and component on this bug. Still a valid for wish for Plasma 5.
(In reply to cherenz from comment #88) > Still a valid for wish for Plasma 5. Indeed. I don't have permissions, tho. With plasma5 there is, however, a partial workaround. While panels still aren't part of activities (why, I haven't the foggiest, other than obvious bugs, my greatest disappointment after the upgrade, as it sure seems obvious to me that different activities naturally need matching different panels to go with them)... In kwin5's window rules, it's now possible to set windows (including panel windows) to appear only on one activity, or to force them to appear on all activities. As such, it's now possible to setup two activities, one with panels and one without. Unfortunately, there's a number of limitations at the moment. The first and biggest limitation is that in plasma5, all panels have the same hard-coded window title (Plasma) and window class, and no window role at all. Thus, it's impossible to create a rule that applies to only one panel; the rule applies to all panels or none. As such, it's still impossible to have different panels for each activity, you're limited to either all panels available or none. The second limitation is that rule can force windows to a specific activity, or it can force them to all activities (the default for panels). There's no way to force windows to all activities *BUT* one. Thus, if you are already using multiple activities, you can't simply add an activity that doesn't have panels. You can have panels on only one activity, but you can't have panels on all activities BUT one, which would seem to be the common request here, unless of course you only have two activities, one with a rule forcing all panels to it, another one without panels. Taken together, these two limitations severely limit the usefulness of the window rules force-to-activity feature as it applies to panels, because (1) the rule can only apply to all panels, not just selected panels, and (2) the rule can force panels to one activity, but not all activities BUT one, so it's possible to have only one activity with panels, but impossible to have only one activity /without/ panels, unless there's only two activities, one with and one without. (Or just one activity, without, but that's easy, just delete all the panels.) Still, it's progress, and if that activity window rule eventually becomes a list of activities, so one can choose multiple activities for a window to appear on without forcing it to all activities, and if panels eventually either get settable titles or distinguishable window roles (IIRC in kde4, panels had roles like panel#1, panel#2, etc, so rules could apply to just one of them) once again, then it'll be possible to setup specific panels for specific activities, even if it has to be done manually via window rules. But simply having a button to manually hide and unhide panels, as kde3 did, remains a pretty basic request, far simpler than having to jump thru window rule hoops even if the latter does eventually become possible without the limitations that apply today. Meanwhile, I've not tried it (yet, I might...), but I believe it should be possible to script either wmctrl or xprop (or a combination of the two), to set either specific window roles or specific window titles, based on panel window position and class. Once that is done, it becomes possible to use normal kwin window rules to specify specific panels as the role or title will no longer match all panels, and kwin window rules can then be used to set them to a specific activity. One can then create additional panels, if desired, probably with a slightly different position or size so the script doesn't set the role/title on the wrong one, to set to other activities, and it should finally become possible doing that, to match up panels and activities, which would cure the problem a different way, by letting a user setup an activity without panels. Unfortunately, even if possible as I suspect it now is, that requires a user knowledgeable enough about scripting to actually do it, and of course the time for them to script up this extremely ugly hack for what /should/ be a simple part of the builtin plasma UI.
Still valid. Best would if one could also map panel hiding to a short-cut.
> With plasma5 there is, however, a partial workaround. That's a needlessly hacky solution. Look at plasma scripting you can change the hide status of the panel there.
I just made a hacky script to do that kwin script that toggle panel https://www.opendesktop.org/p/1266534/ We can also add more feature to a panel by setting it up in (KDE System Settings - Window Manager - Window Rules - New - Detect Window Properties "And select your pannel"
*** Bug 396796 has been marked as a duplicate of this bug. ***
It still would be nice to have buttons to hide the panel as in KDE 3.
It still would be nice to have buttons to hide the panel as in KDE 3. Especially for times when auto hiding and transparency is broken.
The problem may lie with the "Icons-only Task Manager", which has an option Panel Hiding: Unhide when a window wants attention The "Icons-only Task Manager" seems to believe that some window always wants attention, but I cannot discern which window that might be. I tried to create a second panel and delete the first one. This resulted in a mismatch between icons on the panel and open application windows; the wrong window would get focus. In particular most Firefox windows are now inaccessible. I will try to reboot and hope this goes away.
*** Bug 350518 has been marked as a duplicate of this bug. ***
Show/hide based on clicking a button somewhere is tracked with Bug 412483. Let's use this one to track manual show/hide via a global shortcut.
*** Bug 474035 has been marked as a duplicate of this bug. ***
*** Bug 412483 has been marked as a duplicate of this bug. ***
Sorry for the churn and email spam, everyone.
I think this is relevant: Switch Panel Button - Double Panel Same Location https://www.opendesktop.org/p/1289173 Toggle Panel Button - Hide Unhide Taskbar https://www.opendesktop.org/p/1269113 both also made by intika
I'm merging the two together since a button would have a shortcut, so they'd be both fixed in one.