[jitsi-dev] (Certificate Verification) Dialogs outside the UI service


#1

Hello

The certificate verification service presents the user a dialog when a certificate is not trusted from the system. This dialog is created from within the service, not through the UI service. Shouldn't this be moved into the UIService?

I'm working on a similar task to show the user a common popup from within a service (currently the sip protocol, but it's later needed by other services and plugins as well). What's the right way to do this?

Caveat: The topic about the provisioning plugin. It is loaded before the UIService and needs the certificate verification service.

Yana? (?)

Regards,
Ingo


#2

Hi Ingo,

Hello

The certificate verification service presents the user a dialog when a certificate is not trusted from the system. This dialog is created from within the service, not through the UI service. Shouldn't this be moved into the UIService?

I think that if the certificate verification dialog could be used only with the certificate verification service, we don't need to bother about making it available through the UIService. Is it needed somewhere else?

I'm working on a similar task to show the user a common popup from within a service (currently the sip protocol, but it's later needed by other services and plugins as well). What's the right way to do this?

If it's a common warning or message dialog you could already use UIService.getPopupDialog(). If it's more specific you could put in its own bundle and obtain it through the bundle context. We could also make it available through the UIService and put it in the impl/gui package. However I think that it really depends on the context of the popup, what is it about? If it's very protocol specific I'm not sure we should put it in the common gui package.

Caveat: The topic about the provisioning plugin. It is loaded before the UIService and needs the certificate verification service.

Yana? (?)

Moving a part of the gui before the provisioning plugin is on my to do list and as soon as I have some time I'll do it (hopefully very soon).

Cheers,
Yana

···

On Mar 18, 2011, at 2:42 PM, Bauersachs Ingo wrote:

Regards,
Ingo


#3

I think that if the certificate verification dialog could be used only
with the certificate verification service, we don't need to bother about
making it available through the UIService.

What if someone wants to deploy a headless Jitsi? Isn't that the whole idea of the UIService?

Is it needed somewhere else?

Not yet. But a large part of the dialog will is reused to display the certificate for the MIKEY patch (not yet published).

Ingo


#4

It seems to me like a simple warning dialog, so the getPopupDialog() could
work in this situation, or is there something else?

Ideally I'd like to show the user three buttons: Yes/No/Show Details.

Would it be an option to extend PopupDialog with a method like:
public abstract int showConfirmPopupDialog(Object message, String title,
            String[] buttonLabels, int messageType);

where a buttonLabels element is the text to be shown on the buttons in order. The return value would be the selected button. Or driven to the extreme a complete clone of the TaskDialog API from Vista/Win 7: http://msdn.microsoft.com/en-us/library/bb756938.aspx

(I'd do the implementation myself if you like the idea.)

It is indeed an issue if we want to have a headless version, however in
this case we need to split them and put the gui as a plugin for example.
The issue with putting such guis in the main gui package, hence make them
available through the UIService is that if we want to disable a
functionality for some reason we won't be able to
simply remove its gui. On the other hand if it's in its own bundle then it
would be simple.

OK, sure. Then this falls into the topic of splitting the UIService into some "baseline" APIs for Popups etc. and the actual GUI (the Main Window, Plugin-Dialogs, etc.). I'll construct my implementation so that a subclass can easily overwrite the UI specific part and can still use the rest of the functionality.

Ingo

PS: Don't hurry with the UI split-up. My remark above is only to help me understand things better.


#5

На 18.03.11 16:02, Bauersachs Ingo написа:

I think that if the certificate verification dialog could be used only
with the certificate verification service, we don't need to bother about
making it available through the UIService.

What if someone wants to deploy a headless Jitsi? Isn't that the whole idea of the UIService?

Is it needed somewhere else?

Not yet. But a large part of the dialog will is reused to display the certificate for the MIKEY patch (not yet published).

Are you saying that you'd like to handle this in a place different than
the certificate verification service impl?

Emil


#6

I think that if the certificate verification dialog could be used only
with the certificate verification service, we don't need to bother about
making it available through the UIService.

What if someone wants to deploy a headless Jitsi? Isn't that the whole idea of the UIService?

Is it needed somewhere else?

Not yet. But a large part of the dialog will is reused to display the certificate for the MIKEY patch (not yet published).

Ingo

···

On Mar 18, 2011, at 4:02 PM, Bauersachs Ingo wrote:


#7

It seems to me like a simple warning dialog, so the getPopupDialog()
could work in this situation, or is there something else?

Ideally I'd like to show the user three buttons: Yes/No/Show Details.

Would it be an option to extend PopupDialog with a method like:
public abstract int showConfirmPopupDialog(Object message, String title,
            String[] buttonLabels, int messageType);
where a buttonLabels element is the text to be shown on the buttons in
order. The return value would be the selected button. Or driven to the
extreme a complete clone of the TaskDialog API from Vista/Win 7:
http://msdn.microsoft.com/en-us/library/bb756938.aspx

(I'd do the implementation myself if you like the idea.)

Meanwhile an additional checkbox whether to ask again is required. Apart from the "Show Details" button, MessageDialog would do the job. But MessageDialog is a UIServer internal class.

As for the TaskDialog, there is already a SWING-library that implements this functionality: http://code.google.com/p/oxbow/wiki/TaskDialogIntroduction

Could we add this Library?

Ingo


#8

Hi Ingo,

Sorry, accidentally pressed send last time.

(see inline)

I think that if the certificate verification dialog could be used only
with the certificate verification service, we don't need to bother about
making it available through the UIService.

What if someone wants to deploy a headless Jitsi? Isn't that the whole idea of the UIService?

I've already replied you off list, but just wanted to answer this one again here.

I agree that this could be a problem for a headless Jitsi. However the UIService was meant to provide access to some core ui components. We've tried to keep specific ui components in external plugins, which allows us to remove the user interface of a specific functionality easily when this functionality needs to be disabled for some reason. It's not always easy to decide which is a core functionality and which isn't and there's no exact rule about this :slight_smile: I just think that in this particular case if you need to have the gui separated from the service it would be better to put it in a separate plugin.

Cheers,
Yana

···

On Mar 18, 2011, at 7:18 PM, Yana Stamcheva wrote:

On Mar 18, 2011, at 4:02 PM, Bauersachs Ingo wrote:

Is it needed somewhere else?

Not yet. But a large part of the dialog will is reused to display the certificate for the MIKEY patch (not yet published).

Ingo


#9

Hi Ingo,

It seems to me like a simple warning dialog, so the getPopupDialog()
could work in this situation, or is there something else?

Ideally I'd like to show the user three buttons: Yes/No/Show Details.

Would it be an option to extend PopupDialog with a method like:
public abstract int showConfirmPopupDialog(Object message, String title,
           String[] buttonLabels, int messageType);
where a buttonLabels element is the text to be shown on the buttons in
order. The return value would be the selected button. Or driven to the
extreme a complete clone of the TaskDialog API from Vista/Win 7:
http://msdn.microsoft.com/en-us/library/bb756938.aspx

(I'd do the implementation myself if you like the idea.)

Meanwhile an additional checkbox whether to ask again is required. Apart from the "Show Details" button, MessageDialog would do the job. But MessageDialog is a UIServer internal class.

We could move it to the util.swing package and thus make it visible.

As for the TaskDialog, there is already a SWING-library that implements this functionality: http://code.google.com/p/oxbow/wiki/TaskDialogIntroduction

Could we add this Library?

I'm not sure if it's a good idea, because we use some basic custom components like the SIPCommDialog/Frame in order to have the same look & feel all over the application (like the blue background on windows and the escape key which closes windows).

I'm now working on the provisioning master password issue and will also have a look if it's easy to move the MessageDialog.

Cheers,
Yana

···

On Mar 21, 2011, at 2:49 PM, Bauersachs Ingo wrote:

Ingo


#10

Hey Yana

http://code.google.com/p/oxbow/wiki/TaskDialogIntroduction

I'm not sure if it's a good idea, because we use some basic custom
components like the SIPCommDialog/Frame in order to have the same look &
feel all over the application (like the blue background on windows and the
escape key which closes windows).

At first sight it seems to require Java 1.6 as well, so we'd need to do a port anyway. The SIPComm*-Controls could then be injected as well.

I'm now working on the provisioning master password issue and will also
have a look if it's easy to move the MessageDialog.

Thanks!
As a simpler but still generic solution, could we extend MessageDialog in a way to display an arbitrary number of buttons where each of them could have a custom text (instead of only the OK button)? A callback would be required to let the code that created the MessageDialog react to a button-click without closing the MessageDialog yet.

Ingo


#11

Hey Ingo,

Hey Yana

http://code.google.com/p/oxbow/wiki/TaskDialogIntroduction

I'm not sure if it's a good idea, because we use some basic custom
components like the SIPCommDialog/Frame in order to have the same look &
feel all over the application (like the blue background on windows and the
escape key which closes windows).

At first sight it seems to require Java 1.6 as well, so we'd need to do a port anyway. The SIPComm*-Controls could then be injected as well.

Yep, the 1.6 requirement would also be an issue. However I agree that they seem to have some very pretty dialogs, so we could think of some kind of integration in the future.

I'm now working on the provisioning master password issue and will also
have a look if it's easy to move the MessageDialog.

Thanks!
As a simpler but still generic solution, could we extend MessageDialog in a way to display an arbitrary number of buttons where each of them could have a custom text (instead of only the OK button)? A callback would be required to let the code that created the MessageDialog react to a button-click without closing the MessageDialog yet.

It's a good idea and could be very useful! If you could propose a patch in that direction I'll be happy to review and integrate it.

Cheers,
Yana

···

On Mar 21, 2011, at 4:03 PM, Bauersachs Ingo wrote:

Ingo


#12

As a simpler but still generic solution, could we extend MessageDialog
in a way to display an arbitrary number of buttons where each of them
could have a custom text (instead of only the OK button)? A callback would
be required to let the code that created the MessageDialog react to a
button-click without closing the MessageDialog yet.

It's a good idea and could be very useful! If you could propose a patch in
that direction I'll be happy to review and integrate it.

I'll start this evening. Is it okay if I move the dialog into the package util.swing?

Ingo

PS: Could I contact you using an IM address (where?) if I have further questions?


#13

As a simpler but still generic solution, could we extend MessageDialog
in a way to display an arbitrary number of buttons where each of them
could have a custom text (instead of only the OK button)? A callback would
be required to let the code that created the MessageDialog react to a
button-click without closing the MessageDialog yet.

It's a good idea and could be very useful! If you could propose a patch in
that direction I'll be happy to review and integrate it.

I'll start this evening. Is it okay if I move the dialog into the package util.swing?

Yes, it's perfect.

Ingo

PS: Could I contact you using an IM address (where?) if I have further questions?

You could use yana@sip-communicator.org as Jabber IM contact.

Cheers,
Yana

···

On Mar 21, 2011, at 5:30 PM, Bauersachs Ingo wrote: