Sadly it won't help, since Yakuake cannot access profile options and thus doesn't know when to follow that option.

*** This bug has been marked as a duplicate of bug 214547 ***

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.  Clearly that is not how konsolepart works at the moment.  Each konsolepart is limited to run only one session, or more precisely only the session created using the default profile.

It is not hard to make konsolepart show tabbar and support multiple tabs itself. 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? 

Putting above question aside, if konsolepart provides tabbar itself, that would introduce another problem for yakuake since yakuake has its own tabbar.

So make a short summary:

1). the feature requested in this report and bug 214547 won't work unless konsolepart supports multiple tabs itself
2). it is unlikely for konsolepart to support multiple tabs in the near future

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:

  * QString currentWorkingDirectory() const;   (already done)
  * void createSession(const QString& profileName=QString(), const QString& dir=QString() );
  * QStringList profileNameList() const ;

Another needed change is konsolepart should stop creating session automatically. That means yakuake and other hosting applications need to call createSession(...) explicitly after getting an instance of konsolepart.

@Eike, please read my thoughts in http://lists.kde.org/?l=konsole-devel&m=133242676514410&w=2. I would like to hear about your idea.

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

> 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;
}

Hm, I wonder if you even need that 200ms timer. You could possible just use QMetaObject::invokeMethod() with QueuedConnection, i.e. make it return to the event loop. The KPart-creating code is blocking, so it gets to call createSession() before returning to the event loop. Feels less hacky than timing-based.

I have started to use yakuake recently and after some tunning I'm loving it. However I have been affected by this bug, which is very annoying and makes the daily usage of yakuake a no-go for me.

Fortunately I was able to fix it by applying the patch proposed by Mathias Panzenböck  https://github.com/panzi/Yakuake/commit/e5668b2ce4d142070631374306667f3e3a3d8369 which is more or less the same patch attached at bug #214547 https://bugs.kde.org/attachment.cgi?id=38333

The patch is working for me, and the "start in same directory as current tab" feature now works perfectly. I wonder if this patch could be applied to current yakuake meanwhile a better solution is not found.

*** Bug 329441 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> Fortunately I was able to fix it by applying the patch proposed by Mathias
> Panzenböck 
> https://github.com/panzi/Yakuake/commit/
> e5668b2ce4d142070631374306667f3e3a3d8369 which is more or less the same
> patch attached at bug #214547 https://bugs.kde.org/attachment.cgi?id=38333

I also use this patch now. It works great. My custom yakuake repository that also contains other changes (see README) is located at: https://github.com/worblehat/yakuake
I also added an option to the behaviour settings dialog to enable/disable this feature.

I know that this introduces redundancy with the Konsole profiles and it is not a very clean solution, but I this feature is really important to me.

(In reply to comment #0)
> Recently in the konsole git repository, the developers have added
> currentWorkingDirectory() slot[1], I hope this will help.
> 
> [1]
> https://projects.kde.org/projects/kde/kde-baseapps/konsole/repository/
> revisions/a7f71fe903df30b9aaa27f02df35d0eef92fb597

Could this be used in the Terminal's currentDir() method of the mentioned patch? I don't know how to access methods from Konsole::Part there. Is this even possible?

*** Bug 341659 has been marked as a duplicate of this bug. ***

@Eike, what would you recommend if I would like to enable the 'start in same directory as current tab' functionality?  The links to the patches proposed above point to git forks of Yakuake.  Should I remove my current package (yakuake 2.9.9-3 from Manjaro Linux community repo) and install from one of these forks instead?  Or should I replace just (a) particular file(s)?  Are there plans to integrate this patch into the official Yakuake?  If so, I could just wait a bit.
Thanks

The patches proposed here are workarounds that don't actually implement the profile option properly, so they can't be integrated as-is nor shipped in a release. If you feel the patch is good enough for you feel free to apply it. I currently can't say when a proper fix might be written.

Thanks Eike,

I'll take your word that the patches are not implemented properly and stay with the official yakuake package.  It sounds like this might be harder to achieve than I expected.  I'm not sure if the setting checkbox does work in certain circumstances, otherwise, you may consider removing this setting until a solution can be found.

Thanks again for Yakuake!

^ The checkbox is actually not part of Yakuake, it's part of the Konsole KPart component which Yakuake embeds. The bug is basically that it doesn't work outside Konsole itself.

OK, I understand now.  Thanks for the explanation.  All the best!