Version: (using KDE KDE 3.5.7) Installed from: Debian testing/unstable Packages OS: Linux My feature request is similar to the one described in konsole Bug 14919: Session Options Save. Every time I fire up kde and load yakuake all my sessions are gone. I usually create at least 7 sessions and name them accordingly - say for remote ssh sessions or tasks that I carry out on a daily basis. Named sessions make it a lot easier to remember what a particular session is about. It would be very nice to have the option to save all active sessions -- to start with just the ordered session names would be enough. Later it would be nice if the restored sessions could also retain the command history and maybe even the working directory from the time they were saved. At the very least it should be possible to restore all sessions after yakuake restarts. I love yakuake and this feature would really mean a lot to me.
Adding useful session serialization currently mainly depends on the KPart offering a way to retrieve the current working directory, so Yakuake can try to restore it (tracked in Konsole bug #156919). Beyond that, I'm also pondering UI to edit sessions (i.e. sets of tabs) and commands to be run in them at start. Note that right now, you can do this with the D-Bus (or DCOP, in the KDE 3 version) interface; I myself start Yakuake with a wrapper script that sets up my sessions. As for retaining command history, please note that this is a feature of the shell you're using in the terminal emulation and it's not feasible for Yakuake to store and rebuild it, as it's not under its control.
This would be very handy to be able to save sessions. I'd be happy to have it load the samo tabs/splits that I had. In addition to this loading the session profile and folder would be great. DCOP is ok, I was able to make yakuake load something with it but DBUS.. forget it.. Just too difficult. And all users should learn to use DBUS - doesn't sound like a plan to me.. Anyway, my votes for this feature over all other new features. Though bugfixes propably override wishes..
To reiterate, adding this to Yakuake requires new features in Konsole first. Since last week, there finally is some movement around implementing the necessary features in Konsole (and its KPart) for Yakuake to be able to do this, and if the proposed patches are merged there, there's a good chance that an upcoming Yakuake version running on KDE 4.2 (released January next year) will support session restore. It mostly depends on whether the necessary additions can be merged before the feature freeze for KDE 4.2 on October 11th. If they aren't, it's going to be KDE 4.3 six months later. As for DBus, it's just as easy (or hard, depending on how you look at it) as it was with DCOP. Here are some sample commands: qdbus org.kde.yakuake "/yakuake/sessions" addSession qdbus org.kde.yakuake "/yakuake/tabs" setTabTitle 0 "foo" qdbus org.kde.yakuake "/yakuake/sessions" runCommandInTerminal 0 "bar"
And dont forget about missing profiles at every kde session start, I don't know why, but I have 2 making profiles, and prom menu -> Changes profile -> nothing... ? Why? I don't know, I have to make menu -> Manage profiles and switch it to active... It's very poor. Best regads, yakuake kick in the ass ;)
@Przemek: I have the exactly same problem, using 2 profiles and I always have to go to menu -> manage -> 'show in menu' for both. And the funny thing is that the profile I create myself is shown twice in the menu.. I don't know if this all is about the same bug or not but it'd be very great to see it fixed - yakuake rocks!!
Sorry guys, I can't fix that one in Yakuake - profile management and the context menu you're talking about are part of the Konsole codebase / the Konsole KPart component that Yakuake embeds. You have to file a bug against Konsole.
*** Bug 192167 has been marked as a duplicate of this bug. ***
*** Bug 227652 has been marked as a duplicate of this bug. ***
*** Bug 238468 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Anyone know what's the status of Konsole regarding session management?
it'd be great to have yakuake at lease save/restore tabs with names. i'm going to try this https://github.com/aplatanado/yakuake-session for now.
any progress? Alin
Nope, sorry.
What does 'nope' mean? As far as I know Konsole now supports restoring tabs, not sure about splits. Based on what Eike said here https://bugs.kde.org/show_bug.cgi?id=149522#c3 it should now be possible to import the same features to Yakuake too. So is the status of this report 'not doable', or 'someone should just do it'?
"Nope" means both - no progress has been made, and it's also still not doable. Let's take a step back for a moment and talk about the root problem: When this feature wish comes up, as well as other wishes for features present in Konsole but not in Yakuake, most people assume that anything possible in Konsole should also be possible in Yakuake, because that's how they've known KDE to do things. After all, we have the KPart component model, and many of KDE's standalone apps are actually relatively thin shells around KPart components that get used in multiple apps. The Okular application, say, is a tiny little shell application around the Okular KPart, which is also used in Konqueror to display embedded PDFs. KWrite and Kate share the same KTextEditor KPart. And so on. Unfortunately however, the same is not true for Konsole. In Konsole, the main application GUI wraps around / uses the large (but badly designed in the sense that it'd not be supportable as a public API) private API of the chunk of code implementing session/tab management and terminal emulation. The KPart component Konsole installs also wraps around that API, but only exports a minimal part of it, meaning that applications using the Konsole KPart - like Yakuake - don't have access to the same feature set as Konsole itself. Most likely this has historical reasons, i.e. the KPart was added as an afterthought, and nobody had the time or vision to properly rearchitect the app and make the main GUI use Konsole's own KPart at the same time (which would have forced creating a proper, full API for the KPart). This isn't just at the heart of many "missing" features in Yakuake, but also many bugs the KPart has; from the POV of the Konsole developers working on the main app, it's easy to forget about maintaining the KPart equally well. Unfortunately Konsole also has a severe lack of manpower these days. The maintainer during the KDE 3 days, Kurt Hindenburg, originally had to resign during the early days of KDE 4 development due to lack of time, and passed maintainership on to Robert Knight. Robert did do quite a lot of work, but he didn't get into a full-scale rearchitecting like this. And then he disappeared from the scene as well. Kurt is back now trying to keep the worst bugs in check with what little time he has, which is great, but overall there's little forward progress on features or design cleanup - there's no one who has the time to come up with and implement a plan. Now, for Yakuake to save and restore sessions, you have to think about what data is in a session that has to be saved and restored: - The number of tabs, their position on the tab bar and their possibly user-set tab label texts, - The number of terminals in each tab, as well as the nesting order and handle positions of their splitter arrangements. - The current working directory of the shells running inside the terminals. - The Konsole profile used for each terminal. Of those four bullet points, the first two are entirely within the purview of Yakuake, and thus while they're definitely work to implement (and fwiw, I think Konsole doesn't go to the same length of e.g. preserving split setups correctly, but it's been some time since I tried), they're possible to implement. The latter two bullet points however require Konsole KPart APIs to get data in and out of KPart instances: - You need to be able to retrieve the current working directory. - You need to be able to change the working directory after instanciating the KPart and the shell having spawned. - You need to be able to retrieve the current profile. - You need to be able to instanciate the KPart with a given profile, or at least change the profile afterwards. - Possibly, you also need a way to retrieve the list of available profiles, so you can check whether the saved profile is still available (that largely depends on what behavior the KPart would chose to implement when being asked to use a non-existing profile, although listing available profiles would also be a key requirement for making a grapical profile editor). So let's look at those in turn: a) You need to be able to retrieve the current working directory. The KPart doesn't have an API for this. It does, as of KDE 4.3 or so, export a method that allows you to retrieve the process ID of the current foreground process. At least on the Linux kernel it appears to be possible to get from the pid to the cwd, but there seem to be problems on other Unix-like kernels KDE supports (at least I seem to vaguely remember reading about Konsole session restore having problems on *BSD due to that). So this may be possible to code up in Yakuake, at least for Linux. But it should really be done in the Konsole codebase and exported as part of the KPart API, so KPart-using apps don't have to duplicate this code, and so that there's always behavioral consistency between Konsole and KPart-using apps (assuming I remember right and Konsole also relies on pid->cwd - if it doesn't and it has a better way to do this, then the bottom line still is: should expose that in the KPart, because right now the only thing you can get from the KPart is the foreground process id). There are some other implementation details here, of course. The foreground process may not be the shell, it may be some other program. In fact, depending on the Konsole profile in use - which can be set to run any executable - there may not be a shell running at all. --- b) You need to be able to change the working directory after instanciating the KPart and the shell having spawned. The Konsole KPart exports a showShellInDir() method that can be called after instanciation. This essentially sends a cd command to the shell if it's running. That's more or less workable I suppose, although it's all a bit hacky and possibly prone to race conditions. What if the shell isn't ready by the time you send it the cd command, say? What if the shell's .bashrc or similar does anything to put it in a mode on startup where it will never be ready to accept a cd prior to user interaction? Konsole (most likely) has no way to tell, much less Yakuake. The bigger problems are in 'a', though - figuring out if it's a terminal you should even try to get the working dir for (depending on what's running, ...), getting the working dir, etc. --- c) You need to be able to retrieve the current profile. The KPart has no API for this. As mentioned, Konsole profiles e.g. control what executable is run, a shell, or maybe a CPython interpreter, or irssi directly or whatever. Obviously when saving and restoring a session you want the profile to be part of that, or there's not much point to the exercise. --- d) You need to be able to instanciate the KPart with a given profile, or at least change the profile afterwards. The KPart has no API for either of this. --- e) Possibly, you also need a way to retrieve the list of available profiles, so you can check whether the saved profile is still available. No API for this, either. It may not be strictly required for pure save and restore, but I think it'd be pretty neat if Yakuake could include an editor for session templates, and obviously the user would need to be able to select the profile of any terminal in the session template then, and in order to allow that selection you need the list of profiles. It *may* be required for save and restore if the KPart expects you to pass an existing profile name, however - after all the user could delete a profile from Konsole while Yakuake isn't running, that sort of thing. Mainly depends on the design of KPart API the KPart doesn't actually have yet ;). (Note: Some people may be going "But Yakuake can show a profile management dialog already!" at this and wondering. Yes, it can - except that dialog, in fact the entire profile management stuff, isn't in Yakuake, it's in the KPart. Yakuake can only poke the KPart externally to pop up that dialog. This is actually formally undocumented KPart API that was added in the early KDE 4 days on my urging.) --- snip --- Does that do the trick of explaining the "nope"? :)
Wow Eike, this definitely explains what 'nope' means and what's the status. So we really shouldn't expect this to appear in Yakuake in near (or far..) future. Thanks for all the work you do for Yakuake, we love it!
Personally I'm hoping we can sort of inch our way toward it. Right now you can sort of write session templates via external scripts that use D-Bus commands to set things up, except that you can't set the profile for a terminal due to the missing KPart APIs. I'm hoping to find the time to enhance the KPart API to add methods for listing the available sessions and instanciating the KPart with a specific profile. Once that is there, I can implement a graphical session editor that can set up tabs/splits/terminals-with-profile and run commands in the terminals. The editor would also have the ability to create a new template from the currently active setup, which would then reflect all the data it can retrieve already (like tab and terminal positions and so on, see above) and miss the data it can't retrieve yet (like CWDs and terminal profiles), requiring the user to fill those missing bits in manually for the moment. Then the next steps are to add further APIs to the KPart, like retrieving the profile and the CWD. And once the API set is complete, and the session editor can retrieve all the data about the active setup to save as session template, then the same code can be reused for automatic session saving and restore. Biggest problem there is my personal lack of time, too :). So if anyone listening in has even the slightest interest in working on any of these incremental steps, don't go "well, he's doing it already" - jump in, especially Konsole needs any set of hands it can get. I'll do my best to give implementation advice and review for patches.
it seems someone tried something https://bitbucket.org/eternicode/yakuake-sessions
And there was this too (for a while but recent API changes broke it) https://github.com/pjfl/p5-yakuake-sessions.git
(In reply to Eike Hein from comment #3) > To reiterate, adding this to Yakuake requires new features in Konsole first. > > Since last week, there finally is some movement around implementing the > necessary features in Konsole (and its KPart) for Yakuake to be able to do > this, and if the proposed patches are merged there, there's a good chance > that an upcoming Yakuake version running on KDE 4.2 (released January next > year) will support session restore. > > It mostly depends on whether the necessary additions can be merged before > the feature freeze for KDE 4.2 on October 11th. If they aren't, it's going > to be KDE 4.3 six months later. > > As for DBus, it's just as easy (or hard, depending on how you look at it) as > it was with DCOP. Here are some sample commands: > > qdbus org.kde.yakuake "/yakuake/sessions" addSession > qdbus org.kde.yakuake "/yakuake/tabs" setTabTitle 0 "foo" > qdbus org.kde.yakuake "/yakuake/sessions" runCommandInTerminal 0 "bar" Thanks for the tip Eike Hein! Could you please tell me where to put the DCOP commands? Would .bashrc work? Cheers
No, Yakuake needs to be running before the commands. You could write a script to start Yakuake and then run the commands, and put it into your autostart.
I'm using DBus to restore previous tabs. Isn't it possible that Yakuake itself saves this information and runs these DBus calls after it starts up? Wouldn't that resolve as least part of this bug?
*** Bug 379163 has been marked as a duplicate of this bug. ***
and I'm still using DBus to restore saved tabs. However, in recent Plasma you get warning that using DBus for this is "unsafe". I am still forced to use DBus though since there is no option yet to restore previous tabs.
I want to add that this feature would be really good, but as far as i understood the last post its unlikely :(
*** Bug 409832 has been marked as a duplicate of this bug. ***
If anyone here is still interested: https://invent.kde.org/utilities/yakuake/-/merge_requests/11 It should work fine: sessions, tabs, splits, working dir and profile are saved and restored. I have it marked as WIP because the error handling isn't that great, yet.
(In reply to Maximilian Schiller from comment #28) > If anyone here is still interested: > https://invent.kde.org/utilities/yakuake/-/merge_requests/11 > > It should work fine: sessions, tabs, splits, working dir and profile are > saved and restored. I have it marked as WIP because the error handling isn't > that great, yet. Hi. It's great what you are doing. It's much needed. Especially nowadays with popularity of rolling release distros that require frequent reboots. Laptop battery capacities also limited. It looks like your request is still not merged. I wonder why it's still not merged? Anyway, thank you.
Any reason this MR is not yet merged? https://invent.kde.org/utilities/yakuake/-/merge_requests/11
(In reply to Maximilian Schiller from comment #28) > If anyone here is still interested: > https://invent.kde.org/utilities/yakuake/-/merge_requests/11 > > It should work fine: sessions, tabs, splits, working dir and profile are > saved and restored. I have it marked as WIP because the error handling isn't > that great, yet. Hi, i have apply the patch to yakuake-21.12.3.ebuild and yakuake-22.04.1.ebuild on my gentoo but both dont work - no context menuentry is shown and no setting entry, is ther specific version of yakuake where it will work? Or are there any changes about yakuake or konsole that will not work anymore at moment?