tasks-refactor issues

[Aaron J. Seigo]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080923/6afab1cb/attachment.sig