[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konsole-devel
Subject:    [Konsole-devel] [Bug 297222] "Start in same directory as current tab" doesn't work
From:       Eike Hein <hein () kde ! org>
Date:       2012-04-03 22:55:03
Message-ID: bug-297222-5030-UngOwRD591 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=297222

--- Comment #3 from Eike Hein <hein@kde.org> ---
> That "Start in same directory as current tab" option won't work at all unless konsolepart itself \
> provides its own tabbar and supports multiple tabs, just like stand-alone Konsole.

This isn't necessarily true. KonsolePart instances could use D-Bus to
communicate among themselves and figure out what the CWD of the active instance
in the app with the same pid is at creation time. I agree that's difficult to
implement, but it's certainly not impossible.

(I actually wonder if the code is already half in place because syncing
colorschemes may work similarly already, though it might also be based on
KDirWatch.)


> However, that makes me wonder what a konsolepart is intend to be. Is it intended to be a simple widget \
> which can be embedded into other KDE applications to get a terminal, or is it intended to resemble the \
> features of stand-alone Konsole as much as possible? 

KonsolePart should be a simple widget. However, its API should be sufficiently
broad to reimplement Konsole on top of the KPart. Basically, Konsole is
currently misarchitected: The KPart is just an afterthought, and both the KPart
and the main app use lower-level private APIs. This often causes the KPart to
bitrot, and means there is no pressure on the KPart API to be complete. Konsole
should be rearchitected to use its own KPart, to make sure the KPart API is
complete. This is how apps like Kate, Okular, Konqueror and others do it.


> But, that doesn't mean it is impossible for yakuake to resemble that feature from stand-alone Konsole. \
> It should be relative easy after konsolepart adds a few slots like these:

APIs to enumerate the available profiles and spawn a session with a particular
profile are indeed needed by Yakuake to finally implement session management,
so I like your proposal.

However,  it also needs a way to get at profile _options_ since
same-dir-as-current-tab is optional in a profile.

> http://lists.kde.org/?l=konsole-devel&m=133242676514410&w=2

Damn, sorry, I missed that mail and no longer have it in my email client
because I had to wipe some folders due to quota ... I will reply here:

While changing the interaction model to require explicit session startup and
expose the options Yakuake needs while implementing that would definitely be a
huge improvement for Yakuake, I think it's sadly not acceptable to break every
KPart-using app around, at leastn ot before KDE 5 - app devs will burn your
house down.

Is there maybe some way we can make a TerminalInterfaceV3 with the new behavior
and leave V2 behaving as-is?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
konsole-devel mailing list
konsole-devel@kde.org
https://mail.kde.org/mailman/listinfo/konsole-devel


[prev in list] [next in list] [prev in thread] [next in thread]