Version: 2.9.8 (using KDE 4.8.0) OS: Linux I code using vim and my two screen setup consists on yakuake on the left, and a maximized console on the right. I hate having to minimize the konsole to check my email or use the browser. It would be very nice if yakuake could create one window per screen, instead of a global unique one. You could control them using F12 for the 1st screen, F11 for the second, and so on. It should be quite straightforward to implement and it'd make for a nice addition. Reproducible: Didn't try Expected Results: Awesomeness. OS: Linux (x86_64) release 3.1.9-1.4-desktop Compiler: gcc
> It should be quite straightforward to implement and it'd make for a nice addition. It's actually a ton of work to make a production-quality implementation, requiring modifications and additions in the configuration UI, settings load/store code, settings handling (e.g. the behaviour of the open-on-screen prefs), the D-Bus interface, keyboard shortcuts (routing, etc.), focus handling, window management (add/remove vs. app quit), etc. A rough estimate would be modifying 50% of the existing code and adding another 30-40%. It might also break scripts based on the existing D-Bus API or would at the very least introduce some compatibility cruft around the method calls operating on the window. It's a long way from a quick "hey, it spawns two windows now" hack to something that supports the entire existing feature set correctly, adds all the new features needed to manage the new behavior and doesn't make the UI a complex mess in the process. Especially the latter is a considerable risk. And I'm not convinced it's worth it.
>It's a long way from a quick "hey, it spawns two windows now" in that case please don't do it. yakuake is one of the few kde-apps I can trust and it should stay that way. Thanks for the fast response.
To be clear, I'm not saying it's a bad idea by itself or that it's never going to happen, just that I have to weigh the associated costs in UI and code complexity against how much extra use the current and potential userbase would get out of it, and as of right now I'm not convinced there's a clear case for it. However, bold ideas are still good; eventually to-dos sum up to requiring larger code and architecture changes and then they inform the new design. IOW, I'm mainly saying that you shouldn't expect a quick turnaround because if it's done it will require proper care to do it, and it probably won't happen before circumstances conspire to allow it to happen as part of other larger rewrites.
*** Bug 415641 has been marked as a duplicate of this bug. ***
*** Bug 409973 has been marked as a duplicate of this bug. ***
Hello, I did the below two lines of changes and compiled it. Now the second instance of yakuake seems to be working for me without any issues for a couple of months. I suggest that yakuake can take two extra parameters: ApplicationName and config file url. Maybe these two simple changes (as below) would be sufficient to run another instance of yakuake? If so, that would make us happy. Thanks. Two lines changed are: In main cpp: application name set to yakuake2 (using app.setApplicationName ) In yakuake.kcfg : yakuakerc is replaced with yakuake2rc
(In reply to ilkerk from comment #6) > Hello, > > I did the below two lines of changes and compiled it. Now the second > instance of yakuake seems to be working for me without any issues for a > couple of months. > I suggest that yakuake can take two extra parameters: ApplicationName and > config file url. Maybe these two simple changes (as below) would be > sufficient to run another instance of yakuake? > If so, that would make us happy. Thanks. > > > Two lines changed are: > In main cpp: application name set to yakuake2 (using app.setApplicationName ) > In yakuake.kcfg : yakuakerc is replaced with yakuake2rc Maybe you can get this into some nice solution that can get merged into Yakuake? I am sure there are developers willing to assist you when you need help.
(In reply to Claudius Ellsel from comment #7) > (In reply to ilkerk from comment #6) > > Hello, > > > > I did the below two lines of changes and compiled it. Now the second > > instance of yakuake seems to be working for me without any issues for a > > couple of months. > > I suggest that yakuake can take two extra parameters: ApplicationName and > > config file url. Maybe these two simple changes (as below) would be > > sufficient to run another instance of yakuake? > > If so, that would make us happy. Thanks. > > > > > > Two lines changed are: > > In main cpp: application name set to yakuake2 (using app.setApplicationName ) > > In yakuake.kcfg : yakuakerc is replaced with yakuake2rc > > Maybe you can get this into some nice solution that can get merged into > Yakuake? I am sure there are developers willing to assist you when you need > help. Developers explained their thoughts about the request in OP above. I think developers can do the two code changes I mentioned above less than a minute if they want to and if they believe changes won't cause any trouble. My suggestions above was a workaround, and by the way I'm using it daily and it has been working without any trouble. best,
(In reply to ilkerk from comment #8) > (In reply to Claudius Ellsel from comment #7) > > (In reply to ilkerk from comment #6) > > > Hello, > > > > > > I did the below two lines of changes and compiled it. Now the second > > > instance of yakuake seems to be working for me without any issues for a > > > couple of months. > > > I suggest that yakuake can take two extra parameters: ApplicationName and > > > config file url. Maybe these two simple changes (as below) would be > > > sufficient to run another instance of yakuake? > > > If so, that would make us happy. Thanks. > > > > > > > > > Two lines changed are: > > > In main cpp: application name set to yakuake2 (using app.setApplicationName ) > > > In yakuake.kcfg : yakuakerc is replaced with yakuake2rc > > > > Maybe you can get this into some nice solution that can get merged into > > Yakuake? I am sure there are developers willing to assist you when you need > > help. > > Developers explained their thoughts about the request in OP above. > I think developers can do the two code changes I mentioned above less than > a minute if they want to and if they believe changes won't cause any trouble. > My suggestions above was a workaround, and by the way I'm using it daily and > it has been working without any trouble. > > best, As I said, maybe you can get this into some nice solution that can get merged into Yakuake. Obviously the current workaround as it is is not suitable to merge. But I thought maybe you wanted to extent it in a way it could actually be merged. However, as Eike said above that might require major code refactoring.