DWD HIG Draft

[Sebastian Kügler]

Hi Ken,

On dinsdag 17 mei 2016 10:49:08 CEST Ken Vermette wrote:
> We have our first serious formal proposal for the DWD HIGs and the
> functionality we are looking for; here's a link to the publicly editable
> Google doc:
> 
> https://docs.google.com/document/d/1mYzHjcuDitWmk99syjC0xzQPPmyUrpL_29_s3-2Y
> l_g/edit?usp=sharing
> 
> I'd like to invite anyone with a stake in this to make edits/suggestions.
> Once we have any rapid-fire editing done I'll pretty it up and put it on
> the wiki; if editing wrecks the formatting in the doc that's fine. It
> contains a general overview of functionality, the first four widgets we're
> looking to implement, and a list of widgets which I'll be writing out once
> we're satisfied with the current documentation and direction.
> 
> It may also be good to fill in technical or implementation details in the
> doc so anyone reading the wiki can be on the same page. If anyone has any
> concerns about anything please bring them up so we can hammer it out.


Thanks for the nice write-up. I've commented on some details in the Google 
Doc. Here's some of the gist of it:

My overall thought is that it's getting too complex already, and that it's 
also getting too use-case specific. It all seems to revolve around window 
decorations, and while that's one use-case, it limits the usefulness and 
apparently invites to introduce protocol-level problems.

The DWD thing should not just be a way for desktop apps to put stuff into 
window decorations. I see it much more as a "remote control" for apps, a thing 
which can be also used in a task manager on a phone, or from a remote machine 
of whatever form factor.

One thing that immediately struck me as a departure from our original design 
is the introduction of layouts. That's something that I really don't want to 
do, for the following reasons:

- it requires assumptions by the client (app) how the controls are displayed, 
  but what if the DWD is being rendered twice (once in the task manager, once 
  in the windeco, once on a remote smart phone)?

- layout semantics over DBus is just going to be very painful and complex and 
  will take forever to be made stable

- the whole point of DWD is to not make assumptions about layouts, but let the 
  "renderer" (window decorator, task manager, or sth like that) decide how and 
  what to display (priorities help with the decision)

- it brings in a whole slew of added complexity, size hints, size policies, 
  different sorts of layouts, etc.

In short: layouts are against the basic design idea and hardly feasible from 
an implementation point of view. 

This also means, that anything done in DWD needs to adhere to these 
assumptions, and be very easy to communicate over the wire.

Then, there's some stuff in there that I don't understand, buffers, where the 
command button comes from, where the simple action button went, for example, 
and the fact that menus are in fact actions with hierarchy attached.

I've all put these comments inline.

In general, I'd like to see more focus on baby steps, because even in the most 
minimal version outlined by this HIG, it's still a large amount of work, so 
we'll need more granularity and probably more reluctance in dreaming up stuff.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org