Hi all, following a discussion by mail, I copy here a summary of our goals and plan:
I, personally, have no idea what I can do to help Etoile to go into the direction Quentin and Nicolas originally intended. I understand the rough meaning of the pages in the Wiki, but the text is mostly way too blurry to start programming without conflicting with the ideas of the author.
Yes.. while the general goals are more or less known, the steps are fuzzy. Let me try here.. The goals are a small, easy to use, ergonomic, innovative desktop, components based, focusing on communication/collaboration and on projects. That's our goals. Now, how can we achieve that :-) - Small : obvious... we use gnustep after all - Easy to use: we try to focus on it, we kinda follow the NeXT HIG or the Apple one. I think it's more an attitude than a real process anyway, and I think we have people here that certainly can be good critics for ease of use and ergonomy. Finalizing our own HIG would be good too. - communication/collaboration: we should have services/frameworks so that applications and users can communicate easily with other users -- and thus collaborate. The idea here is to use something over Jabber for that. Whiteboard, shared file space, etc. Lots to do, but the jabber protocol is extensible, and I believe the recently committed jabber code will help us here. - projects: the general idea of projects is persistence -- eg, group your work environment into one project, close it, open it again days later to find it as you left it. How to achieve that ? Well, we have the Service component that is planned to evolve in order to manage that, by restarting applications when needed, etc. Technically, I think we'd store in a hidden folder some metadatas (list of apps, documents opened, positions of the windows..), and the filemanager would recognize those and then ask the Service daemon to restart a project. The applications would in turn need to answer to a few messages, like sending back their list of opened documents, knowing how to act on that information to reopen the documents, etc. Ideally most of the work would be done via a NSDocument subclass (so that applications would not need to do much themselves). - components based: that's one of the fuzzy one :-) -- what do we mean by that ? There's one approach -- the live component one, ala KParts. I'm not too convainced by it. For me, I'm more pushing it on three axis: 1) services ! we have them, and they are way underused. 2) applications roles -- roles are a classification/tagging of applications, but they could as well be a kind of "protocols", with applications able to do a role beeing related to their capacity to answer certain messages. Plug in StepTalk in the mix and you could have a very nice environment for scripting / user's custom jobs. Only thing needed to roles is a set of protocoles, and a kind of nameserver to reach apps. The Service daemon should do that job. Quentin, any comments ? 3) NSDataLink. I'm working a bit on it. NSDataLink let you link documents -- or part of documents -- to other documents. For me, it's key to étoilé. Instead of having one monolithic DTP application for instance, you could have a very simple one that only knows how to display NSImage and NSAttributedString. Then let's say you want to add math equations, and let's say you have a math equation editor application; you could simply create an equation in the editor, copy it, paste-and-link it into the DTP application. The DTP application will only receive the equation as an NSImage (which could be in fact a NSPDFImagRep) and display it. If you change the equation, the DTP application will be warned and will update the document automatically. Rince/wash/repeat for Diagram editor, Title editor, whatever. So insted of having one huge monolithic DTP app, you have a very lean one that only knows about boxes, references, text and images, and that's it. Many applications (or "components") working together, and imho that's our goal. - Documents repository, CoreObject, metadata and search -- the other fuzzy one... We have stuff for that: LuceneKit, some of the frameworks like the BookmarkKit, that go into that direction, but there's not much for the moment. There's some fundamental problems -- we want Unique ID for documents, we want metadata, projects, and all that is *hard* to do _properly_ with files that can be moved everywhere and thus breaking anything we'd put that woud rely on files/path. One solution would be to have a single, per-user, documents repository, that could be implemented as files, but that we would present through a specific browser hiding the implementation details to the user. Other solutions involves ZFS or other filesystems.. Comments welcome ! -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
