KF6 meeting notes 2021-09-27

[Volker Krause]

https://phabricator.kde.org/T12212
* search providers are used by apps, not just Plasma, so the move to Plasma 
seems wrong
* David E doesn't remember creating the task, now considered a bad idea

https://phabricator.kde.org/T12098
* not a kf6 blocker, could happen later

https://phabricator.kde.org/T11948
* Alex has a local patch using enum for common actions:

namespace KAuthorized
{
  Q_NAMESPACE
  enum GenericAction {
  SHELL_ACCESS, // if the user is authorized to open a shell or execute shell 
commands
  GHNS, /// if KNewStuff is authorized
  // GUI behavior
  LINEEDIT_REVEAL_PASSWORD, /// MOVABLE_TOOLBARS
  OPTIONS_SHOW_TOOLBAR, /// RUN_DESKTOP_FILES
  // Session management
  LOGOUT, ///
  START_NEW_SESSION, ///
  LOCK_SCREEN, ///
};
Q_ENUM_NS(GenericAction)

const QMetaEnum metaEnum = QMetaEnum::fromType<KAuthorized::GenericAction>();
return 
KAuthorized::authorize(QString::fromLatin1(metaEnum.valueToKey(action)));

* all-upper case is against API conventions, but allows direct use in string 
conversion, considered acceptable
* not considered a performance hot path

* adding action labels and/or a KConfigXT-like format/generator is not 
considered a kf6 priority, could be split out into a separate task

https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/76
* does applyMainWindowState() really need to be virtual?
* session save/restore uses this mechanism as well, and rely on the ability to 
change the config group
* some applications do override applyMainWindowSettings() and touch the state 
restoration code (e.g. Konqueror regarding special status bar handling)
* KMainWindow needs to call applyMainWindowState (not in the MR yet)
* is everything in KMainWindow actually state, ie. does the split even make 
sense? toolbar configuration could be configuration rather than state? state 
is covered by session management, configuration is directly stored
* behavior compatible idea: add a new setter for a state config group, use 
that for state when present, Alex will explore that
* good test cases: Dolphin (complex state saving logic), KWrite/Kate (enables 
KMainWindow::autoSaveSettings)

https://phabricator.kde.org/T14895
* https://tcanabrava.github.io/2021/09/20/kconfig-alternate/ - related, but 
much simpler than KConfigXT
* do we still need the kcfgc file at all, can't that be passed as command line 
arguments to the kconfigxt_compiler directly?
* pick better defaults to avoid having to specify a lot of this in the first 
place
* customizing the input file name is particularly problematic for the CMake 
integration, so moving that from kcfgc file would help a lot
* customizing the source file extension isn't practically doable right now 
anyway, as it's hardcoded in the CMake integration
* Header extension configuration is only needed in one place in our codebase 
(see https://phabricator.kde.org/D19565), but might be different on the 
outside
* Specifying full output names might be a more powerful and nicer way to 
replace the extension customization options

https://phabricator.kde.org/T14856
* David F to look into that
* the string overload can be deprecated, the others seem useful

https://phabricator.kde.org/T12232
* see task comment, David F added a proposal there
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20210927/f26d65fe/attachment.sig>