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.
Friday, October 9th 2009, 3:47pm
Hi Faldegast,
hmm..
immense problems ... could you please explain a little more?
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.
Cool, I thought that the reason is in differencies of the operating systems (platform independency). I am courious if you find another reason.
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
Quoted
Any thougths about this?
hmm..
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?
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.
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.
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
Friday, October 9th 2009, 5:14pm
Hi Faldegast,
Any thougths about this?
hmm..
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.
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.
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.
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.
Friday, October 9th 2009, 7:56pm
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?
Tuesday, May 4th 2010, 10:51pm
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.
Wednesday, August 4th 2010, 1:14pm
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
Wednesday, August 4th 2010, 5:07pm
Jacabo mobile and web
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 should work
Similar threads
-
Tips, Tricks, Samples & Tutorials »-
Modal Dialog
(Feb 7th 2009, 12:55am)
-
- General topics, questions and discussions »
-
A little JabacoJava
(Jul 24th 2009, 9:13pm)
-
- General topics, questions and discussions »
-
Modal Window
(Mar 25th 2009, 10:31pm)
-
- Allgemeine Themen, Fragen und Diskussionen »
-
Allgemeine Fragen zu Forms (Open und Close)
(Nov 25th 2008, 11:07am)