Dear visitor, welcome to Jabaco - Community. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.
Quoted
Any thougths about this?
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
Quoted
JFrame and JDialog are just Swing wrappers for the AWT Frame and Dialog.
Quoted
Currently im studying the sourcecode from OpenJDK to figure out the differences
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.
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.
[/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
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
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
Have you seen the little Lassie Project. it lists all superclasses for a given namespace#classname.
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.
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.
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.