D20169: Add profile support interface for TerminalInterface

[Maximilian Schiller]

mschiller added a comment.


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

REPOSITORY
  R306 KParts

REVISION DETAIL
  https://phabricator.kde.org/D20169

To: mschiller, hindenburg, #konsole, #frameworks, cfeck, hein
Cc: pino, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20190421/283c2694/attachment.html>