3. Overall menu stack to provide innovative UIs, using existing panes and HUDs
Use Case
Many many dtk
-based implementations of platforms share the same code base. Their development lead to many dtk
inspired patterns that are forked again and again. No more.
-
Make dtk
reliable through versioning and packaging (Thanks @nniclaus) -
Handle the evolution of dtk-*
and update platforms accordingly-
Refactor (move) generic code -
Update source accordingly
-
-
Enhance existing UIs and patterns -
Handle platform identity through a set of themes (extending Qt's stylesheet mechanism but not as such)
State of the art
- dtk already provides non
Qt
standard Ux interfaces that leverage its assumed possibilities beyond the use ofQML
- as non standard implementations, they rely on a deep understanding of Qt's internal
- including the event loop
- including platform abstraction plugins (!) since:
- Mutter (GLIB/GTK-based) compositing is a thing
- Aqua/Cocoa is yet another
- Works on M$ but dunno why
- Actually relying on low level features, we can guarantee safe usage
- works on all (manually though) tested platforms
-
dtk
extends the yet excellentqss
(Qt stylesheet system) to handle mixing as in less, through the fucking simple but useful dtkWidgetsStylesheetParser - Currently misused:
-
dtkWidgetsOverlayPane -
dtkWidgetsOverlayPaneItem -
dtkWidgetsOverlayPaneScroller -
dtkWidgetsOverlayPaneSlider
-
Facts
- it is really difficult, even though examples exist, to instantiate these Ux's and maintain them
- many addons exist but are not yet used
We R not alone
- More and more Qt's more or less standard implementation exist with more or less success
- Deepin's system settings integration into the desktop is an excellent successful and respectable example
- However it is implemented in
QML
- Yet another language is always a showstopper when it comes to meeting the group's common skills
- We can do even better in plain
C++
(QML
's just a binding) - We wanna share knowledge
Proposal
- Forget about the awfull menu standard pattern and UX counterpart
- It is however useful and somehow mandatory
- Turn it into something sexy, ergonomic, self understanding
- Using our legacy, that is the tweaks of WM implementations using Qt in our applications
Facts
- More and more platform specifics use
workspaces
- Should this be
intra
orextra
workspace, we need a combination to present possibilities in terms of actions (let's face it, callbacks to UI's elements) - Whatever the scope, this combination ends up in a local specification of
menus
,menus items
,sub-menus
andsub-menus items
- However, if the logic makes no doubt, their graphical counterpart is jurassic and meet end chain Tk implementations, resulting in something just boring
- Besides, navigating through such a stack should have evident visual counterparts
- Hence exposing
dtkWidgetsOverlayPane*
- But these R not stone engraved
- They rely on simple Qt tweaks and usage patterns
- Can be composed or extended
Proposal
- Implement a
Qt
compliantDeepin
inspired pattern for the set of our platform specific counterparts. -
dtkWidgetsMenuBar -
dtkWidgetsMenu -
dtkWidgetsMenuItem -
dtkWidgetsMenu [Composite and Recursive !] -
dtkWidgetsMenuItemContentsfallback to existingitems
!
-
-
-
inherit, compose or reimplement either overlay
orhud
dtk
's patterns -
bind their items
Even more
- Shortcuts (especially keyboard ones) R very efficient, but cryptic
- Make them self documented
- Make them sexy
- Make them non invasive
- Make them useful
- Leverage
HUD
(Heads Up Display)dtk
's implementation-
Bring back sw2d
's (@pferni's) implementation. See #7 (closed).
-
StyleSheets
WorkSpaces
-
if applicable, provide a visual counterpart and selectable workspace browser. Moved to #8 (closed).
To the infinite and beyond
-
Provide generic items as dtkWidgetsMenuBarItem
overloads-
about
dialog counterpart (using dtk application attributes) -
theme
dialog counterpart (usingdtk-theme
)-
Implement settings through dtk-themes
-
-