In data domenica 04 ottobre 2009 20:31:49, Aaron J. Seigo ha scritto: : > On October 4, 2009, Jacopo De Simoi wrote: > > On Sunday 04 October 2009 20:57:11 Aaron J. Seigo wrote: > > > On October 4, 2009, Jacopo De Simoi wrote: > > > > now, we believe that it is ready for merging into trunk. Of course > > > > we need your feedback first, so grab it, try it out and tell us what > > > > you think! > > > > > > with options out of the way :) some thoughts on the plasmoid itself: > > > > > > * it still says "Devices recently plugged in:" when there are no > > > devices listed. that's always seemed a bit odd. it should probably be > > > replaced with an applicable label and the divider line removed in that > > > case > > > > The divider line was put there to avoid the bad "cropped" feeling of the > > scrollwidget when scrolled down; this is actually being addressed in the > > scrollwidget itself, with the nice shadows that now appear when the > > scrollbar is visible, so I believe that it can go back to having it > > getting along with the categories. Still I don't know if it makes sense > > to have one also for the first category. > > i wasn't actually concerned about the divider itself, but about the text > which says "Devices recently plugged in:". when there are no recent > devices, it's rather odd since there are no devices. perhaps the text > should change to something like "No devices to show"? > yes, i suppose that is needed, together with the separator that is unnecessary when there are no devices.
> > > * when an item is expanded, should the background remain painted? it > > > might make it more evident that the item is "open", and it would also > > > allow a way to solve the next point, too. (and if the background > > > remains, perhaps the capacity bar should too?) > > > > The background could in principle stay, for the capacity bar there is an > > issue: there is no way to make a refresh signal "free space changed"; > > that's why we show it only on hover (and for the same reason it is like > > that for kfileplacesitem); > > ah, ok.. unfortunate but sensible (and now i remember the conversation > about this a while back on kde-core-devel or kfm-devel as well :). perhaps > the action icon (Eject) could remain at least? > > and "N actions for this device" is probably redundant and doesn't need to > be shown at all on mouse over when it is expanded? > make sense. > > > * each DeviceItem gets its own ItemBackground in case it has multiple > > > actions. it would be nice if they could share the one ItemBackground > > > between them as only one at a time can be shown anyways so anything > > > more seems like a waste; it would also allow the hover effect to track > > > with the mouse more effectively when there are multiple DeviceItems in > > > the list. > > > > I don't think I understand this; if we had one itemBackground shared by > > all items we would see the selection bar move from a device to another > > one. Do I understand correctly? > > yes; depending on how this ultimately looks it may be desirable to > immediately jump the ItemBackground from an action item to the next > DeviceItem when moving from and action to the next device. > > i think, however, that it will feel most natural if the ItemBackground just > moves between items no matter what they are. > > consider two items, both with multiple actions and both of which have been > clicked to expand .. moving from the second action in the first device to > the first action in the second device would feel quite "natural" and > smooth if the ItemBackground moved between them. > well, actually you can't open two devices at a time, so if we keep this behaviour the problem doesn't exist. on the other hand if we change that i think it makes sense, even if i'd say it would introduce some complexity in the code, but i'm not sure about that. > ah, another item: there is no keyboard navigation :) up/down arrows and > return/enter should work ... > that definetely needs to be done. i didn't think about that. > some other things that have come up as i've been using it today: > > * the popup icon only changes when the user will be notified of a device. > would it make sense to show an icon change even if the device is going to > be ignored? that way there would at least be feedback that the applet was > aware there was a change and chose not to do anything about it? > what do you mean with "ignored", hidden? > * i really like how the unmounting waiting is shown; i did notice that the > icon overlay on a storage volume for mounted matches the action icon to > mount a device; but when you click on unmount, the overlay is a box with a > line through it. this seems asymmetrical. should the overlay on the > storage volume icon be the "unmount" icon? > the real problem there is that that icon to mount the device isn't the right one. but there isn't an icon like "action-mount", so i had to fallback to that. > * there's a Plasma::IconWidget in DeviceNotifier; it never seems to > actually be used. should it actually be the same as the icon in the > NotifierDialog? > that's the icon shown in the panel > * i had marked my external HD as hidden. when i plugged it in, it didn't > show (obviously :). since i had done this a few hours ago it took me a > while to remember WHY that hard disk wasn't being shown. > > would it make sense to show some sort of feedback when a hidden item is > plugged in? the popup wouldn't need to show up and a full DeviceItem > wouldn't need to be constructed or anything, but perhaps a little "A > hidden device was plugged in" entry that could be clicked on to show the > device if you wanted that disappears automatically after N seconds? > > my concern, having already happened to me after less than a day of usage, > is that we'll get users falling into the same trap (not remembering what > they've marked as hidden) and figuring it's some sort of bug or that that > device isn't getting plugged in properly. > that makes sense. maybe, without creating an item to insert in the plasmoid, we could show a message. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
