Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylar-dev] patch for performance improvements and group actions ontask list 
Mik Kersten wrote:

In the case of this particular patch, as you know from the bugs, I agree
with the need to group actions in the way that your patch does.  However,
there are a couple of design issues that need to be discussed up-front in a
patch of this size.  The main problem is the addition of a couple of methods
on ITaskListElement including canComplete() and canRead().  There is a
strong case for task containers not being forced to implement such methods
(they are not things that users read or complete) so the burden on someone
making such a contribution is to make the case for adding those first, or to
come up with or request a change to the framework that ensures that this
top-level interface stays minimal.
Mik, my reasoning was along the lines that containers already had isCompleted() method. I guess, the better hierarchy for task list elements would be something like this: 

 task list element
 +-- list item
       +-- query hit
       +-- task
 +-- list container
       +-- category
       +-- query
Then canRead() and canComplete() can live in "list item" interface, which is currently missing.
We could have canAccept(action) method, which would be more extendable, or even use adapters to adapt task list elements to something that will know about decisions on accepting read and complete actions. But the latter is probably unnecessary.
As of popup menu arrangement I have feeling that complete and read actions are frequent enough to live directly in the menu. Then to keep opup menu small, less frequent context-related actions like "copy context, clear context, attach and retrieve contex" can go into "Context" submenu. 
So while the statement "I get annoyed by slow UI responsiveness when group actions" could
be representative of others, it is not stated as such, and is far from clear whether this has priority in the committers' single-minded focus of stabilizing for the 1.0 release.
Well, it was little harsh statement, but I have strong feeling that it reflects numerous issues with current implementation. 
In terms of your stating that you "have to beg to review and apply them", if
there has been a problem with the turn-around of your patches please state
the average number of days waited to apply.  I have been prioritizing your
patches very high because they are generally very valuable, and if the
turn-around is insufficient for you to continue investing time into them I'd
like to know how we can improve on that without starving other users'
requests that need attention.
Mik, please don't take that comment personal. I completely understand how busy you are and how desperate the whole team trying to make 1.0 release. So, I was little ironic, mostly about myself, because I tend to submit patches at the last minute (not only to Mylar). 

 regards,
 Eugene

PS: you didn't say what are you going to do with this patch

Back to the top