[Konsole-devel] Review Request: SessionManager should always read/write config entries from/to konsolerc, instead of <hostApp>rc
Kurt Hindenburg
kurt.hindenburg at gmail.com
Tue Oct 4 16:38:30 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.
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.
- Kurt
-----------------------------------------------------------
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/20111004/77bd7245/attachment.html>
More information about the konsole-devel
mailing list