Can someone from the frameworks group clarify if this can be committed for the next release 5.58 next month? I know years ago, we had a TerminalInterfaceV2 because the interface was changed.

https://community.kde.org/Schedules/Frameworks

Yes, this change breaks the binary compatibility. Please add a TerminalInterfaceV2 that inherits TerminalInterface instead, or add a separate interface for profile handling.

General notes on the API (not a konsole developer though):

• an abstract virtual destructor is needed
• in kdelibs/kf5 lingo, the "get" as prefix of API getters is generally not used
• setCurrentProfile instead of changeCurrentProfile? the latter makes me think it does changes to the current profile, rather than setting another profile as current
• wrt changeCurrentProfile: what will it do if the specified profile name does not exist? should the API return true/false to indicate the switch actually succeeded?
• wrt getProfilePath: what if an application does not store a profile as single filename, for example as directory, or even stored e.g. in a DB? maybe it would be better to have this as property of a profile
• is a setProfileProperty worth having?
• is an API to list the available properties worth having?

Also: this file is still not installed, so it cannot be used. Maybe just add the new interface to the existing kde_terminal_interface.h?

wrt getProfilePath: what if an application does not store a profile as single filename, for example as directory, or even stored e.g. in a DB? maybe it would be better to have this as property of a profile

Yeah Konsole Profiles seem to already have a path property in the profile implementation. So gonna remove this.

is a setProfileProperty worth having?

I don't think it would be good to have the user applications mess with the users customizations. In case the profile is somehow "incompatible" with the client application, exposing some profile management functions (e.g. copy and modify) might be useful but I can't think of an actual reason which would require that.

is an API to list the available properties worth having?

Just to check at runtime if getting a property was successful returning an empty QVariant should be enough, because you need to look up the available properties to check the returned type anyway.

Please fix the API getters: in the KDE/Qt world, getters never start with 'get': just use availableProdiles() etc.

Similarly, I suggest to rename changeCurrentProfile() to setCurrentProfile().

Could you provide an updated patch?

Ping

@hindenburg: lgtm, could you comment?

I would prefer using TerminalInterfaceV2 in the current file instead of a new file. It would make using it much easier to use, document, etc and when kf6 comes out, easier to re-combine.

ping

In D20169#473105, @mschiller wrote:

ping

I was waiting until the next release of frameworks is out.

5.59 Sat June 1st, 2019 (expected) Sat June 8th, 2019

Oh sry, I wasn't aware of that.