Re: How to not restore a konqueror session? (KDE4)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thomas Michalka (MLs) posted on Fri, 02 Oct 2015 00:48:29 +0200 as
excerpted:

[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[1] 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 
gone.

---
[1] 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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.




[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux