mgraesslin wrote:Did some hacking today:



This is a screenshot of a small QML GridView with all the available buttons from Breeze window decoration. If that looks like a good approach to you, I can finish up the code to make it workable.

That definitely goes in the right direction! Three things:
- Either the text is tiny or the buttons are huge, both of which isn't ideal, but I guess that can be changed easily
- Could the labels be centered below the buttons?
- I see two icons missing (application menu and quick help). Does that mean they're still missing in Breeze and we need them asap in case some users actually use those buttons (which is quite likely especially in the case of application menu)?

You know, to make it look like... well... like this:

andreas_k wrote:cool. How looks the on all desktops and help icon look like?

they don't exist (yet). Or differently put: my drawing with QPainter knowledge combined with "I don't see the issues" is not sufficient to transform the mockups to code

andreas_k wrote:Do you need some help? I made the yakuake breeze theme (https://dl.dropboxusercontent.com/u/164 ... uake12.png) so when you send me the source file, maybe I can help. (to be honest, I'd like to learn QML so it would be a pleasure to help)

At the moment that is mostly not QML, but C++ patches against breeze and kwin relying on unreleased software. I'd be very happy if you would take over doing the QML part, but right now it still needs more work on the C++ side

can I play with the source code?

colomar wrote:That definitely goes in the right direction! Three things:

This is a proof-of-concept screenshot. It will never become the working system. Yes the text size can be changed, yes the text can be centered, yes the missing icons need to be implemented in the breeze theme, but it won't be fixed in this proof-of-concept code

andreas_k wrote:can I play with the source code?

not today, I need to cleanup the code first.

mgraesslin wrote:they don't exist (yet). Or differently put: my drawing with QPainter knowledge combined with "I don't see the issues" is not sufficient to transform the mockups to code

If you pass me a link to the mockups (you've problems with), I'll send you some QPainter code. Seriously...

luebking wrote:

mgraesslin wrote:they don't exist (yet). Or differently put: my drawing with QPainter knowledge combined with "I don't see the issues" is not sufficient to transform the mockups to code

If you pass me a link to the mockups (you've problems with), I'll send you some QPainter code. Seriously...

it's the QML decoration in kde:breeze and currently I failed creating the quick help button (a questionmark) and the on-all-desktop (a pin). The basic drawing code is in kde:breeze branch graesslin/kdecoration2.

Yeah, but I don't see the mockups (any svg, png etc.) for those buttons there...?

luebking wrote:Yeah, but I don't see the mockups (any svg, png etc.) for those buttons there...?

right they are no real mockups, what I meant was "usable QML mockups" :-P.

luebking wrote:Is QML somehow mandatory?

When something is awesome as QML it is!

But in all seriousness, I know I've always been happy doing my programming in C++, but from what I've seen of QML while trying to wrap my head around it - it's a wonderful technology that makes life indefinitely easier while producing better results. In terms of UI, the difference in ease and power is about as extreme as switching from Assembly to C++.

luebking wrote:* grid (not list)
* bigger icons
* text below (or tooltip)
* ideally current deco buttons as icons
* s/--- spacer ---/Spacer/
* Simpler explanation text: "Drag and drop buttons into and out of the titlebar" [1]
* Ignore DWD [2]
* a11y: Extra lineedit(s) for keyboard only control (ie. you can enter just "X:T:IMA")

Yes, yes a thousand times yes. ++ to ignoring any DWD considerations.

luebking wrote:[1] The current dnd is imo suboptimal - it should be sufficient to drag a button out and drop it *somewhere* out of the titlebar to remove it there and add it back to the list. For this purpose, the drag should react immediately (ie. the button is either in the list, the titlebar or under the mouse - not at two positions"

[2] You don't want to explain DWD to the user, not have him to pick a position or something. At best, there'd be a checkbox to explciitly turn it off for any decoration.
The DWD block [3] would usually seek to replace the caption area, so if we allow to position it left or right of the caption, that'd be a lie - and if we enforce a caption, we'd pretty much defeat the entire DWD thing.
For DWD cases where the DWD block would want to keep a caption string (menubar), a label should be included in the DWD block (which would likely be shorter than the canonical title string, reminder: we ned to adjust the visual name properties accordingly)

[3] Yes, block. We could add eg. sliders and icons, but cannot guess (nor need to know, nor should limit) their meaning, nor I believe it would make sense to allow the user to configure:
prev|play|next|caption|position|volume|menu <- and now interleave this with items for things that are not a mediaplayer.
If this needs do be configurable, this should be done in the client which also knows the item meaning for free.

[/quote]

DWD (at least as I envision it) does not apply to this configuration utility at all - and should be ignored completely in this tool. (I'm going to talk in terms of my DWD draft spec for reference, Martin might have radically different designs in mind); I foresee DWD 'taking over' the title area and application menu, but not interacting with the deco buttons in any other way.

In addition I'm rooting to leave DWD layouts up to the application, as we simply don't know what widgets the applications will 'want', nor do we how how they'll want them laid out, in addition global configuration settings on transient widgets is just confusing; users might assume something like a volume slider would be universal to all apps and remove it - or get confused why not all apps show the defined widgets. Anyway, if DWDs would impact this dialogue later (such as adding advanced settings) we should just cross that bridge when we come to it, though at that pint it's just adding things, not overhauling it.

About the only thing I might suggest in anticipating DWDs would be;

• The ability to add visible separators (which would fall back to spacers on unsupported decos)
• The ability to set and adjust the hard size of spacers

We also want to consider "simple by default, powerful when needed"; Things like raw text input and stuff like that should probably be moved under a "more" menu in favour of the drag'n'drop editor. I think Thomas was absolutely correct in suggesting we look at Firefox config, so this is what I came up with;


source: https://share.kde.org/public.php?service=files&t=9dde4c0f37eab64dc693445533e4479b

mgraesslin wrote:

andreas_k wrote:can I play with the source code?

not today, I need to cleanup the code first.

OK, screw it. I did the clean up

You need:

• kde:kdecoration (branch master)
• kde:breeze (branch graesslin/kdecoration2)
• kde:kwin (branch graesslin/kdecoration2)

After installing kwin you can use qmlscene to run the following QML test code:

Code: Select all

import QtQuick 2.1
import QtQuick.Controls 1.2
import org.kde.kwin.private.kdecoration 1.0 as KDecoration

Item {
    width: 800
    height: 800
    KDecoration.Bridge {
        id: bridgeItem
        plugin: "org.kde.breeze"
    }
    KDecoration.Settings {
        id: settingsItem
        bridge: bridgeItem
    }
    KDecoration.ButtonsModel {
        id: buttons
    }

    GridView {
        id: grid
        model: buttons
        anchors.fill: parent
        cellWidth: 200
        cellHeight: 200
        delegate: Item {
            width: grid.width
            height: grid.height
            KDecoration.Button {
                id: buttonItem
                width: 150
                height: 150
                bridge: bridgeItem
                settings: settingsItem
                type: button
            }
            Text {
                text: display
                anchors.top: buttonItem.bottom
            }
        }
    }
}


file:///home/src/KDE4/breeze/windec/package/contents/ui/test.qml:3 module "org.kde.kwin.private.kdecoration" is not installed
[removing "private"]
file:///home/src/KDE4/breeze/windec/package/contents/ui/test.qml:3 module "org.kde.kwin.kdecoration" is not installed
$ ls /opt/kwin_master/lib/qml/org/kde/kwin/decoration
AppMenuButton.qml ButtonGroup.qml Decoration.qml DecorationButton.qml MenuButton.qml libdecorationplugin.so* qmldir

Stracing qmlscene-qt5 for "open" and either "decoration" or "qml" or "quick" doesn't lead anywhere - "qml" and "quick" show the Qt libs, and that's it.

Let's say, I don't like QML at all.
I don't like declarative "programming" (where I describe what I want and the machine guesses what I actually meant... yeah, sure) in the first place and I don't like the meaningless abstracted error messages either.

Everyone can of course do as it pleases him, but I for one will stay away from it as far as I can.

I spent today on finalizing a new button configuration. The result looks like this:



It's all QML, so if someone wants to improve on it: please do so