Why not use JDistro ?

Submitted by gcollin on Tue, 05/18/2004 - 11:41.

JDistro (http://www.jdistro.com) is an open source desktop in Java.
Whereas the graphical part won't work (because of Swing), I think there are many parts that can be very helpful for Jnode:

- Application launcher from internet, with jnlp, InstallAnywhere .lax, etc.... support.
- File distribution via a P2P network tool.
- A good command shell (jsh)
- Others....

It definitively need some refactoring to make it work with jnode, but I think a progressive integration of JDistro stuff into Jnode high level functions would be very helpful.

At the end, JDistro could be (one of) the desktop of Jnode, avoiding many rewrites of the same kind of code between the 2 projects.

I'm one of the developers of JDistro, and I know that guillaume (the lead dev.) is very interested in Jnode.

Gérard

‹ Prepare for new release Does Jnode fall into the Default Permit trap? ›

Time to look again?

Submitted by Stephen Crawley on Thu, 08/04/2005 - 03:06.

It has been over a year since this topic was created, and the
Classpath implementation of Swing has come a long way since then.

Is it worth taking a look to see if JDistro over JNode is now
a viable option?

One of the bigist problem

Submitted by hagar on Mon, 08/08/2005 - 20:56.

One of the biggest problem with jdistro, as I see it, is the licence. JNode is LGPL and to me it looks like JDistro is GPL, so we will get a license problem if we add it to JNode.

Martin

Maybe not a "real" problem

Submitted by gcollin on Thu, 09/01/2005 - 08:57.

I know I and Guillaume are willing to work with Jnode, so I'm sure we will find a solution for this.
Guillaume is not there for the moment, but I guess this will be ok.

Solutions I see for the licensing stuff:
- JDistro goes LGPL. Why not ? but maybe difficult to achieve.
- JNode goes GPL.
- JDistro make a special license LGPL compatible for JNode
- JDistro runs under JNode, filling some abstract interfaces provided by JNode for desktop integration, like mime-type, windowing, etc....
This way there is no need to change any license, the glue between the two can be LGPL.
We could even put some features of JDistro as LGPL, like mime type support, JDNC, etc.... so that they can be directly integrated into JNode.

For a technical point of view, I need to make JDistro run with classpath library ?
What is the best option ? Use Jnode (how to debug ?), kaffe, sablevm ,etc... ?

Gérard

JDistro and JNode

Submitted by lsantha on Thu, 09/01/2005 - 09:31.

I'm glad that you are willing to interoperate with JNode. In this manner the licensing issues can be solved esier too.
But to make JDistro run on JNode might be a more complicated task.
As a preliminary step I suggest to investigate the more general problem of interoperability of JDistro with GNU Classpath. For this an alternative GNU Classpath based JVM might be better (like JamVM, Kaffe, Sablevm, gcj etc.), since it will be easier for you to work and debug. This might be a good start to evaluate what should be done, what is missing etc, and then we can see what else is needed for JDistro to run on JNode.

Levente

working on it

Submitted by gcollin on Tue, 10/18/2005 - 14:30.

Progresses are slow, because **NOTHING** works with classpath library now.

gc

Trying SableVM

Submitted by gcollin on Thu, 09/01/2005 - 11:59.

I'm trying SableVm right now, because it has basic debugging support
This involve downloading Eclipse,etc....

I'll keep you posted.

Gérard

Lets think laterally

Submitted by Stephen Crawley on Wed, 08/10/2005 - 00:37.

It would be a real shame if JNode turned its back on JDistro (or
any other decent Java Desktop effort) just because of a minor
license incompatibility. If a pure Java Desktop is to be a realistic
goal for JNode, you/we will have to work with other people to
get there. It will take too long if we have to start from scratch
on the desktop + application ecosystem, yet again.

Lets think laterally about this. Do we really need to "add JDistro
to JNode"?

What about the alternative of getting JDistro to use JNode as an
execution platform? (In the same way that the JDistro guys currently
use Sun JREs as their execution platform.) I don't see how there can
be any licensing issues in that, especially if a clean separation
between the two codebases is maintained.

In the far distant future when JNode + JDistro may be mature enough
to replace the Windows or Linux ecosystems on people's desktop. At
that point, the people assembling the distro / installer that
packages JNode + JDistro + ... will need to revisit the licensing
issues. But if the GPL is sufficiently flexible to allow RedHat
et al to mix GPLed and non-GPLed code in their distributions,
surely it (or more to the point, the various copyright holders who
make up the JDistro community) can cope with / adapt to this
scenario!

The two projects are complementary.

Submitted by desnoix on Wed, 05/19/2004 - 06:32.

I also answered to Valentin on this subject here:
http://www.javalobby.org/thread.jspa?forumID=17&threadID=12545
Both JNode and JDistro are already quite modular and I don't see any major problem to run them together (except that Swing is required).

2 way to do that

Submitted by gcollin on Fri, 05/21/2004 - 08:28.

There's 2 things, IMHO, we can do:
- Either wait for jnode and classpath to grow up until jdistro can work on it
- Or we can adapt JDistro to run into the current classpath. For example, we can just take the non-UI parts (The ones that run any application, that auto-detect them, etc...) and 'port them' to classpath.

I think I can volunteer to the 2nd thing, but I wouldn't like jnode's guys to write the same code. I would like them to tell: Yeah, do that for Jnode. JDistro will be the "official" desktop for jnode.

They don't seem to be very interested... Maybe it's too early.

Gérard

What is JDistro built on

Submitted by N8Dawg on Fri, 05/21/2004 - 13:12.

What JNode needs (and what i'm supposed to be working on) is a good graphics driver model. I want an interface thats flexible and fast. What I've been thinking is why not have the graphics drivers target the Java 2D API. Some stuff would be generic across all drivers, eg font rendering but a good subset of the Java 2D api could be the API graphics drivers have to target. Once we have a working implementation of Java 2D how hard would it be to build Swing and JDistro on top? An advantage of doing things this was is development work can happen in parrallel on existing OSes. If developers know they're targeting Java2D, this functionality allready exists.

Java2D driver

Submitted by gcollin on Sat, 05/22/2004 - 10:21.

I guess everybody in java world knows Java2D, so I think it's good to base the graphical display on it.

My .02 advice would be to have a base graphical driver containing all the pure java2D code.
Each specific graphical driver would subclass this and do the display board specific screen init. By default prue java code would be used, but the driver caneasily overwrite any java2D functions to use hardware specific features.

My other .02 (that makes .04 !) is to make a special API for window manipulation (resize, tofront, display border,etc...) because I guess hardware graphical chipset have special functions for this....

Maybe you can use this project (as a backend or as source for inspiration) who seems to do good image/text manipulation (I have not tested it):

http://www.lowagie.com/iText/docs.html

Gérard

Architecture

Submitted by N8Dawg on Sat, 05/22/2004 - 18:02.

I'm been a graphics programmer for a number of years, studied the hardware etc. What a good 2D driver will primarily give you is a fast way of bit blitting graphics memory, on-screen and off-screen and doing things such as changing hardware pointers eg double buffering.

Theres no hardware functionality to help with such things as window resize, tofront display, border rendering etc except for the functionality I just mentioned. And thinking about it, this is all you really need to have a flexible fast interface.

All this however might change with microsofts release of longhorn. They want to leverage the power of 3D hardware to accelerate the desktop. Indeed this makes sense on a number of levels. Z-ordering of windows just becomes a number in a z-buffer. 3D-rendering in windows becomes automatic and painless.

The problem in JNode is we dont have access to the APIs to drive the cards in 3D-mode. NVidia and ATI just wont release open source drivers for 3D-mode for the foreseable future at the very least.

The other function of modern 3D gfx cards that we 'MIGHT' be able to leverage is alpha blending. To do this in hardware would be a very nice win.

Looking through the Java3D API more closely, the only package I think it neccessary for a graphics driver to target is the java.awt.image package.

This contains the Volatile image classes (neccessary for efficiently using off-screen video memory) and the alpha blending stuff with the colormodels. I believe that someone can build the rest of the Java2D library in a fast efficient manner from just a implementation of the java.awt.image package.

The primary challenge to doing this would be to provide a model that was secure, and provided multi-application resource locking and management. The whole resource management of video card memory is a complex subject.

Supporting Java3D would be very mice but unfortunately a project for the future. I suggest having a driver infrastructure, and to initially support this with a software driver.

The driver can be efficently accelerated with things like SSE2 and MMX on intel/AMD at least. If the model is good then it sould be easy for video chipset manufacturers to start adding 3D acceleration support incrementally, and release class-file only drivers.

I can't see this happening for a while unless one of the following happens:

  1. JNode becomes a runnaway success very quickly so the video card manufacturers feel compelled to support us.
  2. someone reverse engineers the driver's for Linux or windows. (Unlikely considering the sheer complexity of current GFX drivers
  3. Someone provides a way to run Linux driver binaries under JNode securely. Hard considering the amount of Linux kernel utilities that would have to be supported and this still wouldnt be cross-platform.
  4. The most likely option, someone is prepared to sign an NDA and work on an implementation with the co-operation of the GFX chipset manufacturer.

What are peoples thoughts on the 2D support? If this is the way forwards to get 2D graphics support/acceleration under JNode I think it would be helpful for people to start implementing Java2D using java.awt.image as a base. From Java2D people can start implementing the AWT, and from the AWT people can start implementing Swing. With Suns class libraries this is how the layering works anyway. I see no need for our widget set. Lets stick with what we know works and is powerful, Java2D, AWT and Swing.

ok for a software Graphics2D as first prority for GUI

Submitted by Fabien D on Mon, 05/24/2004 - 19:40.

Here is a reference I found :
bresenham algorithm for line, arc and circle
It's based on integer computation (that's fastest than floating point computation) and can be used for Graphics2D implementation

Fabien

Wait for GNU Classpath

Submitted by brihaye on Tue, 05/25/2004 - 08:14.

Hi,

These powerful algorithms should be integrated to GNU Classpath soon :
http://mail.gnu.org/archive/html/classpath/2004-05/msg00087.html

BTW, what it the synchronisation process with Classpath ? I've found a bug in URLStreamHandler (a "==" test on a non-interned string) which is now fixed in Classpath.

Furthermore, I am examining JNode's graphic code. The doDrawLine method's name is somewhat misleading : shouldn't it be called doDrawHorizontalLine ?

Concerning the font engine, the code below :

for (int i = 0; i < text.length(); i++) {
// get the index for the needed glyph
final int index = encTable.getTableFormat().getGlyphIndex(text.charAt(i));
Shape shape = glyphTable.getGlyph(index).getShape();
if(text.charAt(i) != ' ')
gp.append(shape.getPathIterator(tx), false);
tx.translate(hmTable.getAdvanceWidth(index), 0);
}
g.draw(gp);

... will only work for scripts running from left to right.

More to come on this topic...

Cheers,

p.b.

sounds good too

Submitted by gcollin on Sun, 05/23/2004 - 08:16.

I'm fine with what you said.

Just 2 thingies: there is an opensource ATI 3D driver (dri.sf.net) and one for nvidia (http://utah-glx.sourceforge.net).

I think some graphics board accelerates drawing 2D lines, circles, etc... and that could be helpful to jnode.

I think it's too early to support 3D in jnode. Let's get a good 2D driver architecture working, then maybe move on to 3D.

Gérard

This makes sense

Submitted by mattzerah on Sun, 05/23/2004 - 01:42.

I'm not a graphics programmer, so i'm not sure what needs to be done RE displays and windows etc. But what you have said here makes sense to me. I have been wondering about widget kits and all that stuff, and wondering why we just dont try to implement basic AWT components (like Frame and stuff) that Swing uses, and swing being lightweight should be able to be written (or ported) entirely using that basic AWT implementation.

Althought I"m not completely sure what i'm talking about, so its a bit hard to suggest such a thing Smiling

I like what you have proposed. Get the 2D graphics working (which I suppose will need the font engine working as well, as someone has been trying to work on) and then see how we go with the rest. If there is something I can work on to help achieve this goal, then I am starting to get some time free for development, so count me in.

Does anyone else like this plan for moving forward with the graphics ?

Introducing JDistro

Submitted by gcollin on Fri, 05/21/2004 - 20:01.

JDistro is entirely done in Java.

It consits on:

- A Multiple application runner runtime. It can discover and run .jar, .jnlp, applets, and now some java2 microedition midlets. It has a repository of compatible applications with some of them you can directly download and run. The tricky part here is to run multiple applications in the same JVM, but I guess this feature is not needed for jnode.
- A graphical desktop ontop of it (korte and wharf). The desktop is pure swing, so if you have swing, you can use it as is. Desktop can associate icons, select/kill running applications, etc...
- Some goodies, like a java command shell, a p2p distribution engine, a virtual file system....

What I proposed to do was to port the application launcher runtime, so that you can have .jnlp support, have some common way to find and launch applications....

Later, with java2D and swing code, the desktop in itself could be used.

Gérard

Not that I have tryed nor see

Submitted by hagar on Fri, 05/21/2004 - 08:58.

Not that I have tryed nor seen it live, but how compairtible are JDistro with the JDS(Java Desktop System), release 2 from Sun? Can applications designed/used in JDS work "out of the box" in JDistro. It could be nice if JNode could go with in the slip stream of something bigger.

Regards,
Martin

JDS = Linux + Gnome + Sun JRE 1.4

Submitted by desnoix on Sat, 05/22/2004 - 08:58.

JDS is not a desktop written in Java. Instead, this is a native desktop mostly written in C and using GTK, X, ...

JDistro can launch native apps. And if you're running a X server written in Java, it is possible to run them on the desktop (I have try WeirdX with limited success). But JDistro is really oriented to Java apps.

Quality of WeirdX

Submitted by ravn on Sat, 08/27/2005 - 00:01.

I am interested in hearing what worked with WeirdX and what didn't. The reason is that this is perhaps the best starting place for giving remote computer access.

--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"

Any java application

Submitted by gcollin on Fri, 05/21/2004 - 20:05.

One of the goal of Jdistro is to run all java applications unmodified.

Of course it's only a goal (but with Isolate API I think we'll get there soon), but most of little java apps are running directly in JDistro.

The idea is
- either you install your java application, tells Jdistro to detect it, associates an icon, file types, etc... and then you can run it inside the JDistro desktop in just one click of a button !
- Or you run applets, jnlp applications directly from the web server !

I guess the little java applications in JDS can run.
Gérard

Java Desktop System == Linux

Submitted by monochromata on Fri, 05/21/2004 - 10:19.

AFAIK the JDS is a Linux distribution and has nothing to do with Java except the name.

Sebastian

The page is down: Parse erro

Submitted by hagar on Tue, 05/18/2004 - 12:42.

The page is down:
Parse error: parse error in /home/jdistro/www/index-en.php on line 351

up again

Submitted by gcollin on Tue, 05/18/2004 - 15:52.

Yep, as soon as I submitted this, the jdistro main page wen't down Eye-wink

missing }

Submitted by desnoix on Wed, 05/19/2004 - 06:22.

Sorry -- I hate scripting languages Sad.