JFrame vs JDialog.

Beginner

Friday, October 9th 2009, 12:10pm

I am immensly annoyed with the JFrame vs JDialog problem. JFrame for example lack modality and JDialog lack WindowState. I was annoyed with this when developing Java apps and am still annoyed when i see that this is a problem in Jabaco to.

Currently im studying the sourcecode from OpenJDK to figure out the differences. JFrame and JDialog are just Swing wrappers for the AWT Frame and Dialog. Both of them inherits a Window class, but still have a lot of individual code.

I looked in Dialog.java and so far it seams that the most attractive future (modality) is based on a lot of code. My idea currently is to make a JForm class that extends either JFrame or JDialog and uses code from the other in order to get a uniform Form class. So far JDialog seam to be the best candidate because of the comples modality code, but i have to check out JForm to in order to make a final choise.

Any thougths about this?

Go to the top of the page

OlimilO

Intermediate

Posts: 277

Location: Germany

Occupation: software engineer

2

Friday, October 9th 2009, 3:47pm

Hi Faldegast,

Quoted

Any thougths about this?

hmm..

Quoted

I am immensly annoyed with the JFrame vs JDialog problem. JFrame for example lack modality and JDialog lack WindowState. I was annoyed with this when developing Java apps and am still annoyed when i see that this is a problem in Jabaco to

immense problems ... could you please explain a little more?

Quoted

JFrame and JDialog are just Swing wrappers for the AWT Frame and Dialog.

Would you call it a wrapper? ähm in fact it is a subclass. Have you seen the little Lassie Project. it lists all superclasses for a given namespace#classname.

Quoted

Currently im studying the sourcecode from OpenJDK to figure out the differences

Cool, I thought that the reason is in differencies of the operating systems (platform independency). I am courious if you find another reason.

Quoted

My idea currently is to make a JForm class that extends either JFrame or JDialog and uses code from the other in order to get a uniform Form class.

sounds interesting. You mean to be able to switch between them? Could you please make a sketch, (in Code) how this could be implemented? My idea would be to heavily involve the compiler. Maybe we need something like generics (the C++-preprocessor kinds)?

Ah you mean we should use JDialog as the superclass of VB#Form, in general instead of JFrame.
OlimilO

Go to the top of the page

Faldegast

Beginner

Posts: 27

3

Friday, October 9th 2009, 5:14pm

Quoted from "OlimilO"

Hi Faldegast,

Quoted

Any thougths about this?

hmm..

Quoted

I am immensly annoyed with the JFrame vs JDialog problem. JFrame for example lack modality and JDialog lack WindowState. I was annoyed with this when developing Java apps and am still annoyed when i see that this is a problem in Jabaco to

immense problems ... could you please explain a little more?

Simply the fact that window functionality is split between two classes and I have to chose between two sets of functionality.

Quoted from "OlimilO"

Quoted

JFrame and JDialog are just Swing wrappers for the AWT Frame and Dialog.

Would you call it a wrapper? ähm in fact it is a subclass. Have you seen the little Lassie Project. it lists all superclasses for a given namespace#classname.
[/quote}
I call it wrapper because the purpuse of these classes is to add Frame and Dialog into the Swing framework, and they do not provide much extra functionality. They add to their base classes but does not change their behavour, exept for some minor changes like providing other constructors.

Quoted from "OlimilO"

Quoted

Currently im studying the sourcecode from OpenJDK to figure out the differences

Cool, I thought that the reason is in differencies of the operating systems (platform independency). I am courious if you find another reason.

As far as i can tell the reason is as for so many things in Java to enforce some design patterns. There are no platform dependent code in these classes, such code seam to be located in sun.awt.SunToolkit.

Quoted from "OlimilO"

Quoted

My idea currently is to make a JForm class that extends either JFrame or JDialog and uses code from the other in order to get a uniform Form class.

sounds interesting. You mean to be able to switch between them? Could you please make a sketch, (in Code) how this could be implemented? My idea would be to heavily involve the compiler. Maybe we need something like generics (the C++-preprocessor kinds)?

Ah you mean we should use JDialog as the superclass of VB#Form, in general instead of JFrame.
OlimilO

I dont really know yet. I have to study the existing java classes more first. Currently my idea is to make a JForm in Java that is a merged JFrame and JDialog, having one of them as superclass. VB/Form could then be redesigned to use JForm as its superclass. Thus my work will be useful when making both Java and VB programs.

Go to the top of the page

OlimilO

Intermediate

Posts: 277

Location: Germany

Occupation: software engineer

4

Friday, October 9th 2009, 6:54pm

OK, em, the more i read about principles of JFrame and JDialog, the differencies maybe have nothing to do with platform independency.
But another thought: there were some people asking for Jabaco on mobile devices. It would be nice to be able to "switch" Jabaco to a mobile-Framework.

regards

OlimilO

Go to the top of the page

theuserbl

Intermediate

Posts: 224

5

Friday, October 9th 2009, 7:56pm

Quoted from "OlimilO"

Have you seen the little Lassie Project. it lists all superclasses for a given namespace#classname.

Cool!

Haven' it downloaded yet, because I am currently in an Internetcafé, where it is impossible to download something.
But I have seen the screenshot. Nice.

Is the Sourcecode included? (I ask, because I can´t download it now).
And if yes: Under what license stand it?

Go to the top of the page

theuserbl

Intermediate

Posts: 224

6

Friday, October 9th 2009, 10:20pm

I have now downloaded Lassie and tested it.
It comes only as source code (without binary)

And the program works nice.

But a license doesn't stand in there. It is Public Domain?

Go to the top of the page

OlimilO

Intermediate

Posts: 277

Location: Germany

Occupation: software engineer

7

Saturday, October 10th 2009, 10:52am

Quoted

It is Public Domain?

it is just a sample project where you can see some features of Jabaco.

OlimilO

Go to the top of the page

Faldegast

Beginner

Posts: 27

8

Tuesday, May 4th 2010, 10:51pm

Quoted from "OlimilO"

OK, em, the more i read about principles of JFrame and JDialog, the differencies maybe have nothing to do with platform independency.
But another thought: there were some people asking for Jabaco on mobile devices. It would be nice to be able to "switch" Jabaco to a mobile-Framework.

Jabaco on a mobile framework would be extra difficult. Those does not make any use of Swing but have their own GUI libraries. Android however may be different.

I think using Jabaco on mobile other frameworks then Swing/Java SE requires us to rethink the design of Jabaco Frameworks. We would need parallell implementations of Forms and probably almost everything else. A factory-based implementation should be considered, where classes like "Form" are either abstract classes or interfaces. A set of platform-depended factories could then be used to instantiate the right classes. Take a look on how Swing is skinned for some ideas.

This way we could support a Web toolkit like Vaadin. It seams really simple to write Vaadin GUI:s and it should map neatly to Form-paradigm. There are no really good GUI for designing Java Web applications, so if Jabaco offers that we could position ourselves in this market.

Go to the top of the page

Menkaura

Beginner

Posts: 8

9

Wednesday, August 4th 2010, 1:14pm

Quoted from "Faldegast"

Quoted from "OlimilO"

OK, em, the more i read about principles of JFrame and JDialog, the differencies maybe have nothing to do with platform independency.
But another thought: there were some people asking for Jabaco on mobile devices. It would be nice to be able to "switch" Jabaco to a mobile-Framework.

Jabaco on a mobile framework would be extra difficult. Those does not make any use of Swing but have their own GUI libraries. Android however may be different.

I think using Jabaco on mobile other frameworks then Swing/Java SE requires us to rethink the design of Jabaco Frameworks. We would need parallell implementations of Forms and probably almost everything else. A factory-based implementation should be considered, where classes like "Form" are either abstract classes or interfaces. A set of platform-depended factories could then be used to instantiate the right classes. Take a look on how Swing is skinned for some ideas.

This way we could support a Web toolkit like ='http://vaadin.com/demo']Vaadin. It seams really simple to write Vaadin GUI:s and it should map neatly to Form-paradigm. There are no really good GUI for designing Java Web applications, so if Jabaco offers that we could position ourselves in this market.

jacabo on Mobile devices maybe JavaFX using the output of jacabo java file such work

Go to the top of the page

Menkaura

Beginner

Posts: 8

10

Wednesday, August 4th 2010, 5:07pm

Jacabo mobile and web

Quoted from "Faldegast"

Quoted from "OlimilO"

OK, em, the more i read about principles of JFrame and JDialog, the differencies maybe have nothing to do with platform independency.
But another thought: there were some people asking for Jabaco on mobile devices. It would be nice to be able to "switch" Jabaco to a mobile-Framework.

Jabaco on a mobile framework would be extra difficult. Those does not make any use of Swing but have their own GUI libraries. Android however may be different.

I think using Jabaco on mobile other frameworks then Swing/Java SE requires us to rethink the design of Jabaco Frameworks. We would need parallell implementations of Forms and probably almost everything else. A factory-based implementation should be considered, where classes like "Form" are either abstract classes or interfaces. A set of platform-depended factories could then be used to instantiate the right classes. Take a look on how Swing is skinned for some ideas.

This way we could support a Web toolkit like ='http://vaadin.com/demo']Vaadin. It seams really simple to write Vaadin GUI:s and it should map neatly to Form-paradigm. There are no really good GUI for designing Java Web applications, so if Jabaco offers that we could position ourselves in this market.