[Konsole-devel] Review Request: SessionManager should always read/write config entries from/to konsolerc, instead of <hostApp>rc

Wed Oct 5 16:17:52 UTC 2011

> On Oct. 3, 2011, 11:48 p.m., Kurt Hindenburg wrote:
> > " I guess the design intention is to allow konsole and host apps have independent settings for favorites/shortcuts"
> > 
> > Yes I believe that was the case.  I could see wanting different profiles visible for konsole versus yakuake/kdevelop/etc.  Do you really think no on else would?
> > 
> > I also don't see any issues w/ allowing kparts to open the 'manage profile' dialog.  If they can edit any of konsole's profiles, why not add/etc them?
> > 
> > I'm open to what other people think...
> 
> Jekyll Wu wrote:
>     So we have different idea about the second & third problem. That's fine. 
>     
>     What about the first problem ? I really think that inconsistent read & write should be fixed. Either read & write from konsolerc, or read & write from <App>rc, but do not read from konsolerc and write to <App>rc.
>
> 
> Eike Hein wrote:
>     > And AFAIK the only host app which actually uses that action is yakuake. 
>     
>     Which happens to be a highly popular application and certainly the most serious user of the KPart, so I'd suggest care with "only" :).
> 
> Eike Hein wrote:
>     Actually, let me expand on that for a moment. I realize it's a bit of a thread hijacking, but then again the above touches on fundamentals of Konsole development, so it seems appropriate.
>     
>     Konsole development unfortunately has a track record of developing the main application without much regard for the KPart; it frequently bitrots, causing problems for users of what's actually one of the most prevalent ways of tapping into the application's codebase, i.e. a KPart-hosting app. That's not really OK: Whoever develops Konsole should do so in the awareness that it's not just one application, but in fact a platform technology, a provider to *other* applications. It has responsibility toward its downstream users in terms of API and general stability.
>     
>     The truth is that Konsole is currently misarchitected. Rather than the KPart being a separate shell around the core classes, the KPart should be their primary interface. I.e. the Konsole application should be a relatively thin wrapper hosting the KPart, similar to how apps like Kate/KWrite and Okular are set up. That would necessarily force the KPart's API to be complete and maintained, and make it a lot easier for Konsole to live up to its dual responsibilities.
> 
> Kurt Hindenburg wrote:
>     Jekyll, go ahead and have the read/write to the same file - I would say <app>rc to allow kparts and konsole to have different defaults.
>     
>     Eike, the lack of KPart development has been that way since the 3.x days.  Since it is not used in the main Konsole, it is easily forgotten about.  A few times, long ago, I brought this up to Robert, but his opinion was to keep Konsole and the KPart separate.  If someone has the interest and energy to try, that's fine by me.
> 
> Jekyll Wu wrote:
>     Kurt, I prefer konsolerc for 'DefaultProfile' at the moment. Yes, that is not the ideal way and is not consistent with Favorites/Shortcuts settings, but I think that is the more friendly way for most existing host apps. Before we get a better solution(for example, allow consumers of kpart to decide using separate or shared settings), just use konsolerc for 'DefaultProfile'.
>     
>     Eike, I like that idea of making konsole just another consumer of the kpart.That reminds me of the relationship between gnome-terminal and vte. I would like to do some experiment in the future.
>     
>     BTW, I am also a heavy user of yakuake. That 'only' is definitely no offense.
>     
>     
>

I think that the DefaultProfile should be written to the apprc file. Use case examples: Imagine someone using KDevelop, a user of the KPart, exclusively for Python programming. Someone like that might want the KDevelop Konsole docker to use a profile that starts a Python prompt by default. Another app using the KPart is Konversation, which allows making Konsole tabs because some people like to keep their MUD client running next to their IRC chats because of the similarity in the activities - having the default profile start the MUD client makes sense then.

Perhaps the logic should be a mix, actually: Load the DefaultProfile specified in konsolerc, unless a different one was written to apprc. Then the KPart would inherit the Konsole setting unless it is overridden in the KPart.

> BTW, I am also a heavy user of yakuake. That 'only' is definitely no offense.

Nice to hear, thanks :).

- Eike

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102756/#review7060
-----------------------------------------------------------

On Oct. 2, 2011, 3:15 p.m., Jekyll Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102756/
> -----------------------------------------------------------
> 
> (Updated Oct. 2, 2011, 3:15 p.m.)
> 
> 
> Review request for Konsole.
> 
> 
> Description
> -------
> 
> The first problem(bug #251062) is SessionManager always read the 'DefaultProfile' entry from konsolerc, but always write that entry into <App>rc. That makes no difference when using konsole directly. But when konsole is used through the kpart way, It causes reported problem. I think this inconsistent read/write must be corrected.
> 
> The second problem(bug #257708) is SessionManager always read/write the Favorites/Shortcuts entries from <App>rc, instead of the konsolerc. Again, when konsole is used through the kpart way, it causes confusion. I guess the design intention is to allow konsole and host apps have independent settings for favorites/shortcuts. But I feel that is over design.Most apps and users only expect/need konsole kpart to provide an plain embedded terminal where a shell is ready for use. They do not need/care the ability to open a new session with some favorite profile using some shortcut.
> 
> A related but bigger question is : Is it necessary for konsole kpart to provide the action for opening the ManageProfilesDialog? As mentioned above, 'Favorites' does not make much sense for host apps and 'Shortcuts' is already hidden. And AFAIK the only host app which actually uses that action is yakuake. 
> 
> 
> This addresses bugs 251062 and 257708.
>     http://bugs.kde.org/show_bug.cgi?id=251062
>     http://bugs.kde.org/show_bug.cgi?id=257708
> 
> 
> Diffs
> -----
> 
>   src/SessionManager.cpp 38bc703 
> 
> Diff: http://git.reviewboard.kde.org/r/102756/diff/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Jekyll Wu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20111005/d50f8dd2/attachment.html>