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