graphic features, part 2 #85

Activity

1. kushalkolar commented on Dec 25, 2022

   

   kushalkolar

   on Dec 25, 2022

   Last edited by kushalkolar

   MemberAuthor

   More actions

   think about whether these features should be attached as @properties to a Graphic. This would allow defining the getter to return GraphicFeature.feature_data, and the setter with GraphicFeature._set(). The advantage is that it would allow using the getter return value for other things, unlike now.

   Internally, such as for events etc, we set the GraphicFeature instance as private like self._colors and use the methods, self._colors.add_event_handler(...)

   Edit Apr 19 2023: I think let's keep it as is, where a call, i.e. colors(), must be used to get the data in the buffer for the GraphicFeature. Because users may want to do customized things like colors.add_event_handler() etc. and this allows us to have more public methods in the future if necessary for features.
2. kushalkolar commented on Dec 26, 2022

   

   kushalkolar

   on Dec 26, 2022

   Last edited by kushalkolar

   MemberAuthor

   More actions

   Ideas for colorbar and legends: auto-generate based on graphic name. Legend could be a class that takes in a list of graphics. For colorbars, we could add a method to Colors Feature "get_colorbar" which takes args for text of title, low, mid, high vals. The colorbar should auto update the colors whenever the line or scatter etc color changes
3. kushalkolar commented on Apr 17, 2023

   

   kushalkolar

   on Apr 17, 2023

   Last edited by kushalkolar

   MemberAuthor

   More actions

   So making indexing with numpy.integer types requires converting those to int, maybe do it in cleanup_slice(), need to organize all this parsing better.

   EDIT: I think this was done in #177
4. kushalkolar

   assigned

   clewis7

   on Jun 22, 2023
5. kushalkolar

   closed this as completedon Sep 9, 2023