Community
Participate
Working Groups
- investigate having global CoolBar layout vs. saving a coolbar layout per perspective - investigate simplifying the positioning of remembered coolitems - need a try/finally block around code that sets the redraw flag to false so if an exception occurs redraw is set back on, need to check ToolBarManager also for this - as part of action cleanup need to come up with a story for CoolItemMultiToolBarManager
- cleanup plugin action processing (revisit ordering bug report)
- is setRedraw necessary for busyResetPersp and setPersp????
setRedraws are necessary for switching/resetting perspectives, otherwise the coolbar gets really flashy as the coolbar area is resized.
Created attachment 4687 [details] code jar
Attached jar which has changes for global layout, simplified remembering, and proper handling of setRedraw flag. Waiting for feedback from NE regarding global layout handling. Changed the code to always set coolitem sizes to minimum sizes when update() occurs. It turns out to be impossible (well very difficult) to incrementally change the layout of the coolbar via the current API. setSize() in particular is screwy/difficult to use because of the requirement that the coolitems on a row completely span the row. So setting the size of one coolitem will affect the size of other coolitems.
NE okayed new behavior. Released changes. Minimum size for coolitems is always maintained. Coolitems are sized whenever an update(boolean) on the coolbar takes place. If you arrange your coolbar such that coolitems have extra space between each other, this space will get "reclaimed" when an update occurs. Also reduced the complexity of the restoring remembered position algorithm. The simplified version seems adequate. If too much rearranging of the coolbar is done, the added item will just be added to the end of the coolbar.
