Re: [Bibdesk-develop] Christiaan's BD 2 commits from yesterday

[Christiaan H. <chr...@we...>]

On 7 Feb 2006, at 1:45 AM, Michael McCracken wrote:

>
> On Feb 6, 2006, at 4:03 AM, Christiaan Hofman wrote:
> ...snip...
>>> I meant importing in the test project, yeah. I started working on  
>>> making Publications out of BibItems, but that'll be a long road.  
>>> The problem I had wasn't actually with linking but with compiling  
>>> - once you want to import BibTexParser.h, you have to import  
>>> BibItem and BibDocument, and by then it's the whole project.
>>>
>> Can't BibTeXParser be rewritten to give directly publications? The  
>> basic information is in the dictionary, so we just need to write  
>> an extra method that translates the dictionary into CD stuff.
>
> I didn't want to do this because I was afraid of duplicate parsing  
> code in case we had to make changes to parsing in BD1 and then try  
> to keep another copy of it in sync for bd2, but maybe it's not a  
> big issue?
>
> I also thought that having a BibItem->Publication conversion would  
> be handy so that we could use the RIS and other parsing code  
> without rewriting it as well...
>
>>>> Another problem I have with the test problem is that it is not  
>>>> really clear for me what the UI should look like. A big problem  
>>>> I see is that the publications have far too much information to  
>>>> be able to comfortably put in the detail editing part of the  
>>>> display controller. Should we somehow have separate editors as  
>>>> we have in BD1? I also sort of broke out the Note an Tag parts,  
>>>> as they are basically universal (and secondary information).
>>>
>>> I've been thinking about this too. I decided to try a design  
>>> where the 'most important' information is in a space at the top  
>>> of the detail part, and there's a scroll view below with a series  
>>> of sub-views that'd include editing ui and tables of related  
>>> pubs, etc. I have a sketch at work that I will try to reproduce a  
>>> bit in OmniGraffle tomorrow.
>>>
>>>> Also as I understand it we should replace the detail editor with  
>>>> a separate display controller? Than we can support multiple  
>>>> entities.
>>>
>>> I'm not sure what you mean here.
>>>
>>
>> I mean the detail editor on the lower right (with the brick  
>> background) should be a custom view with separate display  
>> controller that can be swapped in, just like the  
>> TableDisplayController. Then we can swap in the right one  
>> depending on which item is selected in the itemTableView. This is  
>> mentioned on the Wiki. We could then perhaps also allow to break  
>> it out of the window, so we have an editing like in BD1 (similar  
>> to what I implemented with the secondary windows).
>
> OK, I understand. And yes, that's a good idea. I've actually  
> started doing this with a single publicationdisplaycontroller,  
> which for now is just swapped in instead of the lowerpane of the  
> publicationtabledisplaycontroller. It deals with one publication  
> and has its own view so we could certainly show it in a separate  
> window as well. It is a start on the UI idea I mentioned earlier  
> about the important details in the top of the pane and a scrolling  
> UI to view others and edit them.
>
> I will commit those changes soon, but I'm moving house again today  
> and tomorrow, so I can't promise it'll be fast enough, since I  
> think those changes have some conflicts with what you've done and  
> I'll have to do some work to merge.
>
>>>> Also the hierarchy of the groups is not as we want it, I think.  
>>>> I am not sure what precisely we want and more importantly how it  
>>>> could be implemented. Do we want root level custom groups, like  
>>>> in iTunes? Now they are all hosted by the 3 root groups.
>>>
>>> I've also not completely made up my mind what to do here, and am  
>>> curious what everyone else thinks.. I think more flexibility than  
>>> iTunes is due, since the flat list of playlists there can be  
>>> unwieldy if you have a lot of playlists. For instance, I keep  
>>> playlists of CD's I've burned as gifts, but I don't always need  
>>> to see them in the listing.
>>>
>>> -mike
>>
>> Right. But you might want to have a group (either static or smart)  
>> containing all items (publications, persons, ...) related to a  
>> particular project. This cannot be done now, as all groups can  
>> only contain one entity, and they are a descendant of a root  
>> group. CD requires the groups (the relationships) to have a fixed  
>> entity. Perhaps we need to introduce an overall abstract parent  
>> entity for data entities (like publication, contributor, note...).  
>> But I am not sure if this works with smart groups. I.e. does a  
>> fetch request with the parent entity fetch child entities? I don't  
>> think so. Maybe we need to make smart groups more complicated,  
>> using several fetches.
>
> I see what you mean. I like the idea of heterogeneous groups. In  
> fact, if we have heterogeneous groups, I don't know if it is worth  
> also having groups that only contain one entity, as we have now.  
> Maybe the best way to organize the side bar would be to have a  
> single item for "All people", one for "All pubs", one for "all  
> institutions", "all venues" and then have groups that can contain  
> any entity.

BTW, I have some implementation of Institution and Venue sets of  
classes and nibs. I could commit those if you want.

> The groups would be at the top level, but could also contain  
> subgroups.
>
Still, I have problems to envision how to display heterogeneous  
groups. For example the item table at the top contains different  
keys. So maybe we need to have some popup to choose between entities  
and filter those out? Or maybe each heterogeneous group always  
contains the set of root type groups (but the list then becomes long)?

> so, maybe something like this:
>
> - People
> - Publications
> - Institutions
> - Venues
>  -- divider --
> - Unread papers (smart group, filters from all pubs)
> - Collaborators (smart group of people who are authors on papers  
> I'm author on)
> + Compilers (a static group)
>   + Analysis (static)
>     - Cites me (smart, filters from the pubs in the parent)
>     - Dependence Analysis (static)
>
> What do you think?
>
> For this case, it seems like an abstract entity would be necessary  
> to have the relationship of Group->{Person,Publication,etc} work,  
> but about fetchrequests that would get multiple classes, I am  
> surprised that they wouldn't get child entities - can you confirm  
> this? Even if that's the case, though, multiple fetchrequests isn't  
> so bad, since we only need this many: size 
> ({Person,Publication,Institution,Venue}). Right?
>
> -mike


I should try it, but if I read the docs it should fetch just exact  
entities, not subentities. But it is easy to create a fetch method  
that gets also subentities by replacing entities in the fetch request  
by subentities. (have it already written).

Christiaan