On 26 Mar 2006, at 8:32 PM, Adam R. Maxwell wrote:
>
> On Mar 26, 2006, at 10:05, Christiaan Hofman wrote:
>
>>
>> On 26 Mar 2006, at 7:39 PM, Adam R. Maxwell wrote:
>>
>>>
>>> On Mar 26, 2006, at 08:39, Christiaan Hofman wrote:
>>>>
>>>> And how could we drag shared pubs ionto the same table without
>>>> corrupting?
>>>
>>> I'm not sure of the best way to do this; at present, it seems
>>> that the shared group object would have to act as copy/paste/drag
>>> datasource.
>>
>> well, but the document is the tableView's datatSource. I was
>> thinking of allowing drag/drop within the document when dragging
>> one of the following to All Publications:
>> - a set of just shared groups from the groupTableView
>> - items from the main or drawer table when only shared groups are
>> selected
>>
>> but I'm not sure how to pass that information to the destination,
>> though that is the same object. So maybe we could set a flag in
>> the promisedItems, or just a separate ivar.
>
> That's basically what I wanted to allow, as well. Since they
> aren't part of the local document, we shouldn't treat them as if
> they were; just the bare minimum functionality to get them into the
> local document. Maybe we could just pick one: either implement
> dragging pubs from the main table of a shared group into all pubs,
> or implement dragging a shared group into all pubs.
>
>>> I'm sort of abusing our group concept by adding a publications
>>> array to it, but that seemed the most straightforward way (and
>>> display is handled nicely).
>>>
>>
>> but with a lot of catches, as we assume(d) in many places that the
>> items come from the document.
>
> Yeah, and hopefully that won't be too hard to deal with.
>
>>> Current issues, in no particular order:
>>> - copy/paste/drag doesn't work
>>
>> In fact copy/paste does work (I am not really sure if it should
>> for normal items, as drag/drop is disabled for the same doc).
>
> I can copy items from a shared group, but can't paste them into All
> Publications. I can switch to a new document and paste in the
> items that I copied previously, though. Odd.
>
weird indeed, as I can. Onto the main table though, not on the group
table (which can't do that anyway).
>>
>>> - tableview editing should be disabled
>>
>> I already disabled most cases (or all?)
>
> The checkbox and rating were editable last I tried. Why doesn't
> the shouldEdit table delegate get called for those?
>
>>
>>> - I'm not sure if it's possible to update the view as the remote
>>> document changes
>>
>> how would we know?
>> Also the count does not immediately update when it is set.
>
> I don't think there is a way to know...except if we use the
> monitoring functions of NSNetService (maybe)? Not a big deal right
> now. I'm not sure if there's a good way to update the count, since
> the data is received asynchronously...maybe a notification that
> download completed?
>
that could work. Don't know if it's worth it, because it is updated
whenever the table reloads or if you (de)select the item.
>>
>>> - A progress spinner in the group cell would be cool
>>> - Prefs for enable sharing/browsing
>>
>> ... and a nice icon for the prefs ;-)
>
> I checked in a standard Bonjour icon that can probably be adapted
> by someone with artistic ability (i.e. not me ;).
>
can we use the icon itself?
>>
>>> - Passwords seem like too much hassle
>>> - How will this work in future with BD2? Would adding a version
>>> number to the archived data be sufficient?
>>>
>>
>> There's lots of questions I still have for BD2 ;-)
>> Note that there we have a Source managedObject, which should
>> handle most of that. But that is almost completely unimplemented
>> at the moment.
>
> As long as we can turn it into NSData somehow, it should work.
you are thinking of sharing between BD1 and BD2? Because that would
be much more complicated, as the items are completely different, BD2
knows absolutely nothing about BibItem. So we can't easily translate
the data.
> I think adding a version number key is probably simpler than
> registering a new protocol name for BD2, though.
>
>>
>>> Do you think the sharing on a per-document basis is okay, or
>>> should the sharing source be some global object that aggregates
>>> all publications?
>>
>> We could put the exporting in bibappdelegate. But I'm not sure if
>> that is better, also because most people will have one open
>> document anyway.
>> Right now we don't update anyway. I am also not sure how to do
>> that (see above). But I don't know anything about netservices anyway.
>
> All I know about NSNetService is what I learned by dumpster-diving
> Apple's sample code ;). It looks like it's possible to refresh,
> but I don't think it's worthwhile to implement at this stage; once
> we have prefs, a disable/enable would do it anyway if it's really
> necessary.
>
And it really slows things down. Already now I find that sharing my
1000 item database with myself gives a beachball for a long time.
>>
>>> It seems like the latter would be more painful for add/remove/
>>> edit pubs, but it would consolidate all shares under a single
>>> host (even better would be a folder with a disclosure triangle
>>> per host).
>>>
>>> --
>>> Adam
>>
>>
>> I wouldn't want to add disclosure triangles, then we have to
>> completely rework our groups setup (outlineview and all that).
>
> I'm not advocating that, believe me. I think outline views suck to
> work with, and it would basically amount to a brain transplant on
> our group code at this point.
>
> Adam
agreed.
Christiaan
|