Hi VDG,

KWin has an awesome feature to configure the window decoration buttons. With the switch to KDecoration2 this needs to be slightly reworked. I initially thought that we could just reuse the existing dialog, but well it might be a good idea to spend some more time on it, because, well look for yourself:



Yes that's I think the KDE 1 window decoration.

Technically we can do much better. As you had seen in my yesterday's topic I have a QtQuick component which can render a window decoration. So that should allow us to design something new.

Oh and the two checkboxes don't apply any more.

Isn't this dialog a control module (KCM)? If so, we should finalize the basic layout.

Heiko Tietze wrote:Isn't this dialog a control module (KCM)? If so, we should finalize the basic layout.

it's part of a KCM.

Now concerning a different layout: sure could be done. It would mean more work on the implementation side - lots of work I don't have time for. Thus if a different design would be used and we don't find new developers (sorry, I'm a realist) I would have to use the old dialog, because I can integrate that in well one to two hours and we need to have something for 5.2.

My last comment sounds overly negative which was not my intention. I just wanted to point out that the design process shouldn't go in a direction where the result cannot be used due to lacking developer resources.

mgraesslin wrote:My last comment sounds overly negative which was not my intention. I just wanted to point out that the design process shouldn't go in a direction where the result cannot be used due to lacking developer resources.

We can work within constraints, no problem, but of course we have to know what the constraints are, as we cannot guess them.
So what could be changed in a new design easily enough and what would take too much effort?

colomar wrote:We can work within constraints, no problem, but of course we have to know what the constraints are, as we cannot guess them.
So what could be changed in a new design easily enough and what would take too much effort?

that is a difficult question. At the moment the UI consists of a QML based list view which shows a preview of an active and an inactive decoration. In addition there is a filter bar and some buttons which open further dialogs. Changing anything from this basic layout means lots of work. If you want to present the previews differently, that might be possible.

* 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")

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

luebking wrote:* grid (not list)
* bigger icons
* text below (or tooltip)
* ideally current deco buttons as icons

Yes to all, basically anything that gets it closer to what the Firefox Customize mode looks and feels like would be a plus. A list simply isn't very drag & drop-friendly.

* Simpler explanation text: "Drag and drop buttons into and out of the titlebar" [1]

"Drag buttons onto the desired position on the titlebar or drag them out to remove them."

* a11y: Extra lineedit(s) for keyboard only control (ie. you can enter just "X:T:IMA")

Good point

[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"

What do you mean by "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.

True. How about a checkbox "Allow applications to replace the window title with custom widgets" to make it clear?

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

+1000. Configuring the position of DWD widgets centrally makes zero sense, given that we can never know which combination of widget a specific application may use.

colomar wrote:What do you mean by "at two positions"?

Atm. when you start dragging a button, it remains at its position and at the same time appears as DnD icon (until it has a new position)
Imo it should disappear from titlebar as soon as the DnD started.
The list is (maybe, a bit) different: The spacer indeed does copy (not move) and dragging it from the list to anywhere that is not the titlebar would return it to the list anyway.

True. How about a checkbox "Allow applications to replace the window title with custom widgets" to make it clear?

+1

I'm starting to get an idea what needs to be done on the technical side to provide a QML ui for it. Will try that on Monday, but for the QML side I'll need someone to do it, my knowledge is not sufficient to implement something with drag'n'drop

Is QML somehow mandatory?

luebking wrote:Atm. when you start dragging a button, it remains at its position and at the same time appears as DnD icon (until it has a new position)
Imo it should disappear from titlebar as soon as the DnD started.
The list is (maybe, a bit) different: The spacer indeed does copy (not move) and dragging it from the list to anywhere that is not the titlebar would return it to the list anyway.

Oh yes, absolutely! This is also one of those "the closer it is to how Firefox does it, the better" kind of points.

luebking wrote:Is QML somehow mandatory?

no, but it still might be easier to develop (and change lateron) than using QPainter

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.

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.

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

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)