On 5/28/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > 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?
In CollectionKit, everything must be inside a collection. It supports single type of object and group inside the collection. It is not easy to move one object from a collection to another. OrganizeKit has no such limitation. You can have object independent from group, or use them with group. Therefore, there is no collection anymore. A collection is just a group. You can use it as flat or as hierarchy. You can also group different type of objects altogether, except they must be subclass of OKObject. (Maybe I can turn OKObject into protocol). In that case, in a simple group, you may have image object and text object. It should also allow loading object on demand, which will be useful for large data set such as file manager. So the main difference is that it is more flexible to use. I need these kind of flexibility for OuterSpace originally. And I hope it will be smaller so that it can be embedded instead of linked. That's why the license is MIT. > > > 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. How is different from NSLLog, which also supports different level of log with --GNU-Debug ? > > > 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. I agree. > > > 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. I mean you can swap views using Blocks framework as long as it follows the designed protocol. I guess it is not what Container aims. > > > 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 :-) I agree, but I am not sure OrganizeKit will work out in the end. I believe no one is really using CollectionKit and BookmarkKit. We can always replace them and change name if it fits. We will see. > > 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. I have to say your idea of containers is very similar to what I want. I starts from having the unified data source (OrganizeKit) and build several kinds of view depending the the data source. For example, iTunes-style browser view (category->artist->album) do not work if object is loaded on demand. You have to load all songs in order to know the categories if such information is stored in each object. Since Container is still in the early stage, I will pay attention to its development. :D Yen-Ju > > Cheers, > Quentin. > > -- > Quentin Mathé > [EMAIL PROTECTED] > > _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
