Wonders from a KDE fan and developer about some KDE design choices
Technologies going forward..
Twenty years ago, I was reading some books about Unix at the local library. By the time, it was really difficult for me to see, touch, or test an actual unix system and reading books was the closest I could get.
I remember that among the numerous very good ideas ™ in this system, one totally buzzed me : processes and memory protection. A piece of software was protected from other pieces. If one crahes, the other ones could still keep on doing their stuff. Amazing feature, isn’t it ??
Years later, and until very recently, I could proudly say to my friends: “I use linux, I don’t have such problems that you have in Windows and MacOS”. Well, of course, now at least MacOS is based on a serious kernel and the Windows kernel is far better in this regard. But still, unix has had it for very long, and among them, my favourite Unix : Linux.
… forward …
And then, people started to talk about plasma. It is cool, it is great, it is beautiful. One of the reasons I like KDE so much, is that I am very happy with the technology choices made by the project over the time (do you remember the drop of CORBA ?). I’m not into buzz and fancy desktop, so I did not pay much attention to plasma at the beginning. Later on,Β I started to try KDE trunk again. For months, it was about: compile, start, wait few seconds, plasma crashed, and the whole desktop/X session restarted.
Then, it got better : plasma crashing would not make the whole session crash, and plasma would handle its own crashes gracefully by restarting. Trust me, I really like KDE, but I could NOT resist to think “Hey, they now handle crashes as well as MS Word do!, great job!”. Well, of course, It was still pre-alpha times, you are not supposed to expect more at this time.
.. and backward
Still some months pass by, and came the beta time. I could finally get into KDE and plasma would not crash on startup. So I tried this new plasmoid thinguy. I added few plasmoids, played with them, even configured some. I tried to add a new one… and WLANG, suddently the whole thing crashed.
Do you see my point ? One of the plasmoids made the whole plasma thing crash. We are back 30 years ahead in time. End of process separation and memory protection. Back to the “don’t try to touch anything, it WORKS, don’t disturb it” and “I do not dare trying this new cool stuff because it could crash it all”.
Design
This sounded weird. Really, really weird. I wondered, and learned that indeed plasma was only one process. It seemed to me like a very bad design choice, but I do not know much about all of this, so I just kept my faith in KDE and did not worry too much. I don’t know anything about internals. I talked to a few people, on IRC, in real life… but nobody seems concerned. Nothing about that on the FAQ, not even on the (short) architecture documentation.
As time goes by, people put almost anything into plasma. I mean it : anything. Developers and users for once seem to agree, and everybody is happy. I still do not really understand the need to put a browser in a plasmoid, but if people enjoy that, I don’t have a problem with this. Free software is all about fun, isn’t it ?
After I updated to KDE 4.2.1, I’ve spent one hour to fix it, finally removing the plasma configuration files to get a usable system. I did not look further, but I guess I could have removed only one part of one file, or maybe even just remove a faulty plasmoid.
I don’t mind the hour I’ve spent… but I worry about the design of plasma. I do not dare asking plasma people, as it seems so.. deeply obvious. They MUST have thought about it, mustn’t they ?
A trend in KDE ?
Today I had to kill one of my konsole because one of the software I’m working on was eating all the memory. I used the great CTRL-ALT-ESCAPE kill feature and that saved my computer. Once recovered, I was really surprised to see that all my konsoles were dead. “ps” could confirm this. I usually have 4 or 5 konsoles with 5 or 6 tabs each. Lot of opened vi inside and so on. A doubt came to me and i started several new konsole, and then issued a “ps aux | grep konsole”. You’ve guessed it, only one was present. I rushed on konsole source code and konsole/src/main.cpp confirmed my fears : konsole uses only one process on purpose, through the use of KUniqueApplication.
I don’t understand and I’m sad about this.
Conclusion
Don’t get me wrong , I still think that a lot of things are still done right in plasma (and KDE in general): separation between data and views (nothing new, but still a great thing to do), packaging (though it’s not done yet, I like the ideas). And it looks darn good, that’s right, too.
I just feel very uncomfortable with this. This is the first time ever in more than 10 yearsΒ that I am not happy with a KDE design choice, and a blog post looked like a great way to release this embarassment. As usual I’m afraid that people will read this post lightly, will feel insulted, and will answer with even more insults.
Post details
- Categories: Gentoo KDE
- Published: November 10, 2009
Amen. Amen.
We really need to look at re-factoring some of these things. This is just a guess, but I am wondering if the current trend toward all-in-one-process is intended to save resources. Since the whole shared library concept doesn’t work so well anymore, you can save a lot of resources by packing several instances into the same process instead of duplicating library loading.
Perhaps someone with more knowledge than me can comment?
With plasma the thing is having per-plasmoid-processes creates massive performance impacts (something to do with qgraphicsscene’s complexity and stuff), so C++ (binary) plasmoids are stuck for the time being with the ability to crash plasma. It’s not like the issue is just being ignored though π The scripting plasma bindings are maturing, and with scripted plasmoids plasma would be able to take care of plasmoid crashes without dying. So the ‘workaround’ to the whole issue would simply be to avoid binary plasmoids like the plague (except the ‘safe’ ones that come released with plasma), and work with scripted plasmoids as much as possible π
I think sir that you have valid points here but I also know that multi-process design is technically so much harder to achieve.
While crash-mitigation by design would be superb I somehow question the viability of such solution on whole KDE-scale. See Chromium battling the cross-platform issues for example. The above is no expert opinion and I would be happy to hear some smarter voices on this.
You are right, one konsole should not crash all konsoles… nor in the XXI century, hehe.
I don’t know about this, but using the Chromium from the dev channel, it only crashed twice in months of use. They use many threads or process, and it works!
@Jason: While scripted plasmoids might mitigate the entirety of plasma crashing, they still have a long way to go before achieving the goal (i.e. https://bugs.kde.org/show_bug.cgi?id=204997 ).
The reasons for in-process C++ plasmoids has been talked about before by the plasma devs. I can’t help thinking an email to said devs (they’re pretty easy to track down…), sending a mail to the mailing list or popping onto #plasma and raising your issues there might have been a politer way to go about this than a planet published blog entry
if you don’t like it that plasmoids run in-process: please solve in a reasonable fashion the need to paint several individual components on the same canvas with reasonable performance and in a way doesn’t compromise the interaction capabilities we have. post your patch to plasma-devel and we’ll all be overjoyed to receive it.
personally i’d like DataEngines to be run out of process at some point (at least optionally) as that would give us a few benefits with hopefully nominal downside in terms of performance, but the painting issue is rather more thorny than to be able to casually suggest that’s how it could be done.
now, if you had asked one of us involved with plasma directly instead of writing a blog entry hoping it hits someone in the right place, you would have been told directly about scripting frameworks, something we started building into place right from the start. it’s where we’d like to see the majority if not all plasma plugins end up and it opens doors to improve various kinds of common stability issues. (though there are some remaining features in qscript needed to really let us take advantage of the possibilities. not everything can be laid at our feet here.)
i might also suggest that if you don’t like the idea of having a bunch of widgets laying around on your desktop because it might compromise its stability … don’t.
there are also some factually incorrect statements in your entry here, e.g.: “the whole desktop/X session restarted.” if it was truly the case that your x crashed, then that’d be your x.org driver. NOT plasma. of course, this doesn’t stop people from thinking plasma is why anything goes wrong, regardless of where. the reality is that there are bugs in x.org, there are bugs in x.org drivers, there are bugs in HAL and in solid, there are bugs in phonon and phonon’s back ends.
and that has precisely zip to do with plasma’s design. even if every plasmoid was in its own process, if x.org crashes now it will crash then too.
you may also wish to look at kparts which is also in-process and goes back to kde 2.0, konqi’s pre-loading, kontact, etc. and reconsider how “new” this whole idea is.
i get it that you may not agree with some decisions made; that’s life and not unusual. but personally i don’t agree that blogs are where design discussions should be held, particularly when they will lead to others holding (or holding onto) misconceptions that some of us will now spend even longer having to debunk.
Apps like Konsole and e.g. Kate should be separate processes unless chosen otherwise by the user.
But I can also see that separating widget processes in Plasma is not an option and I agree with Jason that focus should be on improving the plasma scripting bindings. Plasmoids should stay what I guess they are meant to be: small widgets giving/exchanging information. If implementing this in a scripted language becomes too resource heavy it should be reimplemented as a separate C++ application.
Google’s Chrome on Linux has each tab in a process and it is EXTREMELY FAST and uses generally less memory than Firefox on Linux (64-bit) would with the same content. I also have had only handful of crashes on Chrome using it for last 2 months. I agree. When advancing technology is heading to more and more cores and virtual threads, why go backwards?
On the other hand, when KDE tackles the ‘technical challenges’ to multi process and multithreading, look what happens: Nepomuk. Case in point. It’s a total disaster.
I think it’s a big problem. If others don’t think it is I don’t know I guess they’re happy to settle for less.
It seems to me the reason for making Plasma one single process is that you can’t really embed/render a QGraphicsItem from a different process, and that this heavy GUI integration is kind of a design goal for Plasma.
However, your points make a lot of sense, I personaly wonder why did Robert Knight go through the extra effort to use KUniqueApplication (the SVN log indicates that he strated of by looking at Kate’s sources, so perhaps that’s where the reason is).
Anyway, the interesting thing is that Kate itself itself no longer uses KUniqueApplication, and it stopped doing so more than four years ago — http://websvn.kde.org/?view=revision&revision=407855 . Now someone (that’s you, Thomas) should file a bug.
This “problem” is not really new, and it’s why plasma devs are pushing for scripted plasmoid.
14623 non7top 20 0 382m 84m 26m S 18 2.1 4:37.61 plasma-desktop
I’ve heard someone was talking about resource usage? And my desktop is only 30 minutes up, in 3-5 hours plasma will be eating much more resources (up to 1Gb ram and 100% CPU). I should also mention that chances that plasma will autostart with session are about 20% only. I do always start it manually.
But it is rather obvious now that the primary goal of plasma – to beat the kicker – is finally achieved. Plasma now is much more buggy, much more resource hungry while being much less functional. And it is after so many years of development and after KDE4.3. Too sad there are no simple alternative desktop/panel thingies in kde4.
If my memory serves me correctly there was a split of configfiles between 4.1 and 4.2 that caused som trouble.
When it comes to crashing plasmoids I believe it is rather uncomplicated to solve.
KDE-Look (And KDE-Apps) should establish versionfilters and all pasmoids++ should be verified as working before allowed into e.g 4.3.3.
A plasmoid made for KDE 4.1 and a old version of Qt should not be admitted into KDE 4.3 section at all. If the developers don’t want to update their plasmoids – it will die. If the plasmoid is good someone else may take it to the next version as a fork.
I also would like to see a better naming regime and a better structure (system/email/social/weather) and so on. I believe it’s time for KDE to take charge over this – it will become a huge mess otherwise.
Why are the plasmoids located in kde-LOOK anyway? Should it be placed in kde-APPS?
@Rsh: There is a great difference between Chromium and Konsole:
Chromium starts a new Process for each tab and embeds this into the main window. This is quite tricky and differs from Platform to Platform.
The effect: if a webpage does something bad, so that chrome crashes, this won’t pull the whole browser (with all open and still working pages) into nirvana, it will only show you a screen “this page crashed :(“, but the browser keeps running.
This is not the thing thomas wants in konsole.
Konsole uses the same process, if you have a running konsole app and open a new window!! So you may have several konsole-windows, but only one process! By default, you expect every running window being an own process.
Now, if one konsole window crashes (or gets killed due to a memory gathering script, or…), this will pull down the procees, and so kill all konsole windows. Bad, isn’t it?
And all only because of KUniqueApplication (which could be really useful in some cases…)
AFAIK it is the same with konqueror.
I’ve had very mixed feelings toward KDE 4 for a long time… As a fan of clean empty desktops, I can’t care less about Plasma except to reproduce Kicker’s autohide panels and I happen to totally hate the nonsensical configuration process… So far, the only impressive thing I found in KDE 4 is the search feature in Kate… And I use Konqueror 4.3.1 which is less flacky that Konqueror 3.5.10 but I still need Firefox… I wanted to update and give it a shot again… Now I think I’m just going to stick with the good old trusty KDE 3.5 for a longer while.
I agree with Thomas.
Plasma: While it may be a valid optimization to allow for putting most of Plasma into one or two processes, it seems to be serious desing flaw to *require* this optimization for everything. If the binary plasmoids are the plague, at least those should run in separate processes, no? And of course, the claim that scripted plasmoids are safe is wrong too. The scripting languages have the same expressiveness as C++, after all, so there is no way that Plasma can know what the plasmoids are up to.
Konsole: Moving to a singleton pattern when the program was working perfectly fine before without it is just mind boggling. Is this just so that you can move tabs between windows, or something?
I also wondered about this design decision, but I also guess it has to do with resources. And when I look at the mem usage of KDE, frankly I’m kinda glad…21st century or not. I’m surprised by the konsole case… I didn’t know THAT! π
One thing I always wondered: Why isn’t it possible to crash only single threads? A crashing thread always takes down the entire application. This is probably the safest thing for the general case. But shouldn’t an app be allowed to decide: I want this plasmoid in an own thread, it’s data is sufficiently separated from the other plasmoids, and if it crashes: stop the thread and notify me! Of course an evil plasmoid can still crash the app (no protection), but the common case of derefing dangling pointers and the like could be covered that way, while saving resources at the same time. But maybe I miss the obvious here… π
By the way, Plasma crashed for me recently during a presentation *without respawning*, leaving just a blank screen with some orphaned tray icons. The crash was in all likelihood related to changing the screen resolution for the projector, but I have not been able to reproduce it.
I was happy that I follow KDE development closely enough to know that presently you say Alt-F2 plasma-desktop when this happens. (It used to be Alt-F2 plasma, right?)
Thanks for keeping krunner in a separate process — even though for most users this would not actually help.
Just take a look at Jason’s answer that it covers most of the problems. It’s not easy (and feasible at all) to write a canvas based software that is multi-process without having a *lot* of problems. As Jason also pointed it out, scripted plasmoids are the way to go in the near features, so we can sandbox all the plasmoids and just have the ‘safe’ ones as c++ ones. This would enable us to save plasma from this crashes. It’s nice that you exposed your ideas and concerns, but it would be awesome if you had sent a mail to plasma-devel mailing list or just asked on #plasma @ freenode π
Cheers,
You should comment on this bug:
https://bugs.kde.org/show_bug.cgi?id=199754
Hey there,
nice article an thoughts, i agree with you that the plasma/kde devs have to think about this problem.
Thx for this article
I don’t know much about plasma internals but what I can tell you is that convert plasmoids-containers-etc in a separate process are not complicated. Why I can say that? because one plasma developer has done it for maemo. So, if you want to run plasma/plasmoids in your maemo 5 the only way to do it is per plasmoid process.
One crazy idea, is possible to use only 1 graphics view by using dbus?
Been considered already for plasma, Thomas π
http://bit.ly/2cCd3j
There is some light at the end of the tunnel.
http://bit.ly/1MeAce
http://bit.ly/40HQ4M
Rsh : KDE has a nice and stable IPC mechanism, working for years. So, it’s already available at the KDE scale, people should just think about using it more.
I share Thomas’s point of view. There are good reasons that we use separate processes for KIO, these good reasons should apply to plasma as well.
Jason: I though plasmoid had a separation between a data engine and a display engine. A first step could be that everything not related to display is hosted in a separate process. That would limit at least the crashes to the badly written plasmoids (or is it buggy QGraphicsScene and buggy display stack).
Have a look at the memory usage of some of those things you have just once, and multiply it by the number of pieces you’d like to split it into. That might answer some questions.
You should have just closed the window/tab instead of Ctrl-Alt-Esc. It would have achieved the same thing. A processing hanging in a terminal doesn’t make your terminal unresponsive.
Konsole wouldn’t be able to easily implement things like tab drag-and-drop were it not a single process. It probably wouldn’t be too inconceivable to allow it to host out-of-process terminal sessions a la Chrome, but it’s unclear that’s particularly worth it. Also, Chrome is similarly single-process anyway. It does something similar to have only one core-GUI process that handles all the windows. The only difference is that it spawns off separate processes to render the contents of each tab. The equivalent for Konsole would have been to have each terminal session out-of-process. Which, incidentally, would still have exactly the same Ctrl-Alt-Esc symptom you described.
A browser is big and complicated, whereas a terminal emulator is considerably less. The programs running in them may be, but if that crashes your terminal, your terminal has fairly serious problems.
(That said, it may be worth investigating out-of-process terminal sessions so that you could drag-and-drop sessions between Konsole and programs that use the Konsole KPart. I think, however, this could cause problems with existing apps. Certainly it could only be enabled for programs explicitly written to support this mode.)
Out-of-process plasmoids would be more worthwhile, but much more difficult to pull off. You’d essentially need to implement something like X.org + compositing manager instead Plasma. It’s not clear this makes any sense.
I had the same thoughts some days ago for different reasons: I’d like to know how much RAM is a certain widget eating. Well there are some ways like subtract usage before the widget to the usage after, looking at the whole plasma-desktop process, but also others widgets may change their ram occupation. Running the widget in the plasmoidviewer could be a solution but I think it uses more resources than just the widget.
In short Plasma reinvents the O.S. and that’s bad. I hope in future it will be split in processes, or will be great to run a group of plasmoids in a different process. Maybe “remote widgets”, witch should be available since 4.4, can be used to this purpose.
What I don’t understand is this:
Why doesn’t KDE integrate the plasma/widget features into KWin, so that every application can be a plasmoid, and every application CAN (but must not) use the plasmoid API.
This way the window manager takes the job of composing the widget on the screen, and the applications can run in different processes, as per usual.
Just my 2 cents.
@nathan : well, actually i once asked on #plasma around one year ago, and got no answer. But IRC being what it is and given the fact that I did not insist, I can’t blame anyone.
@aaron : this was a post about a user’s feedback, not as a developer. I repeat i know nothing about plasma and certainly could not patch anything there. I know the way to propose patch if I ever have one. I indeed use only very few plasmoids.
@aaron : Your point about X crashing is perfectly valid, indeed. I should not have mentionned it, sorry for this (though this was not the main topic of the post).
@jkt : if i fill a bug, I’m afraid people will trash me because my lack of understanding of my konsole design and optimization issues. If I don’t feel a bug, I’ll be called unfriendly. Now you put me in a difficult situation π
@maxilys : I did not like first releases of KDE4, but now i’m very happy with it (but few glitches, such as https://bugs.kde.org/show_bug.cgi?id=179144)
@redm : i like the idea of crashing threads, but I’m sure this is very difficult to achieve, and this is not KDE related, but rather belongs to the kernel π
@dotan : interesting, i’ve subscribed to the bug. But it seems it was filled several months ago and there’s no official statement from the plasma team, so it’s rather useless i think.
@jason, morpheuz, brian : thanks for the start of explanation and for the useful links!
@bluebird : using processes for ‘data engine’ is already talked about by the plasma team, if i understand correctly. Great idea π
@lubos : I’m not sure to understand. You really mean that if using processes for plasmoid, this would multiply the total memory used by plasma by the number of plasmoids ? This seems really weird to me, do you have some more details/arguments ?
@david : moving the mouse was already difficult, i could not wait some more and reaching the tab requires a context menu.. which is not possible in this case. But this is rather off-topic π
Thanks for the explanation though. I don’t use ‘drag&drop’ of tabs, so I’ll try to find a way to change the default on my computer to “use a new process”.
@charon : I also have this feeling that plasma is re-inventing lot of things. Especially when I read about “implementing layouts” and such. But maybe this is really needed, I honestly don’t know.
Agree, the design of plasma and konsole is broken.
As for plasma, it should not use graphicsview in the first place. It can just use native X windows for each plasmoid out-of-process. Qt developers are more than happy to keep making changes to GraphicsView without a second thought about performance and behavior. As you can see it’s become bloated over time and there seems to be some fetish of adding more and more APIs. These changes in Qt are heavily tying down Plasma causing one regression after another when updating Qt. Either, Plasma should write it’s own customized canvas or just use X Windows.
I love plasma. It’s simply great. At my computer plasma crashed the last time a long time ago. (4.1?)
Chrome? Sorry, but you can’t compare a browser and its tabs of rendered pages to plasma. There _should_ be no programmable connection between the tabs for example.
Or firefox: You can completely mess him up with extensions so is firefox badly designed?
(And this plugins are written in javascript)
It is a design decision and I trust the plasma team.
@Thomas: I’m not trying to be a planet cop or anything, but if you acknowledge that IRC didn’t work then why not try the mailing lists or a direct email? A blog entry like this seems more like a way of mustering up a public outcry than an honest attempt to get an answer to a technical question.
Reading the comments that many people have left here, you certainly seemed to have achieved the former quite successfully, with the few attempts at the latter almost lost in the noise.
@non7top There is actually, I think it is called blazer and is in playground somewhere. It was designed for use in remote servers.
Thomas, do you really think that it is convincing to argue that you, a KDE developer, posting in a blog on Planet KDE and addressing issues of software design, are actually posting merely “as a user”?
I believe that you post with your knowledge of software design and what you have learned about certain KDE applications, but you are too lazy to do the necessary “research” (that is, drop the relevant people an email with a question).
Unfortunately, this laziness leads to the obviously wrong conclusions (read Aaron’s, Lubos’s and David’s answers) and hurts not only the perception of KDE, but the relationship between developers and the user community.
There have been many tensions during the past few years, with users accusing the most visible KDE developers of doing things wrongly and doing the wrong things. It has been very difficult to overcome the misconceptions about software design decisions. And the repeated, ill-informed and sometimes hurtful criticism of some users has left quite some scars.
What you are doing with your post is feeding this problem by accusing developers of making the wrong decision without actually knowing anything about what you address.
PLEASE, do this differently the next time. Shoot an email to a mailing list. Can it be that difficult?
@mutlu: I’m not responsible (and actually not even aware) of the “bashing by users” you speak about. I’m not a KDE developer (I’d love to, though, but I lack time). You can’t just “shoot an email”, you need to actually subscribe, filter all emails, and such. It takes time, you quite often don’t have an answer, or you have bad answer from very touchy people that dislike criticism (when you just ask a question). Whatever I do, i got answer like yours that I do the bad way, I should do otherwise. (Actually i’m very surprised that “do it yourself, it’s free software” has not popped yet).
@nathan: I dont’ agree with you. It seems like lot of people are wondering too (both about plasma and konsole). And now at least they can find an answer, either by reading the planet or googling. I would have loved to find such an information myself.
@Thomas, really: you question a design decision and do not take time to send an email to mailinglist? Sure, it takes a little bit of time.
But if you really wanted some real discussion with developers, it is clearly what you should have done. Chill and stop being a martyr π
@Thomas: but I anyway appreciate the fact that you took the time to consider the problem, if there is one, and write about it. If these questions pop up here and there as you said, it is good if someone opens discussion…
@Thomas: I’m sorry that you seem to be getting a bit upset by this, but perhaps take a second to consider that if a couple of comments in a blog is making you upset, then what is the effect of the blog itself on the developers?
WRT to the public service aspect of this, the issue has already been addressed by blog posts by the plasma developers that were syndicated to the planet so this is rehashing previously traveled ground (Brian posted some links to existing conversations on matter for example).
Konsole is already multi-process line Chrome. If you type “ps uxf”, you’ll see each tab has a “bash” shell underneath.
The different “tabs” in the chrome top bar can’t possibly be drawn by the child processes. No way drag&drop can be so harmonious and integrated while being separate processes. What actually happens is:
– The main process draws the while UI + tabs
– The sub processses draw the “HTML area”.
Konsole does sort-of the same. Each tab has a “bash” sub process.
@redm One thing I always wondered: Why isnβt it possible to crash only single threads?
A process has it’s own memory space (it’s own “sandbox” to play in). When it corrupts it’s memory no other process will be affected by it.
A thread on the other hard, shares all memory with the rest of the application (2 children playing in the same sandbox). So if one thread corrupts memory, the rest of the process is taken with it.
—-
People, please trust the devs, they really know what they’re doing.
Honestly, I don’t expect anyone to know the how processes and threads work, but OTOH I find it strange the same people do question the design choices involving processes vs threads. First time explaining is nice (e.g. for a interested user), but if devs would have to explain this every time it would become very tiring.. π
Diederik, you miss the point. It’s not that one konsole window is a single process — of course it is, it was in KDE3 as well. It’s that even if you have fifty konsoles open in separate windows in separate virtual desktops, as of KDE4 they’re all one process, so one bug, one oom-kill and *whoom* *all* your shells have vanished. (And if it’s one great big process the chances of an oom-kill of it just shot right up.)
This would be bad enough with a normal app, but for a terminal emulator it’s cataclysmic: there could be a vast amount of state in all those shells and it’s all gone. You could have needed a working shell to clean up whatever it was that caused the crash: too bad they’re all dead.
And, the thing is? You know how often I’ve felt a desire to drag a Konsole tab from a window to another window other than that in which it originated? Never, that’s how often. Yet to enable this apparently useless feature the stability of konsole has been permanently damaged.
It really *is* worth having lots of konsole processes. Please let those of us who care more about stability than inter-window dragging have it back.
@nix : yes, that’s it, it’s really “cataclysmic” ! π
Maybe turning –nofork on by default will suffice. I’ll try it…