proposal: permanent dialog setting templates

[meik michalke]

Am Donnerstag, 14. Juli 2022, 22:32:47 CEST schrieb Thomas Friedrichsmeier:
> What does give me a bit of a headache is the UI. I fear, we are a bit
> on the complex side, already. This feature add to that, and may not
> be entirely self-explanatory, either. We'll probably also want to add a
> "Reset" feature at the same time (bringing the dialog back to
> defaults), and let's not forget about the capability to remove stale
> templates.

UI is an interesting point, and like i said, i wasn't sure about that either. 
to some it might not be self-explanatory to have all dialog controls on the 
right side, now that i think about that. dialogs usually show those above 
(before me i see the message editor of kmail) or below (the usual "ok" vs. 
"cancel" buttons).

the button type for "send" in this kmail dialog does a good job at reducing 
complexity but allowing for it still: klick it and the default "send" action 
is done, keep it pressed and it shows more options, indicated by a tiny 
downward arrow. this could be used to replace "submit", "close" and perhaps 
the "auto close" checkbox with one "submit" button that also offers "close" 
and "submit and keep open" as additional options (or the "auto close" checkbox 
as we have it now, as checkboxes are also supported by this button type).

the preview section could be put into a "preview" dropdown button that offers 
checkboxes for "code" and -- if available -- "results". it's one more click 
and would function more like the "open"/"create"/"save" toolbar menus we have 
in the main window, but it would clean up the UI.

maybe a "settings" or "templates" button in a similar fashion would then also 
do the trick here, and put all further options in it's menu. on the right hand 
side we'd have then

  [submit] (simple click means "submit")
    click and hold:
      [close]
      [x] auto close

  [settings] (simple click shows menu:)
     [load settings]
     [save settings]
     [plugin defaults]
     [manage settings]

  [help] (simple click opens help page)

  [preview] (simple click shows menu:)
     [ ] code
     [ ] results

the ID of the recent settings template could be shown in the dialog title, 
like

  the dialog defaults:
    Basic statistics [default settings] -- RKWard

  if settings were changed and not saved:
    Basic statistics [unsaved settings*] -- RKWard

  if settings were saved as "my preferences":
    Basic statistics [my preferences] -- RKWard

  if custom settings were changed and not saved:
    Basic statistics [my preferences*] -- RKWard

i imagine the default should be to offer to overwrite previous settings with a 
warning if they were altered and [save settings] was chosen, and not force to 
use a new ID for each refinement.

if we want an option to load custom settings as the default, this could be 
part of the [manage settings] dialog, which would otherwise be used to rename 
or delete templates.

> Of course we could hide most of it behind a single hamburger button?

a single hamburger button for my taste would increase the risk of users not 
finding helpful stuff at all. i'd rather have a few buttons with text, like an 
invitation to explore an option that sounds interesting.

> Further points that would need consideration: If we allow for several
> templates per dialog, is one of them loaded by default, when opening the
> dialog?

that should be an option, in some cases that would speed up common tasks.

> Is one of them saved, automatically (aka "most recent settings")?

interesting idea. i don't know if it's terribly useful, as it looks like a 
lucky bag for me if "recent" is older than half an hour, but it could be 
another option in the [settings] menu.

> And would that auto-saving happen only on "Submit" (least
> surprising behavior) or also on "Close" (useful with previews)?

in ardour (DAW), IIRC, some plugins do this by storing most recent settings 
without a name but a time code, i.e., you have the last bunch of them to re-
apply them in a dropdown menu. perhaps RKWard could do the same and add 
"submitted" or "closed" to the time code for information. but this sounds like 
the most complicated part of the whole idea so far ;)

> And somewhat unrelated, but while we're at it:
> - Would it make sense to remove the "Close" button (since you can also
>   simply close the dialog, as any regular window)?
> - Where (if anywhere) would the "Auto close"-checkbox go?

see above :)


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  institut f"ur experimentelle psychologie
  abt. f"ur diagnostik und differentielle psychologie
  heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20220716/d18b7648/attachment.sig>