Home   Info   DevZone   Wiki  
UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ JosDesktop ] [ not logged in ] [ Web: Imported ] goto:  options
[ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

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?

Hi,
Should we start building something like a JOS Desktop right now?

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.

SebastianGolze 30-June-98

I 100% agree. We need to separate kernel development from the high level development.

So when are you going to publish a proposal? ;)

EricGriffin 1-July-98

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 :

So, any ideas? (oh, and do look over the UserInterfaceGroup pages, such as UserInterfaceIntroduction and UserInterfaceGroup )

As you are thinking about and designing the JosDesktop, please keep in mind that Jos will be a MultiProcessEnvironment, and we are (or will be, or should be) designing the JVM to work in this way. Thus, the design of the Desktop and UserInterface needs to take into account the launching and managing of separate Processes each with its own ProcessEnvironment. However you want to account for this in your ui is up to you, but your implementation of Shortcuts, Aliases, the CLI, and a lot of other things must be compatible with a MultiProcessEnvironment and not the SingleProcessEnvironment that the JavaPlatform is today.

-- AveryRegier 03 July, 1998

I think we should design JOS in two layers, a core and a UI. the core would handle things like the FileSystem and Devices and the UI mearly interfaced with it allowing new types of UI to be easily designed. We should design the core before the UI (all we need are the abstract classes and interfaces) so we dont 'mix' them, I think its very important to keep them seperate. -- DigiGod
04 July, 1998

Here's my go at it:

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

Yes, Java doesn't have multi-process environment in mind (How do you start another application from Java? You don't!). But many of our applications will have to not just start other applications, but interact with the system in many other ways (query for list of running processes, for example ). So, I propose that we work really hard the next days (weeks) to specify what help a JOS application gets from jos.* package(s). Not implement the package, just define it! Then, we implement it for existing platforms. That way we can start working on JOS specific applications. -- BorkoJandras

Sounds good so far, folks. I particularly favour the WPS-esque structure. We do need to separate what we're doing from what the core folks are doing, and to accomplish that we need interfaces, an API or two, some daemons, some understanding of the processes system we're going to have, and (IMHO) messaging protocols. Please also see ShellInterface. --BenKnowles
I realize that the ultimate goal is much more ambitious, but as a quick fix for an all-Java UI, I am porting several Unix utilities to Java (from Linux).

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.)
http://www.etale.com/pnuts/index.html
http://www.ooi.com/beanshell/

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:

http://spin.com.mx/~kevinr/home.html

Kevin Raulerson (9/98)
KevinR@spin.com.mx

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:
CommandSystem.issueCommand("run findtool");"

- AlexisPetrounias (Sunday, October 4, 1998)

What does anyone think about porting the Gnome project to Java?

http://www.gnome.org/

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)
KevinR@spin.com.mx

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)

References:

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 don't know about the theoretical aspects of things, but I'm writing an interactive Java shell and integrating it into a Java desktop I'm writing.

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.

JackWoehr 06-Dec-1998

We're interested! Welcome, Jack!

AveryRegier 07-Dec-1998

I'm a new member, but let me put in my two cents... JOS is really cool, but as far I can tell there isn't much to show for it. As a new member looking mostly from the 'outside' it seems pretty dis-organized. I am not meaning to offend anyone, but I think that all of the JOS enthusiasts should get together in a chat or somehting like that and sort through everthing... the source that's been done, what needs to be done, for each of the parts of the OS, what specifically needs to be done... and I think it would be great if we could put all of our resources together and have something downloadable maybe by April or so, that shows that JOS is a project that is going to happen and not something that is just being talked about... looking at the 1Q and 2Q reports the 1Q has over 2x as many hours as 2Q and what ever happend to 3Q and 4Q we are in 1999 arent we... and on the main page many things on their are very old like the constitution is called 'new' when on the page it says that its from May... anyways.. I know i'm sounding kind of rude... but I think that this is a really cool project, but it's hard for me to tell what going on.. and im sure for non-programmers that they come to the JOS site thinking that it's really great, and get lost and don't understand about WIKI and all that... anyways.. enough babble from me.. .let me know what you guys think about all of this.. and I might be wrong.. im just a kid anyhow......

JamundFerguson 17-Jan-99



Content of these pages are owned and copyrighted by the poster.
Hosted by: