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

List:       kde-pim
Subject:    [Kde-pim] Re: kdepim/korganizer
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2005-03-24 20:47:00
Message-ID: 200503242147.04170.reinhold () kainhofer ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Am Donnerstag, 24. März 2005 20:58 schrieben Sie:
> Reinhold Kainhofer, you wrote something like this:
> > Wouldn't it be simpler to use KURLDrag for dropping attachments instead
> > of a QTextDrag and explicitly checking if the dropped text was a URL?
> > This would allow it to also drop e.g. the current location of konqueror
> > (the web-browser) and not only the location of konqueror (the file
> > manager)....
>
> You're right. I just dived into the DND-semantics of Qt/KDE. I didn't know
> the KURLDrag class, but it would probably be better.
>
> I will see if I can implement this in the todo view shortly. Once I'm
> finished with hacking the KOAgendaView and KOMonthView, I'll use KURLDrag
> there too.


Hmm, thinking of it, we basically have the same drop code in the agenda items, 
the to-do list items, and in the future also in the month view items. (The 
list view is totally missing them right now.)

Basically, when dropping there are two cases:
-) dropped on an item with an Incidence*. In that case, all views should 
behave exactly the same. (Even dropping a to-do on another to-do in the 
agenda view should make it a sub-to-do...).
-) dropped on something else (background, empty space in the agenda etc). Here 
we have a date/time or not. Depending on the view, a new event or to-do with 
that datetime should be created. There's also nothing that depends on the 
view.

I wonder if we can't factor that whole stuff out and avoid lot of code 
duplication. 
In the drop code we need to have the incidence changer, the calendar and the 
target Incidence* available, and we need to emit signals, so it will not be 
as simple as the UrlHandler in korganizer. Moving these functions to the 
KOrg::BaseView class is also no solution since they'll still not be available 
e.g. to the agenda items. 
It's basically the same problem as with the IncidenceChanger, which is also 
not solved in a nice way. Currently, the IncidenceChanger* is passed through 
to each view, and each view holds the same pointer to it. A quasi-global 
variable would be best, but the changer is specific to the calendarview (and 
thus the Calendar-derived object), so it can't be a singleton.

Any better ideas?

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://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]