Le 29 mai 07 à 00:18, Yen-Ju Chen a écrit :

> On 5/28/07, Quentin Mathé <[EMAIL PROTECTED]> wrote:
>> Author: qmathe
>> Date: Mon May 28 23:10:47 2007
>> New Revision: 1970
>>
>> URL: http://svn.gna.org/viewcvs/etoile?rev=1970&view=rev
>> Log:
>> Imported new prelimary Container architecture which introduces a  
>> flexible view model to display collections in many different ways  
>> without rewriting most of glue code. Flexibility of the  
>> architecture comes from pluggable layouts which can replaced on  
>> the fly and subclassed to fit new needs. First step towards  
>> component support. Implementation was initially roughly described  
>> on ComponentKit page of Etoile wiki. Object Manager views and  
>> Document component layout could directly benefit from it. ...  
>> Probably safer to store it in the repository than on my own hard  
>> disk... Time to return to LiveCD playground ;-)
>>
>
>  So I guess we all secretly try to solve the same problem here. :)

It may be :-)

>  I have a project in progress here: http://code.google.com/p/koelr/
>  My idea is to converge all data model into the same one,
>  mainly key-value relationship like AddressBook,
>  which has group and subgroup support
>  and allows searching with predicate.

It's an evolution of CollectionKit then? What are the differences  
outside of predicate support?

>  On the view side, I use Blocks framework to hook up all the views.

Until now, I didn't really like Blocks but the drastically cleaned  
version you put in OrganizeKit repository seems far more appealing.
As a side note, I'm really interested by having a better logging  
facility in EtoileFoundation. Logging class part of Blocks is nice at  
first sight.

>  Since the data structures is the same no matter what,
>  views know what to expect.
>  It is still a typical MVC.
>  It just has unified data and pluggable views.
>
>  I guess your approach is more close to what Grr has now,
>  which pipes data through views.

Well Container code isn't about piping data trough views like Grr.  
That's why I haven't called it Component. All this overlapping  
terminology is sometimes tricky to sort out :-) We really need a  
better glossary.

>  Do you try to solve the problem of pluggable views
>  or more on the data ?

I don't try to solve data storage or data format with Container. For  
pluggable views, it depends what you mean by that.

>  If we can find a common ground, maybe we can work together
>  to save our energy and time.

This would great and seems possible. By the way, CollectionKit is  
largely better name than OrganizeKit :-)

Container is mainly:
- a generic view to display items called ETContainer
- an unified data source informal protocol to bind the generic view  
to the model (so you can freely switch beetwen icon view, table view,  
free layout etc. without changing anything… I also plan to support  
outline view and browser/colum view in the same way)
- the possibility to add or remove items without implementing a data  
source when the collection of items is flat and not organized in a  
tree structure
- a layout unit (ETlayoutItem) which represents each item and is used  
as a wrapper object to exchange values between model and view
- a set of layouts (new layouts which are useful but not available at  
all in AppKit: this would be flow/grid, stack, line/row or page to  
place items in an arbitrary way)… Layouts that wraps existing views  
like NSTableView will be available, as a side effect you will be able  
to create simple list view without implementing a data source as it's  
already possible for NSComboBox
- various extensions like… menu overflow for items which cannot be  
displayed, insertion/customization of items you can pick in a panel  
showing a predefined set, etc.

Layouts combined with optional data source support should allow to  
build things like Download Manager-like window, photo view, very  
specific toolbar-like view (like menulet bar) or a complete document  
layout engine with layer support. In short, it is a sort of an  
additional layer on top of AppKit that  intends to extend and wrap/ 
replace NSView subclasses related to display and management of  
collection of items.

Cheers,
Quentin.

--
Quentin Mathé
[EMAIL PROTECTED]


_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss

Répondre à