Is it possible to replace the current desktop on major os' with our own. Is there a way to replace the current window peer to be the main desktop window?
I don't see when the kernel group will have a kernel with a JVM so that we can begin to build the JOS userinterface and so I think we might start building a java-desktop that runs on all operating systems.
I 100% agree. We need to separate kernel development from the high level development.
So when are you going to publish a proposal? ;)
Ye gods! Something is moving in jos-ui ? There may be life here yet :)
To get started on the design of any of the UIs (cli, tgui, xui, et al), we need to develop, or at least prototype a main interface, server or other underlying framework for all UIs to use. To do this, we need to :
-- AveryRegier 03 July, 1998
|04 July, 1998|
The most object oriented desktop I know is the OS/2 Workplace Shell, which has some very good ideas very badly implemented. Windows does many similar things, generally in an even less flexible way.
I suggest having a package of classes, all someclassed from some kind of "DesktopObject.class" base class, and that any classes added to this package (that are subclasses of DesktopObject) automatically become known and useable to the desktop.
For starters, the DesktopObject base class should know how to display an icon at a location, be dragged and dropped somewhere else, be selected, how to pop up a menu by default allowing it to be deleted and its properties edited, and how to contain other objects.
It should have empty (subclassable) methods for when it gets created, deleted, dropped on another object, has another object dropped on it, needs to save its data, needs to load its data, responds to being double-clicked, etc. It should also be able to subclass the methods that create its pop-up menu, bring up its properties editing dialog, determine which icon to display right now, etc.
Then we need two subclasses of this thing for a standard file and a standard directory. The file one will (when created by the desktop) be supplied with a file it's attached to, and if you move or delete the object it moves or deletes the file. A subclass of this "DesktopFile.class" could be an "ExecutableFile.class", created from any .class file with a main method, or a jar file containing a package with the same name as the jar file, which contains with a class file with the same name as the jar file, which has a main method. (That's verification enough for me that they meant it to be runnable, anyway). When you double click on an ExecutableFile it launches the application. Another similar subclass would launch a browser window for html files.
A very important class would be the one to handle directories. "DesktopFolder.class". It has the same move/delete behavior as files, of course, but if you double click on it it it opens a window to view its contents, and it traverses all the files in its directory, tries to identify them (by type, extension, or some kind of database of extra info about them) and instantiate objects for them.
A fun way to do this would be to traverse the contents of the directory and run each one past each class in the desktop's "known classes" package, and run some sort of static "is this it" method in each one which either returns a reference to a newly created object fo that type initialized to point to that file/directory, or a null reference if it's not that type. Stop on the first hit. Organize the order these are called in so that base classes are only run AFTER all their subclasses are tried. Any file should stop on DesktopFile, and any directory should stop on DesktopFolder.
The Desktop class itself would be a subclass of DesktopFolder. It would always be open, would have a borderless window (I.E. a subclass of java.awt.Window, not java.awt.Frame. Or the JFC equivalent.) It would be sized to the full screen space, would remain behind everything else in the z-order, and wouldn't allow itself to be moved or minimized.
Shortcuts (OS/2 calls them shadows) would just be another class of desktop object, one which forwards some its method calls (I got double-clicked on so open me, I got right-clicked on so open my pop-up menu) to some other DesktopObject which it has a reference to internally.
So we have a hierarchy sort of like this (assuming wiki doesn't eat my indents, which show inheritance):
DesktopObject - Base class, visible & moveable on desktop. DesktopFile - Object attached to a file ExecutableFile - .class or .jar with recognizeable main method HtmlFile - A web page DesktopContainer - Double click on this and a window containing more DesktopObjects comes up. (Icon view, tree view, text view, etc.) DesktopFolder - Object attached to a directory Desktop - The desktop itself, a borderless maximized folder. DesktopDeviceList - Folder containing devices. Queries system to find available devices (when opened). DesktopDevice - A device (like a printer, disk drive, modem...) found in the DesktopDevices folder. DesktopPrinter - Drop an html on this and it prints, double click on it to see print jobs (which have associated DesktopObjects, so you can click on them and delete them out of the queue, etc.) DesktopTasks - Task list (what's running on system) DesktopTask - DesktopObject describing a task in the system. Object created when DesktopTasks is opened, allows them to be killed or given focus or their priority changed or...
Some of this (like DesktopTask and DesktopDevice) might involve interfaces... Details like that would still need to be worked out.
That's my suggestion, anyway.
This weekend I'll see if I have time to prototype some code (DesktopObject, container, file, and folder). No reason it can't run as an application under just about any OS with jdk 1.1.4 or higher...
July 27,1998 RobLandley
These ports so far inlude ls, pwd, whoami, cd, mkdir, rmdir, cat, mv, echo and rm -- with more coming out regularly.
I can run these in Pnuts or in BeanShell (two Java-based shells), for an all-Java UI. (Pnuts doesn't have it's own console window, AFAIK, but it should be able to run in BeanShell's console or any other console.)
I also can call these utilities from a native shell (like the Bourne shell) via simple shell scripts. And they would work in JOS too when the time comes.
The Unix utility ports are at my site:
Kevin Raulerson (9/98)
PS I received a question about price. These ports and all my similar developments will remain GNU-licensed open source aka "free" software. I will charge a small distribution and support fee for final versions obtained from my site -- exactly like a Linux distrubutor does. I'll waive this distribution fee for JOS contributors.
Here is an iddea: have a class belonging to JOS, say in jos.ui.* that is called something like this "SystemCommand" or "CommandSystem" that is purely static and has one method like this: "issueCommand(String command)".
All desktop functions, such as clicking on a menu item, use this interface to issue commands to the system. Clicking on "Find Files" in the JOS menu (hehe) would do this:
- AlexisPetrounias (Sunday, October 4, 1998)
What does anyone think about porting the Gnome project to Java?
Gnome is the GNU desktop that's under development. Redhat and Debian will be using it as the desktop for their Linux distributions.
Plus: We could reuse much code and most documentation. Also many resource files.
Minus: Gnome uses the GTK+ toolkit so we would either 1) have to write bindings for the Java/Swing API and have the extra GTK+ library's code hanging around, or 2) clone Gnome using the Java API, instead of porting it.
The apps would be a straight port if he we kept the GTK+ toolkit (#1, above), but would require less code and run faster if we rewrote them for the Java (Swing) API (#2, above). I don't know which would be best.
With support from two major Linux distributors, Gnome may very well take off and it seems best to re-use rather than re-invent.
What does anyone else think?
Kevin Raulerson (10/98)
Has anyone taken a look at Taligent's People, Places, and Things(R) user interface concepts? It's not exactly what you would call traditional or main stream. But a tremendous amount of thought went into analyzing the real needs of users, they way they work, etc.
Current operating systems provide little abstraction of complex data and relationships. GUIs generally do little more than put a pretty wrapper around the same data the user is faced with at a command line. Concentrating on a "desktop" metaphor results in excessive focus on single-user computing, rather than encouraging task-centered, collaborative, or community computing.
Because this is a higher-level way of abstracting all the files, objects, applications, and their relationships, users will be less intimidated.
Of course, with any such design, there should always be ways to get into the lower-level nitty-gritty stuff we developers like to mess with. But this should not be the default interface we present to users. Besides, after programmers spend some time with such a cool interface, they're bound to start liking it and adapting it to their own work.
I'd like to hear what others think of this. Too pie-in-the-sky?
Menwin Gatus (98 10 30)
Unfortunately, with Taligent being absorbed into IBM, there's not a lot of information about People, Places, and Things on the Web (especially screen shots). But here are a few related links:
I was aiming at Sun's Java PC, but if JOS is alive, count me in.
If anyone's interested I will start posting some of this stuff GPL'ed in January, 1999 or so.