Taskmanager with grouping support preview version

[christian mollekopf]

Hi,
i have some further questions about the program architecture...


To get around the TaskPtr problem, i derived a new class from AbstractGroupableItem called TaskItem in the libs part. It basically just holds a copy of the TaskPtr. Its a bit overhead but in favour we can work with the AbstractGroupaleItems and manage Groups and Tasks therefore the same way. This way the Task class isn't affected in any way by the grouping ability.

> > > * there are gui concepts mixed into this data class. collapsed/not
> > > collapsed is not a data concept, it's a visualization concept. all of
> > > that logic belongs in the UI side.
> >
> > Thats true, but if i remove it i have to move the whole TaskRMBMenu class
> > out of the lib and move it to workspace/plasma/applets/tasks/ so i have
> > direct access to the collapsed() function.
> 
> not at all =) the menus can stay in the library quite easily.
> 
> or really, the QActions can.
> 
> i've never really been a huge fan of the menus themselves being in the 
> library, but the functionality they provide makes lots of sense. what we 
> really want is a class or set of classes here that provides a set of QActions 
> that can then be plugged into a menu.
> 
> two possible approaches:
> 
> * TaskActions class with a QList<QAction*> actions() method. the QActions 
> would be connected to slots in TaskActions that perform the actual work.
> 
> * a set of QAction subclasses, such as MinimizeAction, which can be created 
> and put into menus.
> 
> the former is less work, the latter is a lot more flexible. in fact, the two 
> approaches could even be combined where TaskActions is a simple factory class 
> for determining which of the specialized QActions to create based on a set of 
> Tasks handed in. that might even be the best solution.

Flexible is good =)

I'm not sure what this factory class would do.
I cant think of a case where a set of tasks would be handed in.
The menu is just for Tasks or TaskGroups. 

What i am currently doing is creating a set of subclasses like this:

MaximizeAction::MaximizeAction(QObject *parent, TaskPtr task)
:QAction(parent)      
{
    connect(this, SIGNAL(triggered()), task.data(), SLOT(toggleMaximized()));
    setText(i18n("Ma&ximize"));
    setCheckable(true);
    setChecked(task->isMaximized());
    setEnabled(!KWindowSystem::allowedActionsSupported() || task->info().actionSupported(NET::ActionMax));
}

For actions that don't happen in the library one would have to create custom ones where they are needed because i don't think it would be reasonable
to create a collapseGroupAction (which only applies to the Tasks group)  in the lib.

For basic menus like the "toDesktop" menu i would also create subclasses.

All those items have an overloaded constructor for either a TaskPtr or GroupPtr. The GroupPtr version would end up in executing the action on every group member.

The main menu would then be created where it is used, so we can easely insert actions like "collapse/expand Group" which are specific to each visualization.


Regards


_________________________________________________________________
Es ist höchste Zeit dabei zu sein - Holen Sie sich jetzt die neue Generation der Windows Live Services!
http://get.live.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080710/40875073/attachment.html