[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] more on the karm/korganizer integration
From:       tomas pospisek <tpo2 () sourcepole ! ch>
Date:       2003-10-26 15:59:48
[Download RAW message or body]

On Fri, 24 Oct 2003, tomas pospisek wrote:

> Since we're at it - discussing karm - would you mind discussing the cons
> of my proposal [1]?
>
> [1] http://sourcepole.ch/tpo/ktimerchecklistitem.png

All right, sorry, I dug up your answer in the archive...

I guess all the new things should go in after the release. Is there
any interest in maintaining a separate CVS branch for this? Otherwise I
could just maintain these things as a patch untill then?

On Tue, 2 Sep 2003, Mark Bucciarelli wrote:

> On Friday 22 August 2003 6:26 am, tomas pospisek wrote:
>
> > * A KListView subclass that has a context menu that pops up
> >   when clicking the RMB inside the header and presents you all the columns
> >   which you can hide or show.
>
> That sounds useful.
>
> >   I did this because I want to have all the nice korganizer-todo
> >   properties inside karm (and vice-versa), but I also want people to be
> >   able to configure what todo properties they see so that it won't clobber
> >   their screen.
>
> I'm not sure about this idea.  Why make both gui's the same?

The goal is not having identical GUIs. The goal is to merge the
functionality - I want to be able to organize my work and the less
some applications get in my way - that means not beeing forced to switch
back and forth between various apps, ex/import stuff, not having to
do half of the work in one app and the other half in another app.

I want in karm:

* % completed
* gantt view
* start/end date

I want in korganizer:

* ability to start and stop tasks

> Won't this mean that we will have to work to keep KArm UI in sync with
> KOrganizer?  (For example, the drag-n-drop stuff Reinhold added?)  I'm
> not anxious to set this kind of expectation.

Not necessarily - we can provide some base UI widget (as f.ex. a
base-ListItem) that some functionality. KOrganizer and Karm can subclass
that and add whatever they want.

A propos drag-n-drop - that certainly is a wish for Karm. Reorganizing
tasks with drag-n-drop is one of the less painfull methods.

> Why not just keep KArm simple--if they want access to all KOrg fields,
> they can edit the todo in KOrg.

And start it in Karm afterwards? And then go back to KOrganier and edit it
there? What about synchronization/locking - that will be an additional
mess then. Why make things complicated for the user?

> In addition, I think there are fields that are useful in KArm that KOrganizer
> may never display; for example, an hourly budget for each task.  With this
> field, we could compute % complete, which KOrg does care about.

We can arrange things in a way so that an application can decide wheter it
wants to display some fields or not. Same for the editing.

> To me, there are reasons to keep them seperate.

Certainly. But there is duplication of effort happening right now.

> > * A new subclass of QListViewItem that integrates a QCheckListItem
> >   with Karm's running clock.
> >
> >   I did this because the Karm fraction loves being able to double click on
> >   a task and having the task start/stop running and the Konqueror fraction
> >   loves being able to double click a todo and be able to edit its
> >   properties and click the checkbox and be done with a task.
>
> This raises an interesting question--how to display complete tasks in KArm.
> There was some discussion recently here about the same issue in KOrganizer
> (grey vs. strikeout vs.  no change).  Previously, when you were done with a
> task you could delete it.  The way I implemented karmstorage, when you delete
> a task, it's history is deleted.
>
> Personally, I find the checkbox overlaid on the clock to be confusing
> visually.  And if I understand your chart, double-clicking in different areas
> on the same line produces a different result.  I don't think the increase in
> functionality is worth the added complexity to the UI.

You mean the increase in functionality isn't worth it wrt to the usability
or wrt to program code? The code is not very complex. But double-clicking
on different areas of the line is producing different results right now.

My question is if we want the functionalty at all (being able to double
click a task to finish it and double click a task to start/stop it) and if
we do, then how do we want to solve usability/GUI-wise.

The problem is that korganizer and karm behave differently wrt to that
double-click. The korganizer people do not want to give up "their"
behaveour and I do like karm's behaveour. The proposed solution offers one
path to satisfy both. Is there a better solution?

> >   The idea is here again to eventually integrate korganizer and karm.
> >
> >   So I've integrated the checkbox with the clock:
> >
> >   * if you single click the clock/checkbox you check the checkbox
> >   * if you double click the clock/checkbox you start/stop a task
> >   * if you double click the tastk you edit the task properties
> >
> >   You can find an illustrated example here:
> >
> >   http://sourcepole.ch/tpo/ktimerchecklistitem.png
> >
> >
> >   Please speak up if you think this is a really bad idea. Otherwise I'd
> >   like to proceed and commit this to CVS so people can play with it. The
> >   next step would be merging of korganizer's todo list classes with karms
> >   and moving them to llibkdepim (and of course integrating Mark's huge
> >   patch)
>
> My vote would be to wait.  The issue of more tightly integrating the UI with
> KOrganizer needs more thought, I think.  :)  Especially with a Sep 1 feature
> freeze and a Sept 8th alpha release!

Sure.

*t

--
Bad times for dictators. At least in the oil regions.
Goedart Palm


_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]