Heh heh, having now read the related post on the users list, I see
someone's come up with a smarter, simpler solution.  Yet again proving
that I am NOT the smartest person around.  Don't tell my wife :)

On Thu, Mar 6, 2008 at 1:58 AM, Laurence MacKenzie
<[EMAIL PROTECTED]> wrote:
> I'm sorry, I was less clear than I should have been.  This is the
> process change I had in mind:
>
> Current Process:
> 1. Click on "NOW" on a row.  Result:  Changes to "LATER"
> 2. Click on "LATER" on a row.  Result:  Changes to "DONE"
> 3. Click on "Triage" on button bar.  Result:  Triage resorts, row
> moves to "Done" section.
>
> Proposed Process
> 1. Click on "NOW" in a Chandler item row.  Result:  "Now, Later, Done"
> options appear.
> 2. Select appropriate option.  Result:  Status changes and row moves
> to appropriate section.
>
> Now that I think about it, running the full routine initiated by the
> "Triage" button probably isn't the best idea because that could move
> around other things the user had been working on.  And I do see the
> benefit of not moving items without an explicit instruction from the
> user, it allows one to sort their triage, work it from top to bottom
> then resort it so the current most important items are at the top.  If
> an item was flipped from "NOW" to "LATER" the user would process it
> twice.  So I do see the value of the way the system is designed now.
> I just wonder if this might be a bit of an enhancement.
>
> I also see your point on it being primarily a user interface issue
> that could use input from more users so I'm crossposting this to both
> lists.  Hopefully someone(s) on dev can have an idea if this is
> feasible while someone(s) on users can express an opinion on its
> functionality.
>
>
> On Wed, Mar 5, 2008 at 1:42 PM, Grant Baillie <[EMAIL PROTECTED]> wrote:
> > Hi, Laurence
> >
> > Implementing that involves some custom widget work in the graphics
> > library Chandler uses, wxPython. So, for an expert (i.e. not me :),
> > it's probably not a lot of work -- any experts on the list have an
> > opinion?
> >
> > (Also, possibly there is some existing open source code out there that
> > has done this kind of thing, too).
> >
> > On the other hand, the end-user question is whether this should be
> > default behaviour, since if you're sorted by triage, it can involve
> > items leaping about unexpectedly in the table. But this part of the
> > discussion should probably go to the users list.
> >
> > --Grant
> >
> >
> >
> >
> > On 4 Mar, 2008, at 22:50, Laurence MacKenzie wrote:
> >
> > > Warning: I used to be more involved in IT but I had a career change
> > > about three years ago, so it's probably like a whole new world.  And
> > > to add to that, I have no knowledge of Python, though I do intend to
> > > get up to speed.  Please excuse me if (who's kidding who, when) I
> > > say something stupid or out of date, either here or later. :)
> > >
> > > In the thread "[chandler-users] easiest way to mark task as done?"
> > > Mike brings up a good point about Triage.  It kinda irks me that
> > > when I click the status of a "Now" item to change it, the item
> > > remains in the "Now" section until I update the Triage (i.e. press
> > > the "Triage" button).  It seems to me that should be automatic.  On
> > > the other hand, if the item moved automatically it would REALLY irk
> > > me if I wanted to change that same item's status to "Done" because
> > > once I clicked "Now" and it turned to "Later" I would have to track
> > > it down again to change it to "Done".  That, in layman's terms,
> > > would suck.
> > >
> > > How much work would be involved in changing the "Now/Later/Done"
> > > toggle into a sort of context menu with all three options on it?
> > > Assuming that's not too difficult, it should be relatively simple to
> > > run whatever routine updates the Triage when the status changes,
> > > right?
> > >
> > > Just some thoughts,
> > > -Laurence
> > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> > >
> > > Open Source Applications Foundation "chandler-dev" mailing list
> > > http://lists.osafoundation.org/mailman/listinfo/chandler-dev
> >
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> >
> > Open Source Applications Foundation "chandler-dev" mailing list
> > http://lists.osafoundation.org/mailman/listinfo/chandler-dev
> >
>
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to