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