[Plasma] looks and usability of applet handle frame

Sat Jun 28 15:18:21 CEST 2008

IMHO, we should make a distinction between locked and unlocked state.

When widgets are locked, the click should work as usual, interacting with
the widget elements.

But when the widgets are unlocked, I interpret that we want to modify the
layout of the widgets. Then, the dragging action (1st button click starts
dragging the widget) should be favorized, as it is the most important action
in this state. I find also intuitive to drag the widget from almost
everywhere by default.

2008/6/27 Celeste Lyn Paul <celeste at kde.org>:

>
> Janz,
>
> I think we're on the same page.  Clicking and draging a widget (all
> widgets)
> makes sense. The some-widgets-are-cndable-and-others-are-not issue is what
> bothers me and I would like to see resolved in some way.  I don't care if
> there is a border or not or if the function icons move because I don't
> think
> it matters (i.e. it is probably on the personal preference level, not
> performance level).
>
> ~ C
>
> On Friday 27 June 2008 16:37:24 Janz wrote:
> > Celeste,
> >
> > I agree about the inconsistent moving interaction. Even 'cause (I'm new
> to
> > KDE/Qt world but I don't think it'd be different) drag and click events
> are
> > distinct, so I supose it would be possible, e.g., for Analog clock to
> allow
> > clicking and dragging it to move and clicking it to open the calendar
> (but
> > I don't know if the plasmoid developer has control over drag event anyway
> > so that wouldn't be guaranteed).
> >
> > But I think that, from what is proposed till now, move all plasmoids by
> > clicking and dragging them instead of a border or icon is, imho, easier
> and
> > more intuitive to the user, as it's what we're used to do mostly: carry
> > objects holding somewhere on themselves (except when there are form
> > constraints - as size or shape -, then we have a handler, as a plasmoid
> > developer would provide or leave some empty space on a plasmoid he fully
> > filled all it's place with, e.g., text fields or other non-draggable
> > stuff).
> >
> > Dismissing the border would allow the options to appear in a small area
> > anywhere around the plasmoids (exactly how and where they do but without
> > the move icon and that whole border). I think an extra click or hovering
> a
> > cashew or similar is extra job to a simple action of, for example, remove
> > the plasmoid.
> >
> > 2008/6/27 Celeste Lyn Paul <celeste at kde.org>:
> > > I´m not sure if on-click interaction is consistent in all widgets.  For
> > > example, most widgets have click and drag but for the Digital Clock
> > > widget, click opens the calendar.  It is not click-and-drag to move
> like
> > > the other widgets.  I only have the 10 widgets that come by default,
> but
> > > I imagine there are other exceptions.
> > >
> > > The question becomes: should the on-click interaction be the same for
> all
> > > widgets (then we can think about your proposal more)?  Otherwise we
> have
> > > to stick with the border interaction.
> > >
> > > Truthfully I´m not too comfortable with the inconsistent interaction
> > > because
> > > it requires you to learn idiosyncracies of each widget instead of
> > > class-level
> > > interaction.  Are there any widgets where it makes sense that click
> does
> > > something else (like open the calendar in Digital Clock).  Making
> > > interaction
> > > with widgets consistent should be a goal, regardless if the
> > > function/configure icons stay in the same place or are adjusted
> > >
> > > On Friday 27 June 2008 07:05:18 Ismael Asensio wrote:
> > > > Here it goes my proposal:
> > > >
> > > > Use icons over the plasmoid itself avoiding the extra handle frame.
> The
> > > > feel of these icons would be pretty much like those on old amaroker
> > >
> > > plugin
> > >
> > > > for kicker.
> > > >
> > > > All icons are desaturated (ala cashew) but still recognizable, until
> > > > the mouse goes over one of them. This icon "recovers the color" with
> an
> > > > animation (sorry for the untechnical expresion) and it's ready to be
> > > > clicked by the user. Of course, this behaviour only happens when the
> > > > desktop components are unlocked, and I'm supposing that in this state
> > > > the user only wants to play with the layout of plasmoids, not to
> > > > interact
> > >
> > > with
> > >
> > > > them.
> > > >
> > > > Every action can be place in a different corner of the plasmoid, to
> > > > help easy recognition, not only by the icon, but by its position. You
> > > > can
> > >
> > > easily
> > >
> > > > remember that, for example, rotation is low-left corner and changing
> > > > size is low-right, etc. The center of the plasmoid (greater area,
> easy
> > > > to
> > >
> > > click)
> > >
> > > > can be set for dragging the plasmoid.
> > > >
> > > > Visually, it could be like the image attached. Sorry for the HORRIBLE
> > > > HORRIBLE mock-up. It's done in a quick&dirty way with MS paint at job
> > > > office... but I hope it helps to get the idea.
> > > >
> > > > 2008/6/27 Loïc Marteau <loic.marteau at gmail.com>:
> > > > > Hello !
> > > > >
> > > > > Sorry if this has already been talked but i would like to open a
> > > > > thread about the frame draws by the applet handle.
> > > > > For people wo doesn't know well plasma terminology I talk about the
> > > > > configuration frame who appears when mouse is over a plasmoid so
> the
> > > > > user can resize, rotate, configure or move the plasmoid on the
> > > > > Desktop
> > > > >
> > > > > My personal opinion is that this frame is not very pretty and that
> > >
> > > there
> > >
> > > > > is not interest to make it an entire frame around the applet. So I
> > > > > feel that it disturbs the user visually and functionally speaking.
> > > > >
> > > > > Perhaps we can :
> > > > >
> > > > >    * just keep the small area who contains the icons, and add a
> move
> > > > > icon. * better imho to a maximum reduce the visual pollution : add
> a
> > > > > cashew for that ! on the top right corner of each applets
> > > > >          o The cashew let appears icons and text for each possible
> > > > >            action when mouse is over the cashew and not on mouse
> > > > > click so we don't need to make one more click than before for doing
> > > > > the same thing.
> > > > >          o Like first solution, add a move icon.
> > > > >    * Other ideas...
> > > > >
> > > > > What do you think about ?
> > > > >
> > > > > Cheers !
> > > > >
> > > > > Loic
> > > > > _______________________________________________
> > > > > Panel-devel mailing list
> > > > > Panel-devel at kde.org
> > > > > https://mail.kde.org/mailman/listinfo/panel-devel
> > >
> > > --
> > > Celeste Lyn Paul
> > > celeste at kde.org
> > > KDE Usability Project
> > > usability.kde.org
> > > _______________________________________________
> > > Panel-devel mailing list
> > > Panel-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/panel-devel
>
>
>
> --
> Celeste Lyn Paul
> celeste at kde.org
> KDE Usability Project
> usability.kde.org
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080628/30bd37ba/attachment-0001.html 