Black screen after KDE 5 logo (with log)

[Duncan]

Dâniel Fraga posted on Fri, 16 Dec 2016 15:02:05 -0200 as excerpted:

> On Tue, 13 Dec 2016 21:50:32 +0000 (UTC)
> Duncan <1i5t5.duncan at cox.net> wrote:
> 
>> Generally, what I've found to be the problem when all I get is a blank
>> screen, is that plasma itself won't start.  Try manually starting
>> plasmashell 
> 
> Running plasmashell worked fine. In fact I forgot to set some very
> important environment QT variables:
> 
> https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/
Test_plasma#Prepare_the_testing_environment
> 
> Now the problem is solved and KDE starts fine. Then I "solved"
> another issue: missing icons. In fact I forgot to install
> libdbusmenu-qt. Without it, xembedsniproxy would register the event,
> but the icon wouldn't be displayed. Isn't it interesting that
> libdbusmenu-qt is an "optional" requirement for plasma-workspace, but
> without it xembedsniproxy won't work? I mean, I imagine 100% of the
> users would like to see the icons, so libdbusmenu-qt should be required
> no matter what.

Well, originally, xembedsniproxy was separate itself -- everybody was 
supposed to have gotten with the program and be using the new APIs now, 
and xembedsniproxy was an optional concession to those still running 
"legacy" apps.

But while the plasma devs may want to go off and do their own thing 
sometimes, unlike gnome devs' claims of "our way is the only proper way", 
and the problems kde in general has sometimes had with being entirely 
tone-deaf in terms of how users actually want to use their product, at 
least the plasma devs tend to be able to see the light if enough users 
ensure it shines brightly enough at them. =:^)

In the kde4 era this was demonstrated when plasma brought back the 
folderview desktop, and when they did away with the activities-zoom 
interface that nobody but the devs themselves seemed to like.

In the plasma5 era, it quickly became apparent that enough people had 
enough of those "legacy" apps around that built-in support for those 
"legacy" systray icons really was needed, and the easiest fix was to 
simply bundle the sni-proxy thing.

Libdbusmenu-qt being optional is thus likely due to the sniproxy history, 
and the fact that it's still sort of optional itself.  Presumably, by the 
end of the plasma5 run, rather fewer folks will be using it, particularly 
if as expected, many are running wayland and X itself is legacy, with 
legacy X-based apps being supported by rootless X in wayland.

Whether the change will be far enough along, however, for sniproxy, or 
other support for the by then even /more/ legacy old X-based system tray 
API, to be fully dropped in plasma6 or whatever, remains to be seen.  By 
then it very well /might/ be, but of course that's still several years 
down the road, too, and kde/plasma and its users still have the switch to 
wayland to navigate... or possibly overwhelmingly reject... in the mean 
time.


Meanwhile, there's another even more recent example of this ultimate 
plasma dev responsiveness, rather close to home for me, as well.  Baloo 
support was very recently officially made optional in plasma-desktop and 
plasma-workspace, as well.  Until then, it had been officially required 
in plasma5, despite the dependency being easily patched out as it was 
only necessary for a krunner component or two, and a plasmoid or two.  I 
had been patching that out myself, and being a gentooer, had filed a bug 
with my preliminary patches and requesting that gentoo's kde4 era 
USE=semantic-desktop flag, or similar control of that option, be brought 
back.  The bug was closed as UPSTREAM, but someone made the case to the 
plasma devs, and they decided to make it optional, in part because they 
realized some people would be hacking it out anyway, and at least this 
way it's a known option with known implications in terms of bugs, etc, 
not the unknown, causing unknown mayhem and confusion in bug reports, 
etc, were people left up to their own devices to kill it, as I was doing.

As with kde4 it's unlikely the mainstream binary distros will disable the 
baloo/semantic-desktop option, in part because kdepim and thus kmail 
requires that support, but at least now it's an upstream-viable option, 
for any users and/or distros that do choose to build-time disable it, or 
for source-based distros like gentoo, expose the build-time option to the 
users.


Meanwhile, FWIW, I've seen those badwindow log messages too, but haven't 
any more clue than you do on what they actually mean, given their 
occurrence on systems that to all appearances other than that appear to 
be functioning normally. <shrug>

-- 
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