applet's call comportement

E

Emmanuel Freund

Hi, I'm currently developping a web browser in java and I'd like to have the
windows openned by some applets to be displayed in my own workspace and not
the OS's one. If anybody have an idea, some clue, whatever, it would be of
great help.
 
P

Paul Lutus

Emmanuel said:
Hi, I'm currently developping a web browser in java and I'd like to have
the windows openned by some applets to be displayed in my own workspace

Define "workspace". Leave nothing to the imagination.
 
E

Emmanuel Freund

I've developped my own classes of JFrame, Frame and Window (as some children
of the generics classes, say myFrame, myWindow and myJFrame for example),
and i would like that an applet making a call to JFrame is reorienting
towards myFrame instead.
 
J

John C. Bollinger

Emmanuel said:
I've developped my own classes of JFrame, Frame and Window (as some children
of the generics classes, say myFrame, myWindow and myJFrame for example),
and i would like that an applet making a call to JFrame is reorienting
towards myFrame instead.

You want random applets to automatically use your custom subclasses of
certain AWT / Swing classes instead of using the superclasses that they
actually specify? I don't think you can do this even with ClassLoader
magic or by modifying the platform library. The classes you want the
applets to use themselves depend on the classes that the applets
actually specify, so you have no way to make the former impersonate the
latter. I find the whole idea rather odd, anyway. What is the
objective you wanted to accomplish by this approach?


John Bollinger
(e-mail address removed)
 
E

Emmanuel Freund

You want random applets to automatically use your custom subclasses of
certain AWT / Swing classes instead of using the superclasses that they
actually specify?

yes, more or less

I don't think you can do this even with ClassLoader
magic or by modifying the platform library. The classes you want the
applets to use themselves depend on the classes that the applets
actually specify, so you have no way to make the former impersonate the
latter.

well, i think there's to be somewhere an address where the applet find the
classe frame for example. So if we do a child myFrame of frame, and we
change the address of frame by the address of myFrame, the applet will use
the function of myFrame instead the ones of frame i suppose. I mean, this
could be one possibility, but since i don't know where to find this
address... I don't want to change the platform library, just add some
classes on it.
I find the whole idea rather odd, anyway. What is the
objective you wanted to accomplish by this approach?

To simplify, say that we have developped a full screen browser in java,
where new windows are oppened in some panels, and we can navigate through
those panels by clicking some buttons. The problem is when we open a page
with an applet making a call to Window or one of its child (generally
JFrame), the whole idea of this browser is lost cause the applet will open
an OS-depedent window...

I hope you see what i mean. If you have any idea, it would really help.
 
J

John C. Bollinger

Emmanuel said:
yes, more or less





well, i think there's to be somewhere an address where the applet find the
classe frame for example. So if we do a child myFrame of frame, and we
change the address of frame by the address of myFrame, the applet will use
the function of myFrame instead the ones of frame i suppose. I mean, this
could be one possibility, but since i don't know where to find this
address... I don't want to change the platform library, just add some
classes on it.

You *need* to become intimately familiar with Java class loading and
ClassLoaders, the mechanism by which Java's dynamic linking behavior
operates. You would benefit from studying the details of the class file
format. I think that you will find that you cannot do what you describe
without an enormous amount of work, and that you may not be able to do
it at all. Specifically:

You _could_ define a custom ClassLoader for your application that would
load a class of your choice instead of the platform library's
javax.swing.JFrame (for instance). However, if that class' FQ name is
anything other than javax.swing.JFrame then the VM will throw an Error.
If that class' name _is_ javax.swing.JFrame then it must be a complete
reimplementation of JFrame (i.e. it cannot extend the system's JFrame
because there is a name collision). You cannot use Sun's code for this
without violating your Java license, but you must be certain to be 100%
accurate in fulfilling the published JFrame contract or some applets
will break. (In fact, any applet that depends on serializing /
deserializing a JFrame is likely to break no matter what you do.) In
addition, if you did do this then you would then be locked into
_maintaining_ your versions of these classes.
To simplify, say that we have developped a full screen browser in java,
where new windows are oppened in some panels, and we can navigate through
those panels by clicking some buttons. The problem is when we open a page
with an applet making a call to Window or one of its child (generally
JFrame), the whole idea of this browser is lost cause the applet will open
an OS-depedent window...

I hope you see what i mean. If you have any idea, it would really help.

I am not a GUI expert, but my inclination is to say that you're going
about this in the wrong way. It seems to me that a better way to
accomplish your aim might be for your application to use a custom AWT
Toolkit instead of trying to modify or substitute System classes. The
details of how that would work (including how you would specify the
appropriate Toolkit class to the system) are beyond what I'm prepared to
research at this time. The AWT and Swing classes are designed to be
customizable for a wide range of environments; it would be better to
make use of that to modify their behavior, rather than to try to replace
them.


John Bollinger
(e-mail address removed)
 
E

Emmanuel Freund

You *need* to become intimately familiar with Java class loading and
ClassLoaders, the mechanism by which Java's dynamic linking behavior
operates. You would benefit from studying the details of the class file
format. I think that you will find that you cannot do what you describe
without an enormous amount of work, and that you may not be able to do
it at all. Specifically:

You _could_ define a custom ClassLoader for your application that would
load a class of your choice instead of the platform library's
javax.swing.JFrame (for instance). However, if that class' FQ name is
anything other than javax.swing.JFrame then the VM will throw an Error.
If that class' name _is_ javax.swing.JFrame then it must be a complete
reimplementation of JFrame (i.e. it cannot extend the system's JFrame
because there is a name collision). You cannot use Sun's code for this
without violating your Java license, but you must be certain to be 100%
accurate in fulfilling the published JFrame contract or some applets
will break. (In fact, any applet that depends on serializing /
deserializing a JFrame is likely to break no matter what you do.) In
addition, if you did do this then you would then be locked into
_maintaining_ your versions of these classes.

This class loader thing is interesting, i will work on it.
I am not a GUI expert, but my inclination is to say that you're going
about this in the wrong way. It seems to me that a better way to
accomplish your aim might be for your application to use a custom AWT
Toolkit instead of trying to modify or substitute System classes. The
details of how that would work (including how you would specify the
appropriate Toolkit class to the system) are beyond what I'm prepared to
research at this time. The AWT and Swing classes are designed to be
customizable for a wide range of environments; it would be better to
make use of that to modify their behavior, rather than to try to replace
them.

Well, the AWT toolkit's environnement don't match the things i want to
render. But i aggree it would be simpler in this way.
I'm just wondering, when an applet call the JFrame class for example, there
has to be somewhere the path where the applet could find this class, so if
we change the path toward my own class, the applet will call my own class
instead, no? even if my own class is a child of JFrame? unless i've really
none understand, which is a possibility...

Thanks for all anyway, a lot.
 
E

Emmanuel Freund

Well, the AWT toolkit's environnement don't match the things i want to
What 'things' are you referring to? Fonts (faces and sizes)
spacig or padding, borders etc. can all be controlled for
Swing components by setting a suitable Look and Feel.

let's say: frames have to be in 1280*1024, there must be no resize button,
the close button is a big button in the right-down corner, some things like
that... it's easy to make a child of jframe with those function, but i don't
see how to use Look and Feel to render those things... is it possible?

No. Java will always check the core API for classes before
it looks in other places. It is easy to replace classes outside
the core classes in the way you describe, but not the core classes
themselves.

Note also that (AFAIU), changing the classloader will not help
here, since custom classloaders first cede to the parent classloader>
If the parent classloader finds the class, the custom loader
simply passes that class back to the caller.
k, thanks. So maybe make my own implementation of toolkit and use the
createFrame() function? would it work?
 
E

Emmanuel Freund

John C. Bollinger said:
The AWT toolkit is the base on which everything else is built. It
necessarily matches what you want to render, or you won't render it with
AWT / Swing. Now, you may not _see_ how things in the Toolkit match up;
if you want a Toolkit-based approach to work you will need to learn how
the classes you are interested in (JFrame, and perhaps others) use the
Toolkit, directly or indirectly. For help with this kind of task you
might want to go next door to comp.lang.java.gui.

thanks, i now see better how this is working... i'm going seek some info on
toolkit on comp.lang.java.gui. So if i make my own implementation of
toolkit, a foreign applet will use my own implementation of toolkit? even if
it specifies some Look and Feel options? is that possible?
To be more precise, the frames in my browser are 1280*1024, don't will be
resized, and the close button is a big button on the right-down corner of
the frame, so i would like that when an applet opened by my browser call a
frame, it use those frame.



As I wrote before, you would do this by bringing a custom ClassLoader
into the picture. ClassLoaders are *the* means by which Java VMs find
classes after bootstrap. It might be appropriate to use an
applet-specific ClassLoader anyway, to isolate external applets' classes
from your application's own. Trying to use one to substitute your own
version of a class for the System's version raises all the problems I
described to you before. In particular, here is a schematic example of
why you cannot use a ClassLoader to substitute a class for one of its
ancestors:

1) applet com.sombodyelse.MyApplet wants to open a JFrame, so it asks
its ClassLoader to load javax.swing.JFrame for it.

2) A custom ClassLoader intercepts the request, and instead of passing
it first to its parent ClassLoader (as a "normal" ClassLoader would do)
it finds and starts to load a class file for a class named
com.mycompany.myapplication.MyFrame to satisfy the request.

3) MyJFrame needs its superclass, javax.swing.JFrame, so it asks its
ClassLoader to load that class for it.

4) Go to (2), or throw a ClassCircularityError.

i see. So classloader is not my miracle solution ;)
 
A

Andrew Thompson

let's say: frames have to be in 1280*1024, there must be no resize button,
the close button is a big button in the right-down corner, some things like
that... it's easy to make a child of jframe with those function, but i don't
see how to use Look and Feel to render those things... is it possible?

Not without a custom VM.

The issue here is you wanting to change *existing* frames.
That would allow you to change the look of frames produced by
(for example) my software.

But what makes you think I want *my* software 1280*1024, with
the 'big button' on the right (and possibly your company's
moniker all over them) for *my* project..
...
k, thanks. So maybe make my own implementation of toolkit and use the
createFrame() function?

Only if you can get users to install the 'version' of the VM that
you have hacked into, but I suspect that would violate Sun's
distribution agreement for the VM.

So, again, not that I know of.

You do not seem to display any understanding of why Sun might
resist attempts to change the look of the frames at the level
(and in the way) you want, do you?

BTW - if you want to get the GUI gurus into this one, you have
the wrong group. You might better redirect your question to..
<http://www.physci.org/codes/javafaq.jsp#cljg>
 
E

Emmanuel Freund

Well, the AWT toolkit's environnement don't match the things i want to
Not without a custom VM.

The issue here is you wanting to change *existing* frames.
That would allow you to change the look of frames produced by
(for example) my software.

But what makes you think I want *my* software 1280*1024, with
the 'big button' on the right (and possibly your company's
moniker all over them) for *my* project..

I see what u mean, and i now understand why it would violate sun licence.
In fact, that wasn't for painting my company's logo, but to simplify the
uses of the browser by forbiddin the openning of multiples windows... which
i can do for normal internet frame but not for applet without forbidding the
applet itself.
Well, i would find an other way, or an other company ;)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top