Page MenuHomePhabricator

Release prep: cleanups, tests and thoughts
Open, Incoming QueuePublic

Description

This task contains some of my cleanup suggestions, tests and thoughts for the future. Not all are urgent/needed, but wanted to have them written down somewhere so they can be addressed (or not) before the release.

Remove format nodes internally and just use annotations.

As the title says, we don't need format nodes anymore, we should just have annotations, so we can remove all of the extra bloat that's format nodes from the internals.

Verify all of the events are called when they should, and only then

We have text related events, make sure they are called when needed.

Fix newly added FIXMEs and #warning directives

They point to things that need to be addressed before the release - so address them.

Make sure styles work as expected

No regressions

Make sure that there aren't any memory leaks

Run the tests with valgrind and verify nothing was added.

Make sure annotations work as expected

They should, as a lot of the code is shared with the old one, but still need some nice tests for this.
Especially for the newly added ephemeral types.

Context menu functions in Efl2.Ui.Text needs changing

This was discussed in T8289. My suggested alternative:

  1. Do like we do for other menus in elementary - best one, need to verify what's done there.
  2. Make it support generic objects instead of the current design and use an item class that can be created to create the items.
  3. Have a callback on the item object rather than the item, and add a key to items so we can know which item was clicked.

Merge back or share a lot of code between Efl.Canvas.Text and Textblock.Legacy

I split them so I can make changes without being hindered by legacy. Though a lot of the code is still the same. These could potentially be merged into the same object, as many of the internal changes were improvements that can be backported.
I think though it's better not to merge them, but rather share only parts of the code, because, for example, the internals of Efl.Canvas.Text can now be greatly improved due to the simpler API that doesn't leak implementation details.

This is not urgent, but better to do it before they diverge too much (if many changes are planned).

tasn created this task.Oct 12 2019, 7:48 AM
zmike moved this task from Backlog to Evaluating on the efl: api board.Oct 14 2019, 5:55 AM
zmike added a comment.Oct 14 2019, 6:05 AM

The context menu part is tricky since we have no eo-based menu widget at present.

Events :

  • Menu,Open Exist
  • Menu,Closed Exist
  • Menu,Preopen New allow the user to init menu (like add items) before opening it.

Functions for Items:

  • context_menu_item_add Exist
  • context_menu_item_remove New to remove item from menu
  • context_menu_item_hide New to hide item from menu
tasn added a comment.Oct 14 2019, 11:24 PM

@ali.alzyod, while this may be good feedback, this is not exactly what we are talking about. We are talking about the item_add function signature.

@zmike: maybe keep the context menu functions as @beta until we add a menu widget? Is the hover widget also still in beta?

zmike added a comment.Oct 15 2019, 5:43 AM

Keeping menu functions in beta I suppose is fine, though it really seems more like the kind of thing where instead of having this type of API we would have some other widget (e.g., Efl.Ui.Menu) which functions through a mixin or somesuch to provide Efl.Ui.Context_Menu, and we would simply efl_add this to the text widget instead of having any API for it in the text class.

There is no hover widget. There is Efl.Ui.Popup, which has an anchor property and could be set to contain a box of buttons to mimic a menu, but I haven't seen any plans to create a menu widget.

tasn added a comment.Oct 15 2019, 5:58 AM

Yup, we have a similar idea in mind.

ali.alzyod moved this task from Evaluating to Backlog on the efl: api board.Wed, Feb 5, 12:24 AM