[Konsole-devel] [Bug 297222] "Start in same directory as current tab" doesn't work

[Jekyll Wu]

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

Jekyll Wu <adaptee at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adaptee at gmail.com

--- Comment #4 from Jekyll Wu <adaptee at gmail.com> ---
> 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.)
> 

That "syncing colorschemes" is a side effect of the fact that there are global
objects shared by all instances of konsolepart for managing profiles, sessions,
colorschemes, etc. No dbus magic at the moment.

> 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.
> 

Yeah, I remember you have already mentioned that in a previous review related
with konsolepart. I think that is good, but unlikely to happen in the near
future. That kind of big change would probably introduce as many regressions as
the KDE3=>KDE4 change. I'm simply not confident now.

> 
> > 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.

I'm conservative about exposing those profile options to hosting applications.
They are so internal that hosting applications should not be aware of them.
I'll recheck whether that "same-dir-as-current-tab" can be processed within
konsolepart.

> > 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?

Yes, breaking existing hosting applications is a bad idea. I will try to keep
existing
hosting applications unaffected. Here is the big problem of the current
konsolepart:

Part::Part(...)
{
    ....

    // the last operation!
    createSession();
}

As I have mentioned in above link, moving that "createSession()" out of
constructor is not only needed to give hosting applications more control, but
also is needed to fix the broken implementation of TerminalInterface. 

Here is the rough idea for keeping existing hosting applications unaffected:

Part::Part(...)
{
    ....

    // for compatibility 
    QTimer::singleShot(200, this, SLOT(createSessionCompatible());
}

void Part::createSessionCompatible()
{
    if (_sessionCreated) 
        return;

    kWarning() << "Method createSessionCompatible() is for keeping
compatibility with previous broken implementation"
    kWarning() << "Hosting applications are encouraged to call
createSession(...) explicitly after getting one instance of konsolepart."
    .....
    _sessionCreated = true;
}

void Part::createSession(...)
{
    if (_sessionCreated) 
        return;
    .....
    _sessionCreated = true;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.