Page MenuHomePhabricator

efl text widgets
Open, TODOPublic

Description

This is the current state from devs/tasn/ifaces which I've hacked (a lot) to work with current eolian for the purposes of generating a report:

class Efl2.Ui.Text
├ (P) valign
├ (P) scrollable
├ (P) cnp_mode
├ (P) selection_handler_disabled
├ (P) context_menu_disabled
├ (M) cnp_copy
├ (M) cnp_cut
├ (M) cnp_paste
├ (M) context_menu_clear
├ (M) context_menu_item_add
├ (E) cnp,paste
├ (E) cnp,copy
├ (E) cnp,cut

class Efl2.Ui.Label
 |class Efl.Ui.Text
 |├ (P) scrollable
 |├ (P) input_panel_show_on_demand
 |├ (P) context_menu_disabled
 |├ (P) cnp_mode
 |├ (P) input_panel_language
 |├ (P) selection_handler_disabled
 |├ (P) input_panel_layout_variation
 |├ (P) autocapital_type
 |├ (P) password_mode
 |├ (P) input_panel_return_key_disabled
 |├ (P) prediction_allow
 |├ (P) input_hint
 |├ (P) input_panel_layout
 |├ (P) input_panel_return_key_type
 |├ (P) input_panel_enabled
 |├ (P) input_panel_return_key_autoenabled
 |├ (P) item_factory
 |├ (M) input_panel_show
 |├ (M) selection_copy
 |├ (M) context_menu_clear
 |├ (M) input_panel_imdata_set
 |├ (M) input_panel_imdata_get
 |├ (M) selection_paste
 |├ (M) input_panel_hide
 |├ (M) cursor_selection_end
 |├ (M) selection_cut
 |├ (M) context_menu_item_add
 |├ (M) cursor_new
 |├ (E) changed
 |├ (E) changed,user
 |├ (E) validate
 |├ (E) context,open
 |├ (E) preedit,changed
 |├ (E) press
 |├ (E) redo,request
 |├ (E) undo,request
 |├ (E) aborted
 |├ (E) anchor,down
 |├ (E) anchor,hover,opened
 |├ (E) anchor,in
 |├ (E) anchor,out
 |├ (E) anchor,up
 |├ (E) cursor,changed,manual
zmike created this task.Sep 30 2019, 9:34 AM
zmike triaged this task as TODO priority.
zmike edited projects, added efl: api; removed efl: language bindings.
zmike updated the task description. (Show Details)
class Efl2.Ui.Text
├ (P) valign

This seems like it could just be efl.gfx.arrangement::content_align.

├ (P) scrollable

This could probably be managed through efl.ui.widget_scrollable_content::scrollable_content for anyone who wants it?

├ (P) cnp_mode
├ (P) selection_handler_disabled

This seems a bit strange? I'd imagine this type of thing should use a selection API and not be directly part of the widget.

├ (M) cnp_copy
├ (M) cnp_cut
├ (M) cnp_paste

I'll leave these since I don't know how fully the cnp stuff is thought out at this point.

├ (P) context_menu_disabled
├ (M) context_menu_clear
├ (M) context_menu_item_add

This context menu API feels pretty ugly to continue using, just as it did in legacy. I imagine we can come up with better ideas here?

├ (E) cnp,paste
├ (E) cnp,copy
├ (E) cnp,cut

These events should all probably have event info.

tasn added a comment.Oct 1 2019, 1:19 AM

Thanks for your comments. The branch generates just fine here (other than the C++ bindings that don't compile, but that will be fixed once I rename things). Are you using latest Eolian or the one from my branch? Because q66 recently made some breaking changes.

As for your comments:

In T8289#144050, @zmike wrote:
class Efl2.Ui.Text
├ (P) valign

This seems like it could just be efl.gfx.arrangement::content_align.

Thanks for the tip. It does indeed, though it means I have to also implement padding I guess?

├ (P) scrollable

This could probably be managed through efl.ui.widget_scrollable_content::scrollable_content for anyone who wants it?

Not sure I follow. This lets you set arbitrary scrollable objects inside of a widget, I just want to enable/disable scrolling.

├ (P) cnp_mode
├ (P) selection_handler_disabled

This seems a bit strange? I'd imagine this type of thing should use a selection API and not be directly part of the widget.

So pull it out to its own interface?

├ (M) cnp_copy
├ (M) cnp_cut
├ (M) cnp_paste

I'll leave these since I don't know how fully the cnp stuff is thought out at this point.

The idea was to emulate a copy/cut/paste, so you can for example add a button to do them.

├ (P) context_menu_disabled
├ (M) context_menu_clear
├ (M) context_menu_item_add

This context menu API feels pretty ugly to continue using, just as it did in legacy. I imagine we can come up with better ideas here?

I completely agree, though I'm not sure what makes sense there. I initially wanted to just support generic objects, though we would need to create a different widget which would be the standard child (so uses the correct theme) and lets you do this. I guess we probably have something similar for menus. Any insights on this?

├ (E) cnp,paste
├ (E) cnp,copy
├ (E) cnp,cut

These events should all probably have event info.

Many events should. Though see my email on the ML. Still need to figure these ones out.

zmike added a comment.Oct 1 2019, 6:00 AM
In T8289#144119, @tasn wrote:

Thanks for your comments. The branch generates just fine here (other than the C++ bindings that don't compile, but that will be fixed once I rename things). Are you using latest Eolian or the one from my branch? Because q66 recently made some breaking changes.

As for your comments:

In T8289#144050, @zmike wrote:
class Efl2.Ui.Text
├ (P) valign

This seems like it could just be efl.gfx.arrangement::content_align.

Thanks for the tip. It does indeed, though it means I have to also implement padding I guess?

At some point, yes; content_padding is being redesigned a bit (D10154). I'm not entirely sure it makes sense to have a full implementation, however, as it overlaps with efl.gfx.hint::hint_margin. This could imo be @empty or just stubs that print errors when called.

├ (P) scrollable

This could probably be managed through efl.ui.widget_scrollable_content::scrollable_content for anyone who wants it?

Not sure I follow. This lets you set arbitrary scrollable objects inside of a widget, I just want to enable/disable scrolling.

Ah, sorry, I was thinking of implementation details (T8290) with this, so it can be disregarded.

├ (P) cnp_mode
├ (P) selection_handler_disabled

This seems a bit strange? I'd imagine this type of thing should use a selection API and not be directly part of the widget.

So pull it out to its own interface?

Not by itself, it should already be part of whatever selection interface we're using, I would think? A reusable API for toggling the capability of having a selection for widgets that want to add it.

├ (M) cnp_copy
├ (M) cnp_cut
├ (M) cnp_paste

I'll leave these since I don't know how fully the cnp stuff is thought out at this point.

The idea was to emulate a copy/cut/paste, so you can for example add a button to do them.

Sure, I just didn't know whether you were also doing anything related to selection, as this API should definitely not be in a text widget and should be in a reusable selection/cnp interface/mixin.

├ (P) context_menu_disabled
├ (M) context_menu_clear
├ (M) context_menu_item_add

This context menu API feels pretty ugly to continue using, just as it did in legacy. I imagine we can come up with better ideas here?

I completely agree, though I'm not sure what makes sense there. I initially wanted to just support generic objects, though we would need to create a different widget which would be the standard child (so uses the correct theme) and lets you do this. I guess we probably have something similar for menus. Any insights on this?

This is a good question. cc @bu5hm4n for additional brainpower

├ (E) cnp,paste
├ (E) cnp,copy
├ (E) cnp,cut

These events should all probably have event info.

Many events should. Though see my email on the ML. Still need to figure these ones out.

Yup, just going through our usual API review workflow.

zmike moved this task from Backlog to Evaluating on the efl: api board.Oct 14 2019, 5:56 AM