New task / dock management library

[Emdek]

2010/3/8 Aaron J. Seigo <aseigo at kde.org>:
> On March 7, 2010, Emdek wrote:
>> And I would like to do it as GSoC project, it could include example
>> dock implementation (visualization), as I'm working for one year on
>
> as i've said on irc previously, while i respect your choice to work on this, i
> think it's completely unnecessary and a poor direction. i really don't want to
> spend one of our SoC slots on such a thing.

Ok, no means no, even if my English teacher often said that "no means
yes", but this is not a case.


> it is fun to work on something new. and, of course, we all get to choose what
> we work on. this is what helps make f/oss development fun and interesting.

For sure.


> but none of the features you listed are actually unique to docks outside of
> mixing launchers with windows, and a new library is not required to achieve
> that. other things like "merging system tray windows with task entries") or
> qtscript for grouping strategies[1] could (and should) be added to
> libtaskmanager where they would benefit all task managers.

Not really, adding these things to it will make it bloated.
In case of my design code that belongs to libtaskmanager, after
removing not needed things, and moving strategies to other level,
would form engine which sends information about tasks, nothing more.
It helps to remove impact of changing something in it on projects that
uses it (unless if there would be changes in existing properties of
subclass of Item that represnts task).
Now, as you said some time ago, external users should copy taskmanager
to ensure that it will not break again...

Anyway, extending current library most probably will again break
compatibility, so I don't see difference on this level between
starting something new nearly from scratch and changing current design
very much.
Except that usually wrtting something new is easier than changing
something developed for many years.
And I'll say it again, doesn't mean that current code will be trashed,
it will be reused.


> [1]  though that sounds like completely overkill tbh; are there really that
> many different strategies, or that well end being added at runtime?.

Amount of strategies is not a reason for doing this in that way.
It's meant for advanced users or possible advanced use cases (no, I'll
not list examples :-P).
For average user it is not important, everything what he need is to
have access to standard strategies.