UIWindow#setBlockOnOpen(boolean shouldBlock) && MessageDialog
Angelo zerr
I have used your work with UIDialog into TK-UI to manage
* window.alert("bla bla bla")
* window.confirm("bla bla bla")
and it works well except than UIDialog#open() doesn't manage block
like JFace Window :
/**
* <code>true</code> if the <code>open</code> method should not return
* until the window closes, and <code>false</code> if the
* <code>open</code> method should return immediately; initially
* <code>false</code> (non-blocking).
*
* @see #setBlockOnOpen
*/
private boolean block = false;
So have you intention to manage UIDialog#setBlockOnOpen(boolean
shouldBlock) like JFace Window?
I think we should have better UIWindow#setBlockOnOpen(boolean shouldBlock)?
What do you think about that?
I think it shoud be cool to have too MessageDialog to manage message
dialog (Error, Question, Information, Warning Enum)
like JFace MessageDialog.
We could create MessageDialog into *.core.ui like this :
public static boolean MessageDialog#openConfirm(UIWindow parent,
String title, String message)
What do you think?
At end when you think UIDialod is stable I could develop Swing
implementation if you want.
Regards Angelo
Tom
> Hi Tom,
>
> I have used your work with UIDialog into TK-UI to manage
> * window.alert("bla bla bla")
> * window.confirm("bla bla bla")
>
> and it works well except than UIDialog#open() doesn't manage block
> like JFace Window :
>
> /**
> * <code>true</code> if the <code>open</code> method should not return
> * until the window closes, and <code>false</code> if the
> * <code>open</code> method should return immediately; initially
> * <code>false</code> (non-blocking).
> *
> * @see #setBlockOnOpen
> */
> private boolean block = false;
>
> So have you intention to manage UIDialog#setBlockOnOpen(boolean
> shouldBlock) like JFace Window?
>
> I think we should have better UIWindow#setBlockOnOpen(boolean shouldBlock)?
>
> What do you think about that?
Thread is present
where you can spin the event-loop and this is not available in
Browsers. This is something
you'll maybe also notice in future SWT-Versions. The only possibility
is to work with call-backs.
So sorry but we won't have such an API any time soon :-(
>
> I think it shoud be cool to have too MessageDialog to manage message
> dialog (Error, Question, Information, Warning Enum)
> like JFace MessageDialog.
>
> We could create MessageDialog into *.core.ui like this :
>
> public static boolean MessageDialog#openConfirm(UIWindow parent,
> String title, String message)
>
> What do you think?
widget composed from
already existing ones (UIDialog, UIComposite).
>
> At end when you think UIDialod is stable I could develop Swing
> implementation if you want.
>
can't provide a blocking version
because such a thing is not available on GWT because current browsers
don't provide such a feature
(FF 3.1 is an exception which will provide WebWorkers). So if you are
comfortable too I think you could
start the Swing implementation.
Tom
Angelo zerr
Sorry this won't work because a blocking dialog assumes a Display-
Thread is present
where you can spin the event-loop and this is not available in
Browsers. This is something
you'll maybe also notice in future SWT-Versions. The only possibility
is to work with call-backs.
So sorry but we won't have such an API any time soon :-(
No problem Tom. But is not possible to supporrt it for Swing and SWT and not for GWT?
Into the open methos of UIDialog JFace implementation, we can access to SWT Display?
If it's possible why cannot we manage the block?
Yes. MessageDialog is a thing I have on my list but this simply is an
>
> I think it shoud be cool to have too MessageDialog to manage message
> dialog (Error, Question, Information, Warning Enum)
> like JFace MessageDialog.
>
> We could create MessageDialog into *.core.ui like this :
>
> public static boolean MessageDialog#openConfirm(UIWindow parent,
> String title, String message)
>
> What do you think?
widget composed from
already existing ones (UIDialog, UIComposite).
Cool. Could you tell me when you will do this work please. I will do use
MessageDialog into my window.alert().
I'm comfortable with the API we currently have. Like outlined above we
>
> At end when you think UIDialod is stable I could develop Swing
> implementation if you want.
>
can't provide a blocking version
because such a thing is not available on GWT because current browsers
don't provide such a feature
(FF 3.1 is an exception which will provide WebWorkers). So if you are
comfortable too I think you could
start the Swing implementation.
Ok Tom. I must finsih my work about JXPath with EMF (I'm workinng with Olivier Moise for that)
and after I will work perhaps about DBEL to manage XPath into declarative binding.
I will see how you have done with JFace and I will try do that the same thing for Swing.
Angelo
Tom
Tom Schindl
> Hi Tom,
>
>
> Sorry this won't work because a blocking dialog assumes a Display-
> Thread is present
> where you can spin the event-loop and this is not available in
> Browsers. This is something
> you'll maybe also notice in future SWT-Versions. The only possibility
> is to work with call-backs.
> So sorry but we won't have such an API any time soon :-(
>
>
> No problem Tom. But is not possible to supporrt it for Swing and SWT
> and not for GWT?
> Into the open methos of UIDialog JFace implementation, we can access
> to SWT Display?
> If it's possible why cannot we manage the block?
Well not at the core lib level I guess the only possibility because
things should behave the same across implementations.
The question is whether we could:
a) Provide none-mandatory interfaces toolkits may or may not implement
So we would create an interface named UIBlockingDialog in a special
package, the same could be done for your
proposed UIWidget#find(String xpath)
b) You do this your own now and simply wrap the opening of the Dialog in
a method call which spins the event-loop
I'm going to think about the none-manadatory interfaces a bit.
>
>
> >
> > I think it shoud be cool to have too MessageDialog to manage message
> > dialog (Error, Question, Information, Warning Enum)
> > like JFace MessageDialog.
> >
> > We could create MessageDialog into *.core.ui like this :
> >
> > public static boolean MessageDialog#openConfirm(UIWindow parent,
> > String title, String message)
> >
> > What do you think?
>
> Yes. MessageDialog is a thing I have on my list but this simply is an
> widget composed from
> already existing ones (UIDialog, UIComposite).
>
>
> Cool. Could you tell me when you will do this work please. I will do use
> MessageDialog into my window.alert().
ASAP
>
>
> >
> > At end when you think UIDialod is stable I could develop Swing
> > implementation if you want.
> >
>
> I'm comfortable with the API we currently have. Like outlined above we
> can't provide a blocking version
> because such a thing is not available on GWT because current browsers
> don't provide such a feature
> (FF 3.1 is an exception which will provide WebWorkers). So if you are
> comfortable too I think you could
> start the Swing implementation.
>
>
> Ok Tom. I must finsih my work about JXPath with EMF (I'm workinng with
> Olivier Moise for that)
> and after I will work perhaps about DBEL to manage XPath into
> declarative binding.
>
Great.
> I will see how you have done with JFace and I will try do that the
> same thing for Swing.
>
Cool - I'll think about the none-mandatory idea and keep you updated.
Tom
Tom
makes sense to have this blocking dialog possibility.
Is there really a need for such a thing?
For MessageDialogs this might make sense but for every other dialog it
is senseless. Angelo do you think you can emulate blocking yor own
at the TK-UI-Level.
Tom
Tom Schindl
public int openBlocking() {
open(new UIRunnable<UIDialog>() {
@Override
protected IStatus run(UIDialog element) {
return Status.OK_STATUS;
}
});
Display d = getShell().getDisplay();
while( returnCode == 0 ) {
if( ! d.readAndDispatch() ) {
d.sleep();
}
}
return returnCode;
}
Tom schrieb:
Angelo zerr
Well I added the none-mandatory interface but I'm not sure it really
makes sense to have this blocking dialog possibility.
Is there really a need for such a thing?
For MessageDialogs this might make sense but for every other dialog it
is senseless. Angelo do you think you can emulate blocking yor own
at the TK-UI-Level.
Thank a lot for your work.
I would like avoid to manage block by using test like this
UIDialog dialog = ...
if (dialog instanceof JFaceDialog) {
((JFaceDialog)dialog).openBlocking();
}
As you said, this openblocking is interesting for MessageDialogs.
have you intention to manag ethat? if yes, openBlocking is usefull. No?
Perhaps could we have UIDialog2 interface with openBlocking method?
JFace, Swing implement UIDialog2 and GWT doesn't implement it.
After we could do
UIDialog dialog = ...
if (dialog instanceof UIDialog2) {
((UIDialog2)dialog).openBlocking();
}
What do you think?
Angelo
Tom Schindl
> Hi Tom,
>
>
>
> Well I added the none-mandatory interface but I'm not sure it really
> makes sense to have this blocking dialog possibility.
> Is there really a need for such a thing?
>
> For MessageDialogs this might make sense but for every other dialog it
> is senseless. Angelo do you think you can emulate blocking yor own
> at the TK-UI-Level.
>
>
> Thank a lot for your work.
>
> I would like avoid to manage block by using test like this
>
> UIDialog dialog = ...
> if (dialog instanceof JFaceDialog) {
> ((JFaceDialog)dialog).openBlocking();
> }
>
> As you said, this openblocking is interesting for MessageDialogs.
> have you intention to manag ethat? if yes, openBlocking is usefull. No?
>
> Perhaps could we have UIDialog2 interface with openBlocking method?
> JFace, Swing implement UIDialog2 and GWT doesn't implement it.
> After we could do
>
> UIDialog dialog = ...
> if (dialog instanceof UIDialog2) {
> ((UIDialog2)dialog).openBlocking();
> }
>
> What do you think?
>
SVN-History) with a none-mandatory interface named UIBlockingDialog but
you could easily manage all this in your TK-UI-Code. I'm currently a
little bit undifferent but I think you could easily block in your
TK-UI-Application code. I'm not even sure how this would be implemented
in Swing because there's no event-loop you can spin but need to create
an artificial one. May question is could you wrap calls to UIDialog.open
in your application code and do what JFaceDialog#openBlocking() does?
Tom