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

[Andrew Azores]

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.

Thanks,

-- 
Andrew A