[2759] in java-interest
Re: Questions about pre-beta peers/events/update()
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Thu Oct 12 19:46:45 1995
Date: Thu, 12 Oct 1995 14:46:35 -0700
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: pat@icon-stl.net
Cc: java-interest@java.Eng.Sun.COM
Hi Pat,
> Ok, so I'm confused about who causes components to be repainted and when.
> Let me make some statements and questions and perhaps someone can clarify.
>
> Assume I have a Frame with a Button inside of it...
>
> The paint() methods are called by the "AWT-Motif/whatever" thread, an internal
> thread owned by the Java interpreter...
Right.
> One obvious situation when components need to be repainted is when a
> window is exposed.
Right again.
> Window expose events seem to be one of the types of events that are
> sucked up by the peer components. I can't catch them in my component.
Right. After an expose, the component is repainted automatically,
then the paint method is called.
> (though this may change in the future... right?)
Maybe.
> Big question:
> Is the peer component responsible for scheduling the update() by the AWT
> thread? Who then calls the corresponding Java component's update()?
The AWT thread is the one that deals with all GUI event handling, including
repaints. It calls the peer after an expose event, the peer then calls
update().
> If not, how does the AWT thread know when to repaint() (where does it get
> an event) and how does it even know what components exist? Maybe I'm being
> naive about how much the toolkit/native stuff does.
At the bottom of the AWT thread is an event loop that reads X events from
the event queue and delivers them to the appropriate peer components.
> (more question-statements)
>
> Graphics contexts ultimately come from the toolkit associated with the
> component.
Right.
> The graphics contexts for the Frame and Button are, at a
> lower level, associated with different, real native windowing component.
Right.
> That's why drawing on my frame doesn't draw over my Button...
Right.
> It's the native windowing system that provides the clipping, etc. for this...
> (right?)
Right.
> What is paintAll() for? (It just calls validate() before painting
> causing a layout() ) D
Eventually we want to write a non-native (all Java) GUI toolkit that
implements all the components except windows and graphics contexts. This
would make it really easy to do a quick and dirty port of the AWT.
> Does my component call this when it changes it's size etc.?
No. It is there as an AWT implementation tool.
> It looks like paintComponents() is used to get components to paint
> themselves on your particular graphics context as opposed to the ones
> associated with their native objects? Does anything currently use this?
> (maybe a print function will?)
There is also a print() method. If you hand this print method a
special graphics context (say one that generates PostScript) you
could print a window to a PostScript file.
> As you can see, I'm confused... I wish there were source available for
> the prebeta JDK. ;)
We'll work on making it available.
Have fun,
Arthur van Hoff
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
