On 11/23/05, Quentin Mathé <[EMAIL PROTECTED]> wrote: > Le 21 nov. 05 à 23:30, Nicolas Roard a écrit : > > And most of the work so far has been > > about frameworks, not applications -- the wished workflow / UI vision > > is rather fuzzy. > > I have a rather precise vision (at least not so much fuzzy ;-) but I > haven't take time to completelety write it down on Étoilé wiki or > here on etoile-dev. I have discussed it a bit with Jesse some times > ago, but I have to put it clearly somewhere in a well thought manner.
Well, you should write it down.. really.. > I have reformulated recently our About section with this wishlist to > allow more precise ideas to emerge and be discussed. I'm happy to see > it is useful :-) Yup :-) > > how can we actually fulfill these goals ? What I think is important > > (in contrast to existing desktop such as KDE/GNOME) is the emphasis > > on: > > - project management > > - versioning > > - first class objects (e.g., persons, locations, devices, etc.) > > - indexing and search > > For me, it is also very important to have very streamlined > Preferences/Setup UI because that's one area where KDE/GNOME are > really lagging behind when you compare them to Mac OS X. Yes, I agree with you. It wasn't on my mind, but you have an obvious point. > Yes, libsvn may be a good choice but I would be curious to know how > it could compare to ZFS (snapshot, journaling etc. features), > moreover at low level ZFS seems to behave like a database by > implementing FS semantic on top in an optional layer, which is quite > interesting I would say. > libsvn and ZFS are both different kind of beast, and ZFS would need > to be extended to support a simple versioning scheme, so libsvn is > probably a better choice initially (moreover it is available on most > usual OS). > > About ZFS : http://www.opensolaris.org/os/community/zfs/ Well, ZFS looks very interesting, but : - we're far from implementing this feature right now, so.. - as you said, libsvn is available easily everywhere Why not ZFS, but anyway neither ZFS or libsvn are under work in the next weeks.. I would really like an étoilé-based OS that would let us experiment with all theses kind of low-level technologies -- but I'm trying to be pragmatic, we already need to work on the "core" functions of étoilé before, some priorisation is needed imho. > > Basic UI > > ======= > > > > Here is the UI I propose: > > > > 1) a file manager (GWorkspace for the moment) to present the > > filesystem. You can present a folder content using different kind of > > representations (list, icons, mini icons, "spatial", etc.) > > I don't think it is a wise idea to include GWorkspace, because it > conflicts at many levels with our goals (index/search model, both > spatial and non spatial, one shelf by window, nextish UI etc.) > Moreover I really don't like the way it is coded. > As a temporary solution, we could include Saso's Workspace because it > is less featured but lighter and cleaner. However it doesn't really > fit with Étoilé vision, and when I looked at the code my initial > impression was it would be difficult to evolve it in the way I would > like (without rewriting most parts). Why not, I proposed GWorkspace because it's already here and works, but we can provide Saso's workspace instead, ideally include it in the svn, so we'll have more flexibility for the future (which we couldn't really have with GW unless we fork it, which kinda defeat the point). My point was more, "for the moment, try to focus on what's novel rather than the filemanager -- once that's done, work on the fm" (which will be needed anyway to integrate spatialization features and indexing/search). > > 2) a tabbed shelf where you can drag and drop anything on it, not just > > applications (although of course it will be used mainly to put and > > access applications). The existence of tabs let you categorize easily > > the applications, and have specific tabs for holding running apps for > > example. Basically I want that: > > http://www.roard.com/screenshots/Dock6.png > > Yes, such tabbed shelf will be used in a way or another so we need > one for sure. I don't really like the screenshot look and feel but > I'm sure Jesse might be able to fix it ;-) Ah, damn, I like it ;-) but hey, whatever Jesse will do is good :-) > You should take a look at GWorkspace tabbed shelf, it may be reusable > without lot of refactorings but I'm not sure. Possibly, though frankly it's not that much work (or, not that much work for the base feature that GW's dock has), so I'm not convainced we'll gain anything by reusing it, but we should have a look, yes. > > 3) a desktop area where you can drag and drop objects (more on that > > later) > > > > You interact with folders and files on your computer via the > > filemanager. Indexing/search can also allow for categorizing and > > "intelligent folders" (showing the result of a search). > > I would say a desktop view rather than a simple desktop area because > imho it should be just another Workspace related views like icon or > list view, but with the possibility to pin it on the background. In > my notes, I have thought about something similar under 'Work Table > view' term (this is inspired by Aperture Light Table). > My objection is more about the way it runs and interacts with > Workspace, I think it should be part of Workspace and not a separated > application. 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.. 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 :-) 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... In anyway those are more philosophical reservations right now; as technically it shouldn't really add any difficulty to "pin" directories on the desktop, we could implement it to try if it's useful, possibly. But i'm not convainced, we need to think about the process. > > When you actually open the project, it doesn't open in the filemanager > > though. Its content is displayed.. on the desktop itself. So the > > desktop is NOT a global area like on MacOS/Windows/KDE/GNOME -- it's > > the content of a project. > > I would prefer it can be browsed/visited like a normal folder, but > when it is maximized (which means pinned) in one way or another, its > content is then displayed on the desktop and the content of the > screen is itself reorganised to fit the project settings as when you > switch from one user account to another one on the fly. Well, that's where we seem to disagree :-/ I don't know, I need to try things before. Right now I'm not sold to the idea. > > In addition, the desktop should be able to display more than simple > > icons -- it should display images, specific objects (draw lines, type > > some text, etc), or even "mini apps" ala Konfabulator. > > Mini apps would be an optional way to launch Étoilé components which > supports it; such components would support to be loaded anywhere > (inside documents, folders, projects) unless we decide to restrict > their use in project areas only. 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..) > > In that way, opening a project will actually put you back where you > > were; and the desktop can finally be again used as a *work* desktop, > > where you can drag and drop stuff you're working on, organizing them > > (we could have some things like what aperture does, or piles, etc.). > > Yes. Aperture seems to rock I agree :-D Yes. And the piles idea is not idiot too. So we should implement that once and for all to have it everywhere :-) > > With support from the window manager, the projects will in fact be > > able to act as virtual desktop, and you could easily switch from one > > project to another. > > hmm, projects should act as virtual desktop (or rather "virtual > account") by default in my opinion. yes, that's what I said ? > > Proposed steps > > ============ > > > > For now, unless somebody wants to work on other things, I think we > > could simply focus on the basic desktop elements: > > - the desktop > > - the shelf > > - the filemanager > > - a display manager for X > > I basically agree, but you are forgetting Preferences related > applications :-) I outline it because I have spent most of my time > recently working on them. Yes, I know :-/ -- I don't know why I didn't have it in mind, while at the same time I was seeing your commits passing by :D (damn I'm either stupid or tired, probably a good 50/50 mix of those) My only excuse was that I was trying to pin down what ideas we were pushing forward for the "general" UI, and I didn't think of Preferences as part of it, as it was obvious for me: obviously sane preferences are integral to a good UI experience) > I would be more precise, we need : > - tabbed shelf > - generic layout view à la InDesign or others (but far more limited) > - custom layout view tailored for project areas (inspired by Aperture > probably) > - workspace / file manager (with support for features introduced in > previous lines, but not immediately I would say) > - window manager > - session system > - preferences utilities > We could include too : > - services bar (NSStatusBar, NSStatusItem) > - Workspace related frameworks which supports indexing/searching, > versioning, FS operations, metadatas support on first-class objects > (for now named CoreObject and ExtendedWorkspaceKit) > - few extra applications would be welcome Yes. I mainly highlighted the things related to the "desktop" / projects ideas.. (I didn't really talk about the filemanager for example..) > > For the display manager, garma had one that we could possibly reuse; > > It is not in a usable state, but if someone is interesting to work on > it, it may be a good choice. At later point, it would be cool to > provide the possibility to run Étoilé in a closed virtual environment > (may be by developing a minimalistic OpenGL window server :-)… this > would be cool, because you would be able to run Étoilé on Mac OS X > without X11 beast to take an example, if we reuse cairo library for > the graphics engine it could be not much worse than writing a > complete Quartz backend . Completely agree. It's a bit orthogonal to Etoile though, it's more a GNUstep point. But obviously we'd take advantage of it ! :-) Note that I tried Alex Malmberg's OpenGL backend, and it seem to works reasonably well to experiment with it (though it's using backart for the inside, not cairo, but hey, close enough, and probably faster!). Now, if only this damn ati radeon 9600 would agree to work on linux... :-/ > > Before starting anything though, what are your opinions about what I > > outlined ? Specifically, the desktop/project management and the first > > class objects ? > > Very good, we will be able polish UI when we will have some elements > to combine together for experiments. ok > > The goal would be a major release of étoilé before the fosdem. A > > release of the current frameworks could also be nice before that ! > > Yes I hope too. So, shall we try to push something forward soon ? -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke
