Re: [kde] How to not restore a konqueror session? (KDE4)
- Date: Fri, 2 Oct 2015 00:45:12 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde] How to not restore a konqueror session? (KDE4)
Thomas Michalka (MLs) posted on Fri, 02 Oct 2015 00:48:29 +0200 as
[General discussion around kde session-save.]
> Would be a greater pleasure if KDE could save, open and close each
> virtual desktop separately.
> I want to be allowed to restore each virtual desktop separately on KDE
> startup as well as at a later time when I want to load a certain
> desktop. Of course I want to be allowed to close one or more certain
> desktops when I don't need them longer and want to open them again at
> any time later during the current session or a later one.
> Would be the greatest pleasure if KDE could do all things above and
> additionally could restore all LibreOffice windows -- what better could
> we get? ;-)
The original vision in kde4 was, if I'm not mistaken, to associate apps
(and specific documents opened with them) with plasma activities, and let
plasma reload them when the associated activity was loaded. Plasma
activities, meanwhile, would take over some of the functionality that has
traditionally been associated with virtual desktops, but very
specifically would *not* replace them, allowing the two concepts to be
used orthogonally , so that, for instance, activities would have multiple
virtual desktops, and loading an activity would load not only associated
apps and docs, but associated virtual desktops, placing the apps and docs
as they were either configured or happened to be laid out when the
activity was last opened.
However, due both to user pushback and to having to keep general
compatibility thru the kde4 series, this was never fully implemented in
kde4. Tho I believe people who understand what activities were
originally intended to be, also tend to believe that most of the early
user pushback was simply because people didn't understand the ultimate
vision involved and thought from the introductory state that
functionality they depended on was being removed or confusingly
duplicated, when it was simply a relatively early implementation, which
when fully done, wouldn't remove existing virtual desktop functionality
or simply duplicate it, but instead, make it /much/ /much/ more powerful,
in much the same way that kde4's desktop and panal plasmoids took the
concept of panel widgets and make /that/ far more powerful.
While for various reasons I don't have a kde-frameworks/plasma5 setup
up and running yet, from all I've read, plasma5 generally allows a fuller
implementation of what plasma in kde4 wanted to do, but couldn't, because
by the time it got ready for it, compatibility restraints had locked it
in and it couldn't make that major level of changes in kde4 any longer.
None-the-less, unlike the kde3/kde4 transition, the kde4/plasma4/
frameworks5/plasma5 transition is intended to be more incremental, with
the technologies and user facing functionality in frameworks5/plasma5
being much more logical and incremental extensions of elements already in
kde4, while kde4 was much more a disruptive "paradigm shift".
I guess I'll see how well I believe they actually did when I get a proper
frameworks/plasma5 setup up and running, but the point I'm trying to make
in all this is that almost all of the wishlist functionality you
described was actually envisioned and intended for kde4/plasma4, but for
various reasons including the real time necessary to implement in code,
and compatibility guarantees eventually locking in an incomplete
implementation in kde4/plasma4, it couldn't be completed in kde4/plasma4.
However, the kde-frameworks5/plasma5 implementation will have broken some
of those restrictions and should have allowed, or will eventually allow,
a more complete implementation, tho I personally haven't yet been able to
properly test it to form a personal opinion on how well the effort has
 Reasons: Namely, that I tend to highly customize my desktop
environments, exploring the limits of their power, which means that major
version upgrades take quite some time to recustomize, and I couldn't get
the early start I tried to, because early versions of kwin5 were crashing
on my system, and then for about a year I was too busy to do much with
it, particularly so since various bits of of 5 are incompatible with 4,
which meant that in ordered to test, I had to at least temporarily kill a
working kde4 installation in ordered to even test a frameworks/plasma5
installation that had earlier been entirely broken/crashing. So between
the high level of customization requiring a rather longer than normal
configuration time, and early versions of frameworks/plasma5 crashing...
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
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.