Le 19 avr. 05, à 19:00, Jesse Ross a écrit :
I pretty much agree with everything Nicolas proposed. Here's my own
short
(or not-so-short) list:
1. Filemanager optimized for search/filtering (even if we don't force
everyone to use the flat (folderless) home folder I've mentioned
previously, I would like to be able to try it to see if it makes me
more
productive)
agree, and hopefully LuceneKit will help to have quick results here..
but I would say, filtering on the current window is different than
searching..
we probably wants something different (UI).
2. Metadata, both inherent (file type, date created, owner, etc) and
user-defined. Should be editable via an inspector/Get Info-type panel
yes, I agree. Technically it's another problem though..
3. ShareWith.app (I've mentioned before on discuss-gnustep) or
something
similar to what Nicolas proposes below
Hm could you remind me what's ShareWith.app ?
I know I once talked about a "shared shelf" application that would use
(probably)
a jabber infrastructure + publish/subscribe; you'd put things on the
shelf, and all
your subscribed buddies (or work partners) will see what you'd have put.
I want "well" icons -- ie icons where I can dnd things on it.
Obviously it will be the filemanager's job. The idea is to have a
simple way of handling this case (eg, when something is dnd on an
icon, if it's a "well icon" the file manager will launch the
associated application with the file and the dnd content in
parameters). That will handles cases like "I have this contact icon, I
want to send a file to this contact, I just dnd the file on the
contact icon", or "I want to print this, I dnd it to the printer
icon", etc.
4. No applications -- just commands or "Application Components" that
can
be used on specific types of data. Think of the OS X Font Selection
Palette -- developers would build components like these instead of
applications, and these components/palettes would be associated with
specific types of data (image, text, person) -- if a user installed
that
palette, it would be available whenever the associated data was being
edited. This saves from developers having to duplicate efforts, and
leads
to a more document-centric workflow.
That's what we want, yes. But in the beginning, we'll still have
applications;
and furthermore, some of the things you want to do with a computer are
better
done with "applications" than with components. Eg a ftp client.
The code sharing can (and we'll try) happend at a component level, but
I also
think it can (first?) happend at a framework and a document (with
NSDataLink)
level, if it's the case, that would be a great start :-)
For just a few examples:
a) An Adjust Image Colors command, that could be used on any image
type anywhere, whether that image is embedded in a report or is just a
photo you have in your photo library
Imho, that's the problem with components -- they need to work with
typed data,
which is not always as easy to characterize as "images". But of course
for some
data (like images, or sound), we can push that. Probably providing a
simple framework
+ associated bundles for the components themselves... so an app will
just use the
framework, which in turn will load and run the bundles. Adding
components will just
consist in adding new bundles to the system.
b) Text Size Change command, that will change the size of text in
annotations or text documents or layered graphic images or on document
labels or wherever text might be used
hm could you explain this one in more details ?
c) Sort command, that takes a list of items and sorts them
according
to specified criteria (alpha, numeric, date, etc)
I think that's probably best done using the services menu ?
5. Hidden system structure. Don't show anything that pertains to the
system -- only show the user their own files and devices, unless they
specifically request to see otherwise.
Here I guess there's two schools:
- show the real system to the user... but have a very simple system
- shield the system from the user.
I guess a good mix of both is probably ok (like on OSX)
6. Inode-based aliases (aliases that always point to the same file,
regardless of where it's moved)
7. History of selections -- badge selections so that I can see and work
with (and undo to) the selection I made just before the current
selection.
8. Undo everywhere.
9. No reliance on a terminal -- the command line should not have to be
utilized for anything relating to the system or its installation or
configuration. Viva Classic Mac!
J.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
