On 4/18/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > Le 18 avr. 07 à 08:24, Yen-Ju Chen a écrit : > > > On 4/16/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: > >> > >> Well, I name it OuterSpace because people seems to like "Space", > >> starting from OpenSpace.app. :) > > > > I just realize if we use OpenSpace manager, > > there is no issue about file manager. > > It is very straight-forward to import it (only the part of file > > manager). > > It is by far a much better choice than OuterSpace.app and Space.app. > > I thought of importing in it many times in the past. The two times I > took an in-depth look, I can to the same conclusion: it's very file- > centric, the design isn't really flexible and won't scale up without > rewriting everything from scratch. That's why I finally began to > write Space. >
Well, we can just add a layer of abstraction on top of the files. Then it becomes an object-centric manager. That is basically what I have in OuterSpace, which is copied from your Space.app. :D > > So if Saso agrees with that, I would like to spend some time on it > > and see whether it can be worked out, > > Feel free to do it, I'm not against using it in LiveCD 0.2. I don't think it will make it in time. I don't even look at the code in details yet. The last time I run it is a couple months ago when I asked where to find it. > > > It can also probably serve as a prototype for "object manager", maybe. > > I really doubt of this point. > > > There are two things I hope to clear first. > > 1. I prefer to decompose the whole OpenSpace Manager into > > several smaller components for easy reuse. > > I haven't really look at the code, but I believe there are many > > things > > which can be shared, ex. by dock and trash can, and maybe more. > > The interesting things may be some views like path view, calendar > view, icon view. But I'm not sure to remember them properly. That is part of my plan. Most of the common view can be shared by other projects. The way I see the managers for different types of objects are just specialized object managers. Music manager has only table view because icon view with preview does not make sense. But for photo manager, icon view with preview is the most useful one. AddressBook is basic a browser view with preview panel on the right. Again, it does not make sense to have icon view with preview for AddressBook because it takes too much space. So all the varieties of managers are specialized object managers. The file name becomes people's name for AddressBook, and song's name for Music Manager, so on. Once we have a relative flexible architecture for OpenSpace, other managers can be done easily by copy and modification. That is also why I will use BSD license, even for the application part, if no one objects. We can think in this way: if GNUstep/OpenStep does not provide NSDocument, how many applications will have to implement their own architecture just for open/save/close document ? If we can decompose OpenSpace into smaller components, it will be very handy for other applications, even if they just copy the code instead of linking to the libraries and subclass. > > > It may not be a target for LiveCD 0.2, > > but in my own opinions, I cannot see a better choice for the future. > > OuterSpace or Space ;-) Integrating Outerspace now may have some > interests, we would collect bug reports which would allows us to make > OuterSpace more solid. This is specially interesting if in the end, > it becomes a framework for building Workspace-like applications. It could be the current solution. Yen-Ju > > Cheers, > Quentin. > > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss > _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
