activity configuration UI

[Marco Martin]

On Friday 30 March 2012, Aaron J. Seigo wrote:
> On Friday, March 30, 2012 10:17:15 Marco Martin wrote:
> > On Friday 30 March 2012, Aaron J. Seigo wrote:
> > > the buttons in the title do work, indeed... i wonder if they make more
> > > sense on the same side of the dialog together, but that's something i
> > > can experiment with easily enough on my own, though if we do buttons
> > > up there we need to get some agreed on UI standard for it.
> > 
> > i think if there are two and on opposite sides looks more balanced and
> > thumb friendly
> 
> yes, for two buttons .. i'm just wondering if that translates to other
> dialogs which may have more or fewer buttons and which should be
> consistent with these dialogs.

yep, this at the moment is just for the Sheet component, Dialog is still as it 
was

a problem of putting buttons there for normal dialogs is that they may get 
quite small so they could be too narrow for title+ a row of buttons

> > > and then if we move to the "tap outside to close without saving" as per
> > > Sebas' suggestion we get down to one button anyways and that's all a
> > > moot point.
> > 
> > that is already done, this is another old topic do we need a close button
> > in every dialog because is discoverable or try not having them that is
> > not obvious, but becomes easy once trained
> 
> i like the the idea of less buttons.
> 
> however, if we do want to keep the "close" button and if we put buttons int
> he title bar, it could be drawn exactly as we do the "close" button on
> plasmoids.

yeah, that's an idea as well

> > would basically look like a tooltip?
> 
> basically, yes, but with a "pointer" pointing to the element in question.
> bad ascci art
> 
> [ Already Taken ]
>      ^
>  |=/ \=======|
>  |
>  | Error mesage |
>  |
>  |=========|
>  |
> > in this case could be tap over to dimiss if cover something the user
> > doesn't want
> 
> yes, that would work ...

i did an experiment with a baloon tip for dialogs at a certain point.
it was abandoned because was quite difficult to be used in Plasma::Dialog but 
the graphics is still there (well, almost impossible due to the requirement of 
window mask in non composited case ;) 

if we stay with something just on-canvas in this case there would be no 
problem tough

-- 
Marco Martin