[rfc][icedtea-web] Security dialogs wait for PolicyEditor to finish parsing

Jiri Vanek jvanek at redhat.com
Mon Mar 24 16:01:39 UTC 2014

On 03/24/2014 04:46 PM, Andrew Azores wrote:
> On 03/24/2014 11:11 AM, Jiri Vanek wrote:
>> On 03/24/2014 03:44 PM, Andrew Azores wrote:
>>> On 03/24/2014 10:40 AM, Jiri Vanek wrote:
>>>> On 03/24/2014 03:01 PM, Andrew Azores wrote:
>>>>> Hi,
>>>>> PolicyEditor loads and saves policy files async, obviously. However, this means that opening a new
>>>>> PolicyEditor instance on an existing policy file and programmatically adding a new codebase to the
>>>>> editor does not have a well-defined order. This can be problematic because PolicyEditor
>>>>> highlights/selects the last added codebase, so eg in the scenario where the editor is being
>>>>> launched
>>>>> from a security dialog, we want to be sure that the current applet's codebase is the one selected
>>>>> when the editor appears. This patch adds a method to PolicyEditor that indicates whether the
>>>>> editor
>>>>> is currently reading/writing a file, and adds a loop to the two security dialogs so that the new
>>>>> codebase is not added and the editor made visible until it completes its IO.
>>>>> Thanks,
>>>> Hm... I dont think this is correct approach. Why are you so strongly against modal dialogue?
>>>> J.
>>> I'm not... making PolicyEditor modal will come later. This patch is just about making sure that when
>>> you launch PolicyEditor from a security dialog, the current applet's codebase is guaranteed to be
>>> the selected one when the editor appears. This and modality are completely separate.
>>> Thanks,
>> uff... wouldnt be much more easy to make the load/save in sync?  I do not see any reason why it is
>> in new thread Thread(save/load).start() ....
>> J.
> I really don't want to be doing it sync on the UI thread. This makes the application less
> responsive, and is generally bad practice. Not worth the benefit of making it easier to guarantee
> the programmatically added new codebases come after. There are better ways to do it async than
> manually spawning a new Thread, though, yes. eg SwingWorker as you said on IRC, or Executors and
> Runnables as I suggested. Still, these potential enhancements to the multithreading model would
> still have the codebase ordering problem.

I agree thath do it in gui thread is wrong. But I disagree with current aproach and new suggested 

Correct aporach is:
invoke thread (swingworker)
   disable gui or show dialog with progressbar or soem wait please
    (so gui will be "responsoble")
wait for thread.

Would be correct approach.

However - the polici files *are* small. So the burden of *doing it IN*  AWT is imho acceptable.


More information about the distro-pkg-dev mailing list