more task-refactor issues

Christian Mollekopf chrigi_1 at gmx.ch
Mon Oct 6 23:21:49 CEST 2008


> From: aseigo at kde.org
> To: plasma-devel at kde.org
> Subject: Re: more task-refactor issues
> Date: Sun, 5 Oct 2008 16:52:40 -0600
> 
> On Sunday 05 October 2008, Christian Mollekopf wrote:
> > > > The popupMenu seems quite convenient to me. Unfortuantely i wasn't able
> > > > to implement a BasicMenu on rightclick on a popupmenu entry but this
> > > > should be ready with the "fancy way" as marco pointed out.
> > >
> > > when the user right clicks on a group, we can show a menu populated with
> > > each entry as a submenu with action ites.
> >
> > if "action ites" was a mistake an means actions,
> 
> action items; the 'm' key on my keyboard is acting up. i'm hoping it isn't a 
> sign of worse things to come =/
> 
Hopefully not ^^

> > that is exactly what i
> > tried to implement (but QActions don't have a virtual mouseClickEvent
> > function), otherwise i didn't get it ;-)
> 
> well, you can implement this using a kmenu, which has a bunch of contextMenu 
> items. but i don't think we want it on the menu.
> 
> so ... when a user right clicks on a single entry, they get a single context 
> menu showing "close, minimize, etc..". when they right click on a group, they 
> should probably just get a menu with one entry per window in the group, and 
> each entry should be a submenu showing "close, minimize, etc.."
>
let me make sure i got this rigth =)
so you would remove  the normal actions of a groupitem (To Desktop, Minimize, ...) and only show member tasks on rightclick? So with leftclick you could only activate a groupmember and with rightclick you could only access the contextmenu of a groupmember?

I would not consider this very useful. I think it would be much more useful if we have a menu with items of each groupmember on leftclick and each groupmember item shows its contextmenu on rightclick. On rightclick on the group  we show the menu which is currently shown and operates on all groupmembers.

> > > one possibility is to just give N columns to the expanded group, to a
> > > maximum of maxColumnsPerRow.
> >
> > how would this solve the problem, that a group loacted at the end of the
> > first row which gets expanded would have to split? (since the order is
> > fixed) We could of course move the group to the next row but this would
> > lead to holes in the layout....
> 
> we'll need a way to split groups across rows. whether than means the actual 
> groups themselves or temporarily passing items up to the parent group for 
> layouting .... as marco said, it'll be annoying in the code but it's what i'd 
> expect as a user.

Hmm... in this case i will implement it the way that we have two groupitems if it has to be split, so we can still get a consistent layout of a group.

> -- 
> 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
>
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer


More information about the Plasma-devel mailing list