Re: 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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: DWD HIG Draft

[Martin Graesslin]

On Wednesday, May 18, 2016 4:21:20 PM CEST Ken Vermette wrote:
> Update;
> 
> After feedback we made some moderately heavy changes to teh DWD
> requirements, namely removing/changing 'priority groups' in favour of
> 'layouts'.
> 
> Instead of the application firing off widgets with a "spray & pray" manner
> via priority groups, we're using layouts. With layouts the application sets
> a primary layout, and can switch to contextual layouts later. The primary
> layout has to be accepted as-is otherwise DWDs will be disabled for that
> window.
> 
> Layouts can specify the order and size policies of widgets, but only for
> the area inside the canvas - an application can't try to scramble
> user-defined buttons. Applications can swap layouts if there's a contextual
> need, but the DWD can reject them if there's an issue, telling the app to
> provide traditional controls.
> 
> We will specify how things should be laid out by applications in HIGs later
> (basically, it's what the required layout was before), but this will let
> applications use discretion if something would be awkward. More information
> on this can be found under 'Widget Placement" in the doc.
> 
> Document link:
> https://docs.google.com/document/d/1mYzHjcuDitWmk99syjC0xzQPPmyUrpL_29_s3-2Y
> l_g/edit?usp=sharing
> 
> This upcoming weekend is a long weekend here, so I'll have time to put this
> on the wiki and make a blog post. If anyone wants me to hold off for more
> feedback please let me know.

Maybe give sebas a chance to read over it. I try to remember to mention it in 
the meeting on Monday.

Cheers
Martin

> 
> Cheers;
>  - Ken
> 
> On Tue, May 17, 2016 at 10:49 AM, Ken Vermette  wrote:
> > Howdy!
> > 
> > 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-> 
> > > 2Yl_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.
> > 
> >  - Ken



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: DWD HIG Draft

[Ken Vermette]

Update;

After feedback we made some moderately heavy changes to teh DWD
requirements, namely removing/changing 'priority groups' in favour of
'layouts'.

Instead of the application firing off widgets with a "spray & pray" manner
via priority groups, we're using layouts. With layouts the application sets
a primary layout, and can switch to contextual layouts later. The primary
layout has to be accepted as-is otherwise DWDs will be disabled for that
window.

Layouts can specify the order and size policies of widgets, but only for
the area inside the canvas - an application can't try to scramble
user-defined buttons. Applications can swap layouts if there's a contextual
need, but the DWD can reject them if there's an issue, telling the app to
provide traditional controls.

We will specify how things should be laid out by applications in HIGs later
(basically, it's what the required layout was before), but this will let
applications use discretion if something would be awkward. More information
on this can be found under 'Widget Placement" in the doc.

Document link:
https://docs.google.com/document/d/1mYzHjcuDitWmk99syjC0xzQPPmyUrpL_29_s3-2Yl_g/edit?usp=sharing

This upcoming weekend is a long weekend here, so I'll have time to put this
on the wiki and make a blog post. If anyone wants me to hold off for more
feedback please let me know.

Cheers;
 - Ken

On Tue, May 17, 2016 at 10:49 AM, Ken Vermette  wrote:

> Howdy!
>
> 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-2Yl_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.
>
>  - Ken
>
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

DWD HIG Draft

[Ken Vermette]

Howdy!

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-2Yl_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.

 - Ken
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel