On 11/25/05, Quentin Mathé <[EMAIL PROTECTED]> wrote: > Here is the url where you can look at the code : <http:// > savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/ > GWorkspace/TShelf/> > Well, unhappily it seems there are dependencies on FSNode framework, > I don't know if it is easy to rip them off.
Add that to the fact that it doesn't use NSTabView for whatever reason.. (you can easily _subclass_ NSTabView if you just want to have a different look..) anyway, as I said earlier, a shelf is not the difficult/long part, that's rather easy. A proper "spatial" view and the whole project management thing + desktop is more work :-) > > I agree that it could be a "desktop view", but I disagree with the > > pinning thing -- for me it should be automatic, really -- you just > > navigate between projects.. > > Yes, you might be right especially if we consider moving away from > overlapping windows, especially for Workspace. > > > Furthermore, I'm frankly not convainced of the utility of such a > > desktop view in the filemanager -- the desktop view will be by > > definition set up for your desktop size, so if you view it in the file > > manager with scrollbars, well, I'm not sure it will prove extremely > > useful. But why not, if not used as a "desktop view" it could be used > > simply as the "spatial" view in the file manager :-) > > I see your point, but if we move away from overlapping windows for > Workspace, it ultimately means we merge Workspace view windows and > desktop view, every Workspace views being just "pinned". Details > would have to be hammered down. Er... I'm not sure to really understand, what do you mean by "moving away from overlapping windows" ? you mean, different than the spatial mode in the finder / nautilus / gworkspace where each folder have its own window ? > > So.. basically, yes, we want a "desktop" view (which is more a kind of > > "super" spatial view -- a spatial view with all the niceties I listed, > > widgets, objects, etc); we could use this spatial view the same way we > > can choose list/icons in the file manager (we'll have > > list/icons/spatial/3d ;-) . But I'm not convainced by the "pinning" > > mode, for me any project will by default be in "pinning" mode, and a > > normal directory shouldn't go on the desktop.. Well.. I don't know, > > I'm not very convainced, but perhaps what we want is some easy to move > > back and forth the project and directory paradigms... > > Your last sentence outlines the issue. A project is just a special > folder object in my opinion, which means it can contains other > folders and you can move it as you would do it with any other > folders. More precisely the issue would be more about how you move > out elements in a project or a subfolder of it . Well, that's the thing.. I'm not sure a project is just "a special folder", at least, not more than an application bundle is also a "special folder". That is, it's an implementation detail rather than a feature. I would say, we should use "normal" folders to categorize/classify the files (along with indexing/search, object identifier thing, "intelligent" folders, etc), among them, the projects -- for the user they will simply appear as a specific kind of files. (ok, I'll try to refine my thoughts) A Project will simply be a bundle, you won't navigate in it with the filemanager (by default, as you can always have the possibility to "open" a project as you can do now with app bundles). Double-clicking on a project, that is, opening it, will simply launch the "viewer/editor" for the projects, which in our case would be the desktop app. This desktop app will display the content of the project, spacially, and will open all the documents in the project that were active the last time you used it. Applications will need a tiny bit of support for that, that is, Etoile should provide a simple framework that let applications serialize and reload the state of the document. Example, for a text editor, when receiving the message "project is beeing closed", it will save the list of all the documents opened, plus for each document a list of parameters particular to this application (in that case, it could simply be, "current line" and that's all). A project will contain the files you're working on, plus metadatas about the project and the project state, and you could also have other projects inside (they'll be considered as files after all) or even normal folders to organize your space / work. That way Projects provide not only a work space -- represented / accessed by the desktop -- but also a work state : it will restore the state you were last time you were working on the project. Basically, it's pushing forward the current "saving sessions" possibilities of GNOME/KDE, or, if you prefer (I do ^_^) it's trying to close the gap with the way Squeak manage Projects. > > Yes, of course. The cool thing imho is that we could have specific > > components leveraging the metadatas of a project.. (eg, using the > > project content/metainfos to have some widgets specific to the > > project.. imagine a "last svn commits" scrollview .. a message board, > > whatever..) > > That would be cool for sure, but more widely it brings us back to > Filter views idea (I may have put some notes on the wiki about it or > at least it has already been discussed in list archives iirc), where > most Étoilé applications would be a Filter view you can activate on > folders or documents depending on their UTI and extended with extra > utility components. It is like kpart view in KDE but done right. > To take an example, > - Open a Workspace view/window > - Move into Mails folder > - Filter menu (which is usually contain default view like icon, list) > is extended with a new entry "Mail view" > - Select "Mail view" in Filter menu > - Workspace view/window is detached from Workspace process and > migrated to Mail process > - "Mail view" is now loaded Uh.. no, I'm not really sure they are an example of a filter ! they are standalone "objects"/widgets on the desktop, that could do anything, and possibly reading their host project metadatas... I mean, filters are interesting, but by definition you could argue that *any* program could be assimilated to a filter.. > The cool feature would be you can move instantly back and forth > between "Mail view" and "Icon view" hosted in two different processes > but bound to a unique and shared model. I know it is very difficult > to implement for various reasons we have discussed in the past (take > a look at list archive). Yes, I know very well, which is why I'm not sure about them... well.. > For a composite document, it would work identically, to edit a > document component you would select it, look at Filter menu to select > the editor you may and want to use for this precise component, then > the complete document would be migrated to another application. > Major problems will start to arise when you try to edit a document > component with two editors simultaneously because data have to be > reloaded and synchronized back and forth, resulting from the fact > each application runs in its own address space and we have no > document process where its model/data are always available (without > reloading it). Well, not only that, but there's the fact/problem that this idea only work for a limited range of datatype imho -- for complex stuff, a real, dedicated app, would be better than fighting/choosing among the filters. Now of course we could have such dedicated app based on filters, and if I remember, that's what we agreed in the end.. anyway that's a bit pie in the sky for the moment, as we _don't_ have a proper infrastructure for doing that, not even a proof a concept... > Yes, but I wanted to insist on the fact they should be more than what > we know as "virtual desktop", they should be more closely related to > 'user account' concept (that's why I have written about 'virtual > account'). hm... could you be more precise ? > > So, shall we try to push something forward soon ? > > Outside of 0.1 release content which is already detailed (I have to > finish to backport from Cocoa to GNUstep my last changes to > PreferencesKit), I have no precise ideas. > It would be cool to : > - finish IconKit, ServicesBarKit Yes.. at least IconKit.. (any volunteer in the room ? shouldn't be a long work ^_^) I would add the BookmarkKit ? or is it working ? been a while since I checked :-/ > - write system configuration glue code for Preferences related > applications when I will have committed them soon or may be rather > write a SystemConfiguration framework based on GNOME system-tools- > backend er.. ? > - have some light tool implemented to do rudimentary usual autoconf > stuff is it really something *we* should do ? > - think about Linux/BSD packages issue when you take in account poor > situation on GNUstep side yes, but well, we have only a limited range of action here.. > - have a tabbed shelf to at least initially replace GNUstep/ > WindowMaker dock (Nesedah should feel at home) > - window manager (Nesedah should feel at home ;-) Yes. I checked Wtf, and it works, although graphically nothing is done (eg, decorations and icons are plain frames, that's all).That would be my preferred goal, but perhaps a mid-term goal. The other possibility is to use another window manager, say, Metacity (I mention it because my wmaker is broken for some reason and I used it instead, and it's quite useable, although there's some focus problems and the infamous appicon appearing... but, it's the default manager for gnome, thus ensuring it's available nearly everywhere, it's customizable, and doesn't provide its own dock or menu... thus a quite good match for us, and solving the problems would be a good thing for gnustep anyway). See http://camaelon.blogspot.com/2005/11/shiny-screenshot.html -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke
