11.4 KDE autohide taskbar not working

So far good experience with 11.4 on an AMD desktop, but noticed that the taskbar will not autohide. For now I’ve changed to “windows can cover” setting so I can at least see the bottom of full-height windows.

i have the some problem. I noticed that from early milestone releases. In my case, not even “Windows can cover” work. The panel will stay on top no matter what.

Same here.

On a fresh boot the taskbar will autohide UNTIL I open the application launcher menu. From that point on the taskbar won’t autohide.

At least it’s not me this time <grin>.

On 03/12/2011 02:36 PM, draynes wrote:
>
> Same here.

one of you should log a bug:
http://en.opensuse.org/Submitting_Bug_Reports

and, in that bug reference this thread:
http://forums.opensuse.org/showthread.php?t=455440

and, when you have a bug number come back here and post a link to it,
so the others who follow into here can also add info, and check
bugzilla for bug status and any workarounds…

and, all the others here should then add comments and facts to the
bug-…the more who do the faster all the facts are known and the
sooner it will get sorted out…probably…

[only three ands…]


DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

There is no option for 11.4…

Most of the time, it works. But it sometimes stops working. I’m not sure what triggers that.

A logout of KDE, then login will fix it.

There’s possibly a process that could be killed and restarted from within a KDE session, that would correct the problem. But I’m not sure what to look for.

I found something by accident while using Konqueror as a web browser:

aseigo: panel hiding

Friday, March 11, 2011

panel hiding

With all the news of mobile and politics and what not, I thought it might be nice to hear about things we’re working on related to the desktop that, while maybe not as earth shattering or exciting, are none-the-less part and parcel of what we do each and every day.

One of the things we introduced in recent releases of Plasma Desktop was panel auto-unhiding: if you have a hiding panel and something in it says, “Hey, I need the user to notice me!” then the panel will happily unhide. This was only possible because we have the ability to know things like the attention and input status needs of components such as Plasmoids and Status Notifiers.

Unfortunately we hit a snag: not everything sets the attention status sanely. This would sometimes lead to a panel being “stuck” in the unhidden position, unless you could find out what was “sticking” it and cause that component to become “unstuck”. Not very elegant.

After stumbling through a few other random issues yesterday and today, I implemented an approach that tries to balance all needs. This was something that came out of discussions with hiding panel users who are also KDE contributors, particularly Kevin Ottens and Thomas Zander.

In the plasma/panelunhiding branch in kde-workspace, a panel will now auto-unhide and then rehide a few seconds after any user activity. That means that if you walk away from your computer, something happens and you return, the panel will still be there in a visible state to let you know. However, if you are using the system while something goes into “I need attention” state, then the panel will pop up but then mercifully slide back out of view in a few seconds time without you do anything.

I’ll be testing it out more over the next few days and welcome others to do so as well, and then if all goes well with this approach then I’ll merge it into master and, if it’s really solid, maybe even merge it into 4.6.

Posted by Aaron J. Seigo at 1:27 PM

On 03/13/2011 01:06 AM, Argoson wrote:
>
> There is no option for 11.4…

perfect!

i’ve posted a help request to the wiki forum…i can’t find a way into
the 11.4 bug section…i can’t ever tell if it exists yet…


DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

On 03/13/2011 09:38 AM, DenverD wrote:
> On 03/13/2011 01:06 AM, Argoson wrote:
>>
>> There is no option for 11.4…
> i’ve posted a help request to the wiki forum…

until that page gets repaired, this is the way to log an 11.4 bug,

-go to https://bugzilla.novell.com/index.cgi

-click on “New” in the strip of menu items (Home, New, Search, etc)

-in “Product Line” spin to openSUSE 11.4 (if not already set)

-click “Use this product” button

-look at the list of previously submitted bugs to see if yours is
already reported . . .

-etc


DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

There already is such report, see bug #670128](Access Denied).

I found that I was able to make autohide work on all my desktops except one. Just go to that desktop and start something that opens a popup on the task bar, then switch to another desktop before the popup goes away. After that the taskbar stays up on the one that had the popup, but autohides on the others. This is on my main desktop system.

Strangely, on my notebook installation of 11.4 the autohide seems to work without any problems.

On 03/18/2011 06:36 AM, dsosnoski wrote:
>
> Strangely, on my notebook installation of 11.4 the autohide seems to
> work without any problems.

no, that is the way it is supposed to be…and, the way it is for
most people…

clearly, it is either a hardware/driver problem (maybe/probably
graphics) or a software conflict problem…

all in this thread need to add to the existing bug to give things like
hardware/graphics chip, software versions, etc… then more than
likely the developers could track down the bug…

there may already be a bug, and if so each of you need to add info to
it until a full enough understanding is reached…

see: if no one logs a bug it might stay around for years…if only
one person logs it the developer will more than likely figure it is
something that ONE person did wrong in the set up…but, if 15
people, all with an ATI card on a HP laptop log the same bug, THEN
things get noticed…

all with this problem should visit
https://bugzilla.novell.com/show_bug.cgi?id=670128

adding relevant info is a contribution to open source software…


DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.1.8, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

An excruciatingly careful script to restart plasma, quietly if it works and very noisy on failure.
It makes the symptom go away for me:

#! /bin/bash

prog=$(basename $0 .sh)
test -d /tmp/logs && \
    rm -f /tmp/logs/${prog}-?????? || \
    mkdir /tmp/logs

lf=$(mktemp /tmp/logs/${prog}-XXXXXX)
exec > ${lf} 2>&1 < /dev/null
set -x -e

trap "echo '$prog failure:' ; cat ${lf}" 0

kbuildsycoca4
sleep 1
kquitapp plasma-desktop
sleep 1 
kstart plasma-desktop

trap "rm -f ${lf}" 0

A quick follow-up note: Based on KDE bug reports, the problem is that when a window
is “demanding attention” (whatever that means), KDE tries to tell you by making the
task bar visible. It is a bug that changing window focus does not let the task bar re-hide.
Meanwhile, usually if you can get another window to demand attention, give it the
attention it deserves and the task bar will re-hide. 90 % of the time (not 99) anyway.
So, fire up an xterm and kill it and you are usually back in business. If that fails,
then run the script above…