Morpho XML Editor updates

[Matthew Brooke]

Dan:

 >>  Obviously I didn't make it clear that there there may be 500 editor 
panel on the right
 >> and there is no need to click on the tree on the left when moving 
between them. Thus
 >> one cannot simply use tree selection events to save changes in the 
panels.

...which is why I also advocated using the "finish" button to gather 
those values too.  You could use Container's getComponents() method to 
get all panels, and call actionPerformed() on the ones that are wizard 
wrapper panels.  Basically, if the user is trying to use an editor with 
500 editor panels on the right, then we can *guarantee* that they will 
miss some of these buttons, and they *will* lose their edits - probably 
without even realizing it. 


 >> And to keep the tree selection in synch with the panel being edited 
there needs to be
 >> communucation as panel widgets are selected, not when the tree is 
clicked.

If they don't press the buttons, this update will never happen anyway.  
You could maybe even do updates based on glasspane mouse clicks?


I'm only advocating fixing this because it is the kind of issue that 
will reinforce the often-heard perception that Morpho is an annoying, 
unreliable software that "loses" peoples' data - not good for the 1.5 
"gold" release...

M


Dan Higgins wrote:

> Matthew,
>    Obviously I didn't make it clear that there there may be 500 editor 
> panel on the right and there is no need to click on the tree on the 
> left when moving between them. Thus one cannot simply use tree 
> selection events to save changes in the panels. And to keep the tree 
> selection in synch with the panel being edited there needs to be 
> communucation as panel widgets are selected, not when the tree is 
> clicked.
>
> Dan
>
> ----
>
> Matthew Brooke wrote:
>
>>
>> Dan:
>>
>> >> I would like to point out that this interface has exactly the same 
>> number
>> >> of steps as the Wizard where there is a 'Save' and 'Cancel' button 
>> for each page
>>
>> The point I'm trying to make is that the extra step in the editor is 
>> unnecessary from the user's point of view (which is why only some of 
>> the editor panels have save buttons, not all of them) , whereas all 
>> the wizard pages require a "next" button to be clicked (because it's 
>> a wizard...)
>>
>>
>> >> there is NO EASY WAY TO DO THIS WITHOUT MAKING SUBSTANTIAL
>> >> CHANGES TO THE WIZARD PANE CODE (OR THE EDITOR).
>>
>> No need to shout :-P   why wouldn't this work:
>>
>> a)  in morpho/editor/DocFrame.java, add a line to the valueChanged() 
>> method of your SymTreeSelection class (which will get called every 
>> time a user clicks on a tree node)
>>
>> b)  when this event occurs, check if you have one of your wrapper 
>> classes (eg AttributePanel.java) in the right hand pane, and if so, 
>> call its saveButton.doClick() method
>>
>> c) repeat for editor's "Finished" button listener
>>
>>
>> That way the DOM gets updated whenever the user clicks a different 
>> tree node and when they click "finish".  Unless I've missed something 
>> major, this doesn't appear to be a substantial change?
>>
>> M
>>
>>
>>
>>
>>
>>
>> Dan Higgins wrote:
>>
>>> Matthew,
>>>
>>>     I agree with most of your comments, except in 1) I would like to 
>>> point out that this interface has exactly the same number of steps 
>>> as the Wizard where there is a 'Save' and 'Cancel' button for each 
>>> page. An advantage of repeating those buttons is that the panels in 
>>> the editor are essentially identical with the pages in the Wizard.
>>>
>>>     Nevertheless, having the 'in-line' Save & Cancel buttons is 
>>> somewhat confusing. The standard nested text panels on the right of 
>>> XML editor were written to use focus events to keep the tree 
>>> up-to-date as information is edited (and the appropriate tree node 
>>> is selected as one selects new panels). We should do the same thing 
>>> with special editor panels like those taken from the Wizard, but 
>>> there is NO EASY WAY TO DO THIS WITHOUT MAKING SUBSTANTIAL CHANGES 
>>> TO THE WIZARD PANE CODE (OR THE EDITOR). In other words, the 
>>> existing editor panels were put together with the goal of minimizing 
>>> changes in either the Wizard code or the XML editor code. Thus the 
>>> Save button is needed to save any changes in the Wizard pages 
>>> displayed in the editor (just reusing code from the Wizard).
>>>
>>>     Note that the problem is that the XML editor can display 
>>> multiple pages - e.g. if one selects the the attributeList in the 
>>> tree, a whole series of attribute pages will appear on the right 
>>> side of the screen. One could then move from one page to another and 
>>> never save the edits (because no events are triggered) until a whole 
>>> lot of changes have been made. And the tree would not get updated 
>>> while all these changes were being made. Maybe we could figure out 
>>> how to do this without changing the wizard page code, but it would 
>>> seem to require a lot of changes in the XML editor.
>>>
>>>     Otherwise, we would need to revise all the widgets used in the 
>>> Wizard to handle/generate events. For textboxes, this might mean 
>>> simply handling focus gained/lost events, but it would be more 
>>> complicated figuring how to deal with other widgets like the radio 
>>> buttons used to change subpanels in the AttributePage.
>>>
>>>     Frankly, I am very hesitant to start making the changes needed 
>>> to avoid the Save/Cancel buttons prior to the planned 1.5 release in 
>>> April. We still haven't completely frozen the code base and started 
>>> seriously working on bug elimination and performace enhancements. It 
>>> seems to me that substantaial code changes are needed to handle the 
>>> wizard pages without the Save/Cancel buttons. And I am worried that 
>>> we are running out of time! (So my real concern is priority of such 
>>> changes.)
>>>
>>> Dan
>>>
>>>
>>> --------------
>>>
>>> Matthew Brooke wrote:
>>>
>>>>
>>>> Hey Dan -
>>>>
>>>> The revised editor looks great - I especially like the attributes 
>>>> representation.
>>>>
>>>> I'd strongly vote for not having the additional "save" & "cancel" 
>>>> buttons, though, for the following reasons:
>>>>
>>>> 1) we're making users perform an extra (redundant) step that they 
>>>> wouldn't have to perform under similar circumstances in most other 
>>>> user interfaces - the "save" functionality could be performed by 
>>>> the editor without their having to hit a button.
>>>> (this also applies to those buttons below the spreadsheet in the 
>>>> main morpho data view that we were going to delete... :-)
>>>>
>>>> 2) It may be confusing for users, having "save", "cancel", "revert" 
>>>> and "finish" buttons all in the same area (this is the feedback we 
>>>> got with the original XUL wizard that Chris & I did, where we had 
>>>> "dialogs" nested inside the existing wizard frame - even though we 
>>>> grayed out the main wizard buttons).
>>>>
>>>> 3) I'm guessing the "save" & "cancel" buttons aren't shown in all 
>>>> editing panes - only in the ones imported from the wizard (is this 
>>>> true?). This may further confuse users - they have to hit "save" on 
>>>> some panels, but not on others.
>>>>
>>>> 4) If the user fills in some "attribute" data (in your screenshot) 
>>>> and *doesn't* hit "save", but clicks on other tree nodes and makes 
>>>> other edits, and finally clicks "finish", will the "attribute" 
>>>> changes never make it into the final DOM?
>>>>
>>>> It seems both safer and less confusing to get rid of the "save" & 
>>>> "cancel" buttons, and "commit" the data based on change of focus - 
>>>> e.g. insert the data from the wizard panel into the DOM when the 
>>>> user clicks a different tree node and/or clicks "finish" - is this 
>>>> feasible?
>>>>
>>>> Cheers
>>>>
>>>> M
>>>>
>>>
>>>
>>> -- 
>>> *******************************************************************
>>> Dan Higgins                                  higgins at nceas.ucsb.edu
>>> http://www.nceas.ucsb.edu/    Ph: 805-892-2531
>>> National Center for Ecological Analysis and Synthesis (NCEAS) 735 
>>> State Street - Room 205
>>> Santa Barbara, CA 93195
>>> *******************************************************************
>>>
>
>