Hi Costantino,
On 01/26/2010 01:17 AM, Costantino Cerbo wrote:
Then I've reformatted the code and renamed the method
native_gtk_check_version(...) to gtkCheckVersionImpl(...).
As result you receive a new patch (b6913179-3.patch) ;-)
Thanks. I'll generate a new webrev after you and Peter finish reviewing.
On 01/26/2010 11:19 AM, Costantino Cerbo wrote:
> 2. src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java
>>
>> 86 fd.setVisible(false);
>> 89 fd.setVisible(false);
>
> I'm not really sure if you need these calls. Also, I think that the second
> one could cause an endless loop if it weren't guarded on the shared level in
> Component.show(boolean). I think calling run() or quit() should be enough
> for it to function correctly.
In my previous email I forgot to say, that I add the call to
"fd.setVisible(..)" because without that the component isn't disposed
and also if we close the main Frame a thread remains alive.
I see.
What concerns me is that file dialogs are modal. And if you invoke its
setVisble(true) on the EDT, the event dispatching is going to be locked.
Try moving the file dialog over the main frame containing some Swing
GUI. I think it's not going to be updated properly, while the
XFileDialogPeer should work OK.
Since GTK file dialog is not a usual Java window, the situation is very
similar to what we have on Windows. Please take a look at
src/windows/classes/sun/awt/windows/WFileDialogPeer.java . You may
notice that the peer re-dispatches the show() request to a new thread -
this is OK because the modality sub-system on the shared level will
handle blocking correctly. Also please note that in order to support
blocking Java windows by an external window, the peer inherits from
WWindowPeer and implements the DialogPeer, notably its blockWindows()
method, itself. It looks like we have to use a similar approach in
XToolkit for the GTKFileDialog...
--
best regards,
Anthony
