palette-separators -- Palettes should support separators

[deyan]

List palettes should have (complex) separators

• Separators should be list element, but are with different height
• (Optional) Some separators should be draggable
• Separators should have title (1)
• (Optional) Some separators should have icon that collapses/expands the list to the next separator
  

[deyan]

Batch update from file active_tickets.csv

[deni]

General support for separators

• Add a new class ListPaletteSeparator with the following methods:
  • public abstract String getTitle()
  • public abstract boolean accepts(ListPaletteItem item) - checks whether theseparator is responsible for the specified palette item.
  • public abstract boolean isCollapsible() - returns whether this separator can be expanded/collapsed or not.
  • public RwProp<Boolean> isCollapsed() - property holding information about the state of this separator - expanded or collapsed.
  • public Prop<Icon> expandedIcon() - the icon to use when the separator is in expanded state. Gets it from the skin.
  • public Prop<Icon> collapsedIcon() - the icon to use when the separator is in collapsed state. Gets it from the skin.
  • public ListPaletteItem getSeparatorItem() - returns a ListPaletteItem that renders the separator. See ListPaletteSeparatorItem below.

• Add a new class ListPaletteSeparatorItem extending ListPaletteItem to visualize a separator.
  • It will be constructed by ListPaletteSeparator and will keep it in a final property.
  • Its render() method will return a panel with BoxLayout that contains:
    • A panel with TitleBorder for the title of the separator. Since it will not have preferred size it will be resized to fit the available space.
    • A label with the appropriate icon (only if the separator is collapsible).
  • It will override InteractableItem.clicked to provide logic for expanding/collapsing the list of items.

• ListPalette changes:
  • A new property holding a list of the separators will be added. It will use the public List<? extends ListPaletteSeparator> getSeparatorsList() method which by default returns an empty list.
  • The abstract Prop<ImmList<I>> items() property will be left as it is so that implementors can easily specify the palette's items.
  • A new property will be added - public AutoListProperty<ListPaletteItem> orderedItems() that keeps a list of all the items that will be added in the list (including separator items) in the correct order. It will use the list of items and the separators.
    • It will be used instead of the items property everywhere.

Adding separators in AllResourcesPalette

• Add a new class AllResourcesPaletteSeparator - a separator responsible for resources of a specific kind.
  • It will be constructed by a resource kind (String) and will override the following methods:
    • public boolean accepts(ListPaletteItem item) will compare the resource kind it was constructed by and the kind of the resource of the given ResourceItem. It should not only compare the strings, but also take into account the kind-subkind relationship, i.e. 'image-frame' is a kind of 'frame' and a frames separator should accept image frames.
    • public String getTitle() will get the title from the skin. The element class will be the resource class (subclass of ResourceR4) and the property-id will be a public static final field in AllResourcesPalette.
    • public boolean isCollapsible() will return true.

• Register as extensions:
  • Separators for the different resources (HotTextResourceR4, ImageResourceR4, FrameR4, etc).
  • Titles for all registered separators.
  • Icons for the expanded and collapsed states of AllResourcesPaletteSeparator.

[deni]

Source code: [8791]

[pap]

• We liked the description of the design and most of its ideas but have the following remarks:
• Change the AutoListPropertys in ListPalette with AutoProperty<ImmList>s.
• Also rename AllResourcesPalette to ResourcesPalette and AllResourcesPaletteSeparator accordingly.
• If you have problems/questions that are left you should state them clearly in the design text and not leave them in "TODO" comments in the code.
• Also please when you write TODOs follow the convention "TODO: comment --deni@yyyy-mm-dd".
• ResourcePaletteSeparators related
  • Create an empty(marker) interface ResourcePaletteSeparator.
  • Let the current ResourcePaletteSeparator implement that interface and be called something like KindResourceSeparator.
  • About the frames create another class that directly implements the interface and its accept method uses the R4 class of the resource of the given ResourceH and checks whether it derives from FrameR4.
• You didn't explain the extension point you created so we didn't understand how separators will be registered as extensions.
• Also registering titles and icons sounds very strange. Meddle couldn't understand that. You'd better have said that they would be a part of the skin.
• Please when you put a mark to the analysis explain briefly why did you select that exact mark.

[deni]

• I don't have any unresolved design issues. Thanks for reminding me to mention them in the design text, but I usually do so...
  • I do have some 'TODO's left, but I think this is normal since the task is not yet implementation_finished. They help me find the unimplemented parts of the task, so I'll keep leaving them. Sorry if they somehow bother you.

• The convention "TODO: comment --author@yyyy-mm-dd" is a good one, but we have not officially adopted it and there are very very few such 'TODO's in Sophie. If you insist on using it, maybe you should propose it to the whole team. Then it should be added in the GoodCodeExamples page so that everybody interested in our code conventions could see it (for example, new people working on Sophie).

• I don't think I should spend time putting a mark to the analysis and explaining it because noone the analysis people won't read it. But since you sound interested:
  • I liked this analysis because it is clear enough and has a picture :-). Besides, the requirements are prioritized and some are left optional.
  • Adding separators to the Resources palette is not mentioned at all. I needed some more details and talked to deyan during the design phase.

• Actually I don't know the meaning of the different scores and I couldn't find it explained somewhere. Maybe I need a discussion about our process.

[deni]

• After a long discussion with pap made ListPaletteSeparator and ResourcePaletteSeparator interfaces and the previous ListPaletteSeparator and ResourcePaletteSeparator - their base implementations. Also had to make ListPaletteSeparatorItem an abstract class and add a base implementation for BaseListPaletteSeparator.

• "Other" separator in ListPalette - responsible for all items for which there was no other apprpriate separator:
  • add a private field to keep this separator and a private method to create and get it - getOtherSeparator(boolean, Icon, Icon)
  • add the "Other" separator to those defined by the specific palette in separators()...compute()
  • add a private Set field in ListPalette to keep the lastly used items and use it in the "Other" separator's accepts() method.
  • Whether it is collapsible and its collapsed/expaded icon will be in the skin.

• As suggested in the design review:
  • changed the separators and orderedItems to AutoProperty<ImmList>s
  • renamed AllResourcesPalette and some related classes

[deni]

Source code: [8791], [8795], [8796] and [8799]

[meddle]

Merged to the trunk at [8827].

• We changed the size of the collapse/close icons.
• I renamed some strangely named things, for example a property isCollapsibleProp is now just collapsible, it is boolean and it is a prop, not getter. Good idea is the base implementations of the interfaces to be named Base|Interface_name| and not |Interface_name|Impl. I renamed the base separator.
• Otherwise good work

3.5p

[meddle]

Closing all the tickets before M Y1