On Tuesday 23 September 2008, Marco Martin wrote: > On Tuesday 23 September 2008, Aaron J. Seigo wrote: > > some not-so-small things: > > > > * we're going to want to have a "only group when full" option in there > > > > * multiple rows are still missing > > an ideal thing would be a QGraphicsFlowLayout, but well we don't have that > :/ so i suppose it would be needed something that every time an item is > added/removed relayouts everything in a grid layout, sooo, something custom > in here? subclassing the grid layout? (ohnoes! own layouts again:)
either subclassing, or just checking the width of the widget compared to the number of items and coming up with a ROWxCOLUMN and manually inserting the items into a grid layout. the latter is probably the easiest: one method with probably two dozen lines of code that gets called with a button is added or removed. > > * i'm getting a consistent crash-on-exit with program grouping is on > > > > > > but we have a biggers issue with the new widget than above, mostly to do > > with user interaction. here are the outstanding issues i see: > > > > > > * all grouping interaction is done via the context menu. this is a non- > > starter. there absolutely must be visual feedback on this, e.g. an arrow > > to expand collapsed groups > > still think the old way with a submenu opened on click is more intuitive. agreed. > to be done or with an ugly qmenu or with a plasmaview that contains an > offscreen widget filled of windowtaskitems, perhapsit's a bit big for 4.2 > btw we could do the qmenu first and then switch to something more pretty later. sort of how we tend to do everything else: make it work, make it pretty. > > * when a group is expanded, it becomes a cloud of little icons in about > > the same space as original button. the icons are not recognizable. > > probably it's an issue of the sizehint of the taskgroupitem and should > signal to invalidate the master layout, like in some places exists > already.. could be; it does use nested layouts, however, so it could be that the main graphicsitem with the layout in it just doesn't adjust it's size hints properly. > > * i had no clue how to trigger manual grouping > > > > > > so ... how to interact with grouped items ... > > > > expanding groups: > > > > * a single click on a collapsed group could expand it > > i like the current behaviour of cycle on clicking problems with this behaviour is that it's non-predictable (there's no cue as to which window will come up) and it prevents one from actually selecting which window you want. how often do you really want to cycle through all N windows versus pick window M based on its title and/or icon? > > * an expand arrow when clicked could could expand it > > like it better downsides to this: smaller hit area, will mean lots of little arrows, people have to notice you can click on them. > > * an expanded group could push other buttons aside, giving the buttons > > inside as much room as buttons not in the group (making an > > all-groups-expanded taskbar as cluttered as the current bar) > > an idea upon this option: > just allow a single expanded group at a time, when theer is one expanded > all the items not belonging to that will show just the icon, selecting one > of them the group collapses this is a possibility, yes. > oh, a side note: > now the current thing is the one in playground or in the branch? i've been working in playground. i can't be bothered to keep yet another whole branch of workspace around and svn does not make switching around between branches fun enough for me yet =) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech
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
