Le 24 nov. 05 à 01:28, Nicolas Roard a écrit :
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..
Yes :-)
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.
Exactly.
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.
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.
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..
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.
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 .
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.
ok
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..)
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
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).
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).
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 ?
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').
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)
hehe. No worries :-D
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 ?
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
- 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
- have some light tool implemented to do rudimentary usual autoconf
stuff
- think about Linux/BSD packages issue when you take in account poor
situation on GNUstep side
- have a tabbed shelf to at least initially replace GNUstep/
WindowMaker dock (Nesedah should feel at home)
- window manager (Nesedah should feel at home ;-)
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
