[kde-linux] Re: No panel/taskbar after going to single monitor

[Duncan]

Mark Knecht posted on Sun, 03 Apr 2011 09:58:41 -0700 as excerpted:

> I've got a KDE problem. I needed to move a monitor on one dual-screen
> KDE box to a different machine. I physically removed what was the second
> monitor, modified the xorg.conf file to remove all references to the
> second screen and rebooted. I now get a normal login screen with entries
> boxes in the middle of what is now the only monitor attached to the
> system. However once I log in I get only wallpaper and don't see any
> panel/taskbar at the bottom of the screen.
> As KDE doesn't even give the option to open a terminal using a right
> click I don't know how to proceed.

KDE 1 was a long time ago.  I didn't know it had dual monitor support?  
But the only time it doesn't make sense to include the kde version is 
before there's other versions to talk about, so you /must/ be talking 
about something in the kde1 era, right?

=;^P

Seriously, version number can make a difference.  kde4's multi-monitor 
support has improved dramatically over time, and particularly plasma had 
some bugs in that regard as late as 4.5.  I've not personally seen any in 
4.6, but then I've not done a whole lot that might provoke them in 4.6 
either, so I can't be sure the ones I experienced in 4.5 have been fixed.  
By the 4.2.4 at which I originally switched, kde4 /was/ useful in multi-
monitor mode, but there were /significant/ bugs with it, some of which 
have only been fixed recently.

FWIW, I've not updated from 4.6.1 yet tho 4.6.2 is or should be out pretty 
quickly.  But at least the gentoo/kde folks mentioned 4.6.1 had some 
regressions in it due to confusion from the currently underway upstream kde 
transfer svn -> git -- the 4.6.1 tarballs pulled the wrong one in some 
cases, resulting in code that wasn't release-ready being released.  So try 
either 4.6.0 or 4.6.2 on 4.6, or the last 4.5 release, 4.5.5 if you're 
uncomfortable with 4.6 still, staying away from 4.6.1.  If you're running 
something earlier than 4.5.3, I'd definitely recommend upgrading, as early 
4.5 series had graphics bugs on certain hardware and I'd honestly not 
consider anything pre-4.5 release quality kde4 at all.

But to work around the current issue...

kde4 has multiple launch methods.  The kickoff or alternative launch menu 
on a panel is only one.  Just because it has disappeared does NOT mean you 
can't launch anything.

krunner:

krunner (kde4's run dialog) should still work, for one (tho before 4.5 it 
was buggy and prone to crashing, so could often go unresponsive).  You can 
either use it directly, or launch konsole from it and then use konsole to 
run whatever.

There are two ways to access krunner even without the usual launch menu.  
The first is keyboard shortcut, the default being Alt-F2.  This being kde, 
that's naturally configurable, but if you configured something else, 
presumably you'd remember your own run dialog shortcut.

The second is the run command... option in the default desktop context 
menu.  It's worth noting however that from kde 4.5, the usual secondary-
button desktop context-click action is configurable, and may trigger 
something other than the default context menu.  Should this be the case, 
you can click on "the cashew" aka toolbox icon, generally located at the 
corner or edge of the screen, choose desktop settings, in the resulting 
dialog choose mouse actions, and check and/or reconfigure actions there, 
so you have a "standard menu" context menu again.  While you're there, if 
you like, you can even configure an "application launcher" action that'll 
give you the usual application menu.  Here, I have ctrl-left-click set to 
activate that.  (I wish they had an option to trigger krunner there.  If 
so, I'd probably configure that for some mouse action too, but the option 
isn't available, so the closest it gets is the "standard menu", which as 
mentioned has the run command... option on it.)

Desktop plasmoids:

In plasma, the desktop itself can contain plasmoids or widgets.  You can 
add a kickoff, classic, or lancelot menu directly to the desktop activity, 
if desired.  Widgets must first be unlocked to allow this, however, so use 
either the desktop context (standard) menu or the cashew to unlock widgets 
if necessary, then again to add widgets.  There's an application launcher 
category you can select to show only launcher widgets, or pick from the 
big list if you like.

The folderview plasmoid (or layout if you've chosen that rather than the 
standard desktop layout) can sort of be used as a launcher as well, alto 
it's a bit more difficult.  If you click on a directory or use the 
folderview context menu option to "open with dolphin", you should get 
dolphin or whatever else you've configured as your default file manager.  
>From there, you can navigate to /usr/bin or whatever, and click on a 
binary to open it directly.  Back in the kde3 era, kwin was at one point 
unstable and used to die on me, leaving me without a method to focus a 
particular window (the open dialog or a konsole) in ordered to type in 
"kwin" and launch it again.  But direct mouse-clicking still worked, and I 
was able to click a directory on the desktop to launch the file manager 
(konqueror back then), then use it to navigate to /usr/bin and click on 
the kwin binary to launch it directly. =:^)

Of course if you don't have a folderview in view on the desktop, you may 
have to add one using add-widgets as above, and you may prefer to add a 
launcher instead.

Monitor Reconfiguration:

Once you have one of the launch methods above working, you can launch 
kcontrol (umm... systemsettings, even tho they aren't in general system 
settings but rather kde settings for an individual user, so the kde3 name 
kcontrol is more accurate, why they switched to the less accurate and less 
googlable generic term for kde4 I don't know, but I obviously don't agree 
with it).

In kcontrol you can use hardware, display and monitor, size and 
orientation (4.5+ path, pre-4.5 had a different kcontrol layout) to 
reconfigure your monitors as necessary.   It's worth noting that in kde4 
previous to about 4.4 (I believe it was either 4.3.1 or 4.4.1 that fixed 
it, but don't recall which), there were **SIGNIFICANT** bugs with this 
kcontrol applet and multi-monitor mode for some users (both the Radeon 
graphics (freedomware drivers of course) on my main machine and the Intel 
graphics on my netbook were affected), but again, those seem to have been 
fixed by 4.5, and the bug shouldn't affect people with only a single 
monitor or those switching back to a single monitor from multi-monitor 
mode anyway.

Keyboard shortcuts:

Finally, in addition to remembering your krunner keyboard shortcut in case 
plasma decides to go haywire again, it may be worth configuring a shortcut 
for konsole or the like, as well, just in case krunner is crashed too.  
The three launching methods, keyboard shortcut, krunner, and plasma, are 
deliberately independent of each other, so crashes in one shouldn't take 
down the other two and you should always have at least one of the three 
available.

There's actually several ways of configuring app launcher shortcuts in 
kde.  First, in kcontrol, under common appearance and behavior, shortcuts 
and gestures, custom shortcuts (again, 4.5+ location, pre-4.5 kcontrol 
layout was different), you have the master control.  There should be a 
KMenuEdit entry there, which you can enable or disable.

With the kmenuedit entry enabled, you can use kmenuedit to setup a 
shortcut for any entry in your applications menu.  kmenuedit is kde's 
application menu editor, activated by selecting the edit applications 
option from kickoff or alternative menu context menus, or run kmenuedit 
directly from krunner, konsole, or kickoff's search entry.

Alternatively, you can create an independent keyboard or mouse gesture 
shortcut in kcontrol's custom shortcuts, directly.  Using this method, the 
app doesn't have to be listed in kde's apps menu, so it's handy for 
launching scripts, non-X binaries, or anything else that simply doesn't 
have an apps menu entry.  The framework used is actually quite flexible 
and as mentioned, allows mouse gestures, etc, as triggers as well.  
Further, you can configure actions other than launching apps.  Konqueror 
gestures are available for example, but you can choose between window 
context specific and global application and between mouse and keyboard 
input.  The triggered action can be launching an app, launching a URL 
(using standard kde associations to decide what to do with it), keyboard 
output, or dbus actions, so as I said, the custom shortcuts framework used 
really is quite flexible, indeed. =:^)


Hope that's useful.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman