On Mon, 2004-02-02 at 17:00 -0500, JP Rosevear wrote: > Basically we can't do any drag and drop in the calendar/addressbook/task > list right now. Here are a couple of ideas: > > 1. ESourceSelector provides an API call to add drop types its interested > in. ESS proxies the gtk tree view drag/motion/release signals and > includes the ESource in the call back. > this sounds great to me. We could probably have all the D&D implementation hidden there and have ESS's users just have a couple of calls/callbacks for doing all D&D stuff.
> 2. Since ESourceSelector uses a tree view, the various components could > just use the DnD foo in the tree view directly (like the mailer does). > In both cases for the calendar and tasks we need to consider what > happens on the drop, especially in the case where the drop happens on a > source that is not "selected" (ie checked off). > well, as I understand it, it should just add the dropped appointment to the folder it was dropped to. > The calendar/tasks > could either make the drop location primary (which makes some sense > since that is where new items are by default created) or they need to > load the client, add the items, then unref the client. > well, do we really need to set it as primary? > I personally prefer 1. since it ensures that things like disallowing > drops on groups is consistent and it generally reduces the amount of > code I think. We need to think about how to disallow drops on read only > sources as well (use the e-source-group read only setting?). > yes, we could just use that one. Although I think we should probably have the read_only setting on the sources, not on the groups. That is, there can be LDAP folders that are read only besides other read-write. The same could happen for Exchange connector calendar. cheers _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
