> The terms "Zoom Out" and "Zoom In" are presented to the user. I wonder if > this perhaps exposes the mechanism rather than the action(s) the user would > like to perform. What distinct functionality does each of the zoom level > provide? Or another way to put it might be, what activity would the user > like to perform that would prompt the user to change zoom levels? > > At the "zoom 0 (fully zoomed in)" level, the only thing I can think that > "Zoom Out" provides is to show the available activities. Once "zoomed out > (1/2, 1, 2)" the user can currently select an activity, create new > activities, or remove existing activities. If that is what it does (or is > envisioned to do), would it make sense to label "Zoom Out" in the > fully-zoomed-in/normal-desktop-view mode something like "Show Activities".
+1 the point of zooming out once is to switch activities or move stuff between them. I'd like the second zoom out to be for management of activities. > Selecting an activity could use the same Qt/KDE selection model similar to > what's used throughout the desktop (essentially a single selection view). > Keyboard navigation could be the same as elsewhere on the desktop: arrows > keys highlight, enter activates (zooms in). Mouse navigation would be the > same: mouse over highlights, click/double-click activates. > > To keep the move-applets-between-containments-using-the-mouse functionality > probably requires the activate target outside the containment like the > "Zoom In" on the handle is now (but perhaps bigger and labeled "Select" or > "Select this activity" "Use" or something...). I don't think this part really fits with plasma. when we zoom out we are quite literally zooming out - it's just a transform on the canvas. pretty much one line of code. it'd be kinda nice to have a way to select an activity and see which one is selected, though. > > If all the activites don't fit on the screen, perhaps the same mechanic > that's used througout the desktop when display items don't fit on the > display area could be used here: a horizontal scrollbar. I have to keep > reminding myself that I can drag-to-scroll when I've zoomed out to see the > available activities. first thought: eeeew, ugly scrollbars! second thought: er, you have a point, some indication that scrolling's possible would be good. although we do turn the mouse into a grabby hand. > > To push a little the further; what about a zoom slider in the tool box > once the user is in the "Show Activities"/(zoom > 0) mode. The slider > could use detents for each zoom level. The user is arguably already > familiar with the zoom slider from many apps (dolphin, gwenview). interesting... > > The visual presentation and interation would be mostly similar to a dolphin > icon view in preview mode, only with live, more interactive "previews" > (containments). One remaining question would be: are there any functions > envisioned in the zoomed out modes that go beyond selecting, creating and > removing activies that would not work with this suggested mechanic? hrm. um. I can't think of any, actually. > > Just a few thoughts I hope are helpful, and I'm happy to pitch in some > coding time to help whoever wants to work on this, Andrew Lake coding time would be awesome. :) we have plenty of other things that could use coding time too (er, who's watching over the bug monster while aaron's away?) -- This message brought to you by eevil bananas and the number 3. www.chani3.com
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
