>> 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).
Yeah -- I guess I see it more as a filtering as well, but filtering on a lot of metadata, not just file name. And, if there are folders in the folder you're filtering, then possibly doing a recursive filter as well. >> 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. Yeah -- I'll try writing a spec for it tonight. >> 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. Why does that have to be a separate application? Couldn't it be treated just like a drive that you're connected to? You would view the contents in a normal file manager window, and modify attributes on the files via an inspector panel. I guess I don't understand why you would need a different mental "mode" and thus, a different application, for browsing and modifying files on a remote disk rather than a local disk. > 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". Could we say, though, "If component ABC is the current area of focus or currently being edited, load palette XYZ"? So, for example, if we're looking at a Text.comp component, the we would make active/available FontSelection.comp and ColorSelection.comp and Sort.comp and whatever else we think you would use when editing text. > 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. Exactly. Developers wouldn't make applications anymore, they would think in terms of "what type of tool could I provide for manipulating data?". It's the Unix philosophy applied to the desktop. >> 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 ? Does the above explain it? >> 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 ? Services in this desktop paradigm _are_ the applications. When you want to manipulate an image, you don't load Photoshop: you load components for your brushes, and your color selection component, and your layers component and anything else that relates to your workflow. You completely eliminate the bloat that comes from applications because you only load the palettes/components/services that you need. And it relieves developers from having to reinvent common palettes/data manipulation mechanisms -- instead they can focus on making one palette or service that manipulates one type of data especially well. It's the idea behind providing a File Selection Dialog or Font palette or Color Selection palette as an interface "freebie" in systems like OS X -- simply extended to the next level. Not to mention that it makes the user's life a million times easier because they only have to learn _one_ palette/component/service. Instead of having, for example, a different Color Selection palette/dialog for each application (I can think of at least 5: OS X system color selection, Photoshop, Illustrator, Flash, Word) -- you have one component that's shared across the system. >> 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) Yeah -- OS X is pretty close. I still think you could get away with only showing the user their home folder by default, given the following situation (I'm thinking of this in terms of a default OS X install): - If there are no applications, we don't need an Applications folder - New 3rd-party components users want to install could be dropped onto the icon represeting the system in ShareWith.comp (was ShareWith.app, but since we're not making apps anymore :) -- the system should know what to do from there. Therefore, we don't need a System folder or a Library folder - ShareWith.comp can also have icons representing other users on the system -- no need for a Users folder - If users need to update/upgrade the system, they run an Update System command and everything is updated -- no need for a System folder to add stuff manually If root wants to see everything, though, let them see it all in the standard Unix fs -- just like OS X, if asked, can show dev, bin, etc. I realize I need to spec out ShareWith.comp better -- like I said... tonight :) J.
