app with multi-GUI or app with one GUI ?

Maybe GrafiXML
can be that factory : it describes a UI in XML and render it the way you want (swing, swt, java, c++, ...)

Fabien

I found a GUI designer named grafixml

It is using a standardized xml model named usixml whose aim is to design UI with abstraction of the implementation (swing, java, c++, TUI, ...).

PS: I have not tested it yet but it sounds interesting.

Fabien

It is nice to read how many ideas come up on differnt user interface topics.
However we should not forget were we are at the moment, what we have at the moment, what are our short term and longterm goals and what JNode is.

JNode wants to be PURE Java. Do not even think about bringing native code in in any form. As it was said already, that probaly can be done somewhere else.

Regarding the UI topics a realistc order of implementing things could be the following:

1. Make the console work fine. (Just try to type a longer command than the width of the screen, or the available space between the prompt and the rigth edge of the screen, you will se what I mean. What is that ghost cursor there ? Why is the console so slow? and so on... )

2. Optimize charva performance-wise. Reduce the unneeded work it is doing all the time. Try to implement the missing components like JTree. Doing all this in the true spirit of charva (that is: with respect to Swing). There are lots of other things there. As soon as you strat to work on it you will see. Curently due to the way charva is implemented you cannot run two charva applications in the same time in different consoles. The way it uses threads and satic methods are among the factors that causes it.
Charva is extremely important. Stil for quite a while JNode will not have usable graphics. But in the meantime JNode will become suitable for running a lot of headless apps. Soon it will also be possible to develop under JNode, (at least small things , like tests or small prototypes). Charva canhelp a lot in all these things. Further when will we have a normal GUI we also will need console and text mode just like we need it today with other OSs. Not to mention when you log in to JNode with a simple text mode client. Charva apps should work there too. So there is ony one honest way to think about text mode UI in JNode today and that is: in the long term.

3. It is not clear yet whether an AWT implemenation based on Swing is the way to go for JNode. It might be easier to prive a JNode AWT from scartch. And there is some (or a lot of, if you like) things done already there. We have the WT components which could serve for this. They are as they are but they can be and need to be improved. JNode will need a basic desktop any way and WT could help there. It could also help to set up AWT much earlier than the time when Swing in classpath will be usable. The current wt component sintactically implement the corresponding awt peer interfaces. However the implementation methods are empty at the moment.
On the other side there is a small awt demo using an other set of components (minimally implemnted) that tries to darw something on the screen. It normally should draw circles and arcs but it just happens to draw lines instead. It woud be good to find out why. There are problems with the font rendering too. The speed of course but even worse is that it draws a really hardly readable mess intead of letters. I wonder why?
A usable AWT implementation would just be nice, after that Swing goes by itself.

4. Swing of course, is the next step. The best thing to do for that is to contribute to Classpath, and always look for ways to try to test soemthing from it under JNode. This would keep you busy for an other year and a half

5. By that time the SWT implementation on Swing will be usable anyway. And we can try to run JDistro too, and the 3D desktopt that Sun is working on these days, or maybe an other GUI based on the Jazz (a zoomable graphic library) that maybe will be created by somebody...
There are also projects (abandoned ones) that tried to implement an X server and X client in pure Java around year 2000. It might be possible to integrate them into Jnode as well.
However, since JNode should run any Java application it would be hard to make a list things to run on JNode, especially so becuse some of them wil be invented tomorrow and others a few days later...

So as you can see, there are just plenty of things to work on now, under the current conditions even if free Swing is still quite far.
At the moment I'm working on a small editor based on charva, and generally on setting up a simple development environment under JNode (edit, javac, java).
Further I'm trying to finish the L2 compiler. This would be a clearly visible performance improvment in all parts of JNode.
And I'm doing this in may sparse free time after work.
That's why I cannot say enough to just make your self dirty with the code, or come and have fun developping JNode if you like, whenever you are in the right mode for that.
And while doing so take care that all features be easy to use and fun to work with. JNode first should be as easily DEVELOPABLE as possible and then as usable and easy to work with as possible. We should never forget that we are the first users of JNode while creating it and what JNode will become is greatly depends on us and wil reflect ourselves in some way. Let's try to create a well articulted haromnious pure system where every feature shows that the developers were happy creating it because they regained a kind of freedome that was not available in the Java land for so many years. The Java programmer is not closed away from the hardware, from the compilers, from hacking on all parts of the system any more. Here is the chance again to understand every corner of your software, of your operating system. Say no to the empier of closedness, where you are deprived once and forever from the chance to know what is the software at your hand. And with JNode all this is available in the form of the distilled synthesis of the history of computing called Java.

DEVELOP YOUR FUTURE OPERATING SYSTEM TODAY!

Regards,
Levente

What we need is a fast and stabile implementation for Graphics2D...now my question is who want's to help? More or less everything is there but the finetuning and font engines are for ones that realy know what they are doing in graphics field... and that's not me ... So people if you want to have a GUI ever in JNode start help to finish this Graphics2D implementation...

This is not related with JNode. It has to deal with java. I dont know if it is a good or bad idea, but the right place for this is maybe in JCP or something.

JNode will provide all the APIs java needs and some tools that an OS user needs (that can not be implemented with java). There is no reason to fork java or to create a new or a different java!

Hi,

>Thus, we have a factory for each of these : charva, swing, (swt ?),
>(awt?), and maybe html.

Mmmh... Until now, *official* Java only supports AWT and Swing. Why add so many different architectures ?

OK, we can find bridges between AWT/Swing, Swing/SWT, AWT/SWT, and even SWT/Swing... but developping from "non-Java" architectures would be an error IMHO.

Furthermore, SWT (or the unmentionned yet valuable GTK+) use native methods that use the underlying OS APIs. In the case of JNode... what is the underlying OS ? So : Java -> native -> Java ? Wow !

> Perhaps we can use JSF (Java Server Faces) or XUL (that convert
> XML->GUI and is used by mozilla).

Using XUL and maybe Luxor (which relies on Swing until now) for designing a generic JNode GUI would be great. JSF is, of course, also to be seriously considered.

But we can not prevent a user to deploy his own "canonical" application based on AWT or Swing IMHO.

>That's why I proposed creating an UI factory.

+1

Cheers,

p.b.

I think it is not possible -- and a bad idea

The first problem is you can not simply create a factory but you would also need a whole set of interfaces (and having the components implementing them). But it would not be enough because the different toolkits use different ways to interact (hierarchy, events, ...) so you would need wrappers. Finally, the apps will be forced to use it.

Mozilla XUL is typical in this point of view, living in its own world. I don't think Java/JNode needs one more toolkit.

Instead, I suggest to focus only on Swing. And then to add support for other toolkits. The only problem is that Swing is not yet available in JNode.

Swing provides the structure to build what you want.

1) There is a lot of PLAF, including textual ones, 2D ones, 3D ones, ...

2) It is possible to implement the other toolkits with Swing. For example, LaOS implements AWT peers in Swing, SWTSwing implements SWT in Swing, there is XUL engines for Swing and I also have a partial implementation of LCDUI (midlets) in Swing, ... And other toolkits like Zaval or Thinlets use Graphics2D so they can run in Swing too.

Most of it is already part of JDistro. So I'm suggesting to keep only two UI in JNode: terminal and swing.

About Eclipse, the shortest way to bring it to JNode is to contribute to the SWTSwing project. SWTSwing is already able to run a lot of components/tests. http://chrriis.brainlex.com/projects/swtswing/

About Charva, it would be nice to have a pure ansi-terminal version (afaiu already there in JNode) and a Swing one. BTW, I don't think there is a lot of demand for Charva-like apps. Instead, why not to focus only on GUI and TUI ?

Guillaume