Page MenuHomePhabricator

Name conflict between class and property
Open, TODOPublic

Description

There are name conflict cases between class and property. For example,

  • Efl.Ui.Text Class name and Text property of Efl.Text interface. (D7394#129052)
  • Efl.Canvas.Text Class name and Text property of Efl.Text interface.
  • Efl.Input.Hold Class name and its Hold property.
  • Efl.Input.Key Class name and its Key property.

In eolian_mono, Efl.IText.Text is listed in blacklist because of Compiler Error CS0542(https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0542). there are only getter, setter methods(GetText, SetText).

The other UI Frameworks text widget naming will help this discussion.

EFL(elm)EFL(Efl.Ui)XamarinWPFUWPAndroid
for presenting textLabelTextLabelTextBlockTextBlockTextView
for editing single line textEntryText, TextEditableEntryTextBoxTextBoxEditText
for editing multi line textEntryText, TextEditableEditorTextBoxTextBoxEditText

Android:
TextView - https://developer.android.com/reference/android/widget/TextView
EditText - https://developer.android.com/reference/android/widget/EditText

WPF :
TextBlock - https://docs.microsoft.com/en-us/dotnet/api/system.windows.controls.textblock?view=netframework-4.8
TextBox - https://docs.microsoft.com/en-us/dotnet/api/system.windows.controls.textbox?view=netframework-4.8

UWP : https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/text-controls
Xamarin : https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/text/

I'd like to suggest some widget names.

  • TextView - It may make conflict with MVVM namespace.
  • TextBlock - There is evas_object_textblock. but it is legacy evas_object(not eo). so, it won't be problem.
  • EditableText - In this case, Text and TextEditable should be merged.
YOhoho created this task.Jul 31 2019, 12:18 AM
YOhoho triaged this task as TODO priority.
YOhoho added a parent task: T7849: efl.ui.text.
YOhoho updated the task description. (Show Details)Jul 31 2019, 12:27 AM

Thanks for a very detailed report!

These are the last three remaining name conflicts, which are blacklisted by eolian_mono. When we fix them, we can finally remove that blacklist.

  • Efl.Input.Key: We should reopen T7964.
  • Efl.Input.Hold: We should reopen T7965.
  • Efl.Ui.Text and Efl.Canvas.Text: Yeah, we need to rename them. TextLabel and TextEntry look fine to me, but maybe there was a reason to move away from these names when we moved from Legacy to Unified (@cedric? @tasn?). We have to avoid View.

I agree that TextEditable is just a Text widget with editable = true in the constructor, but this is a very common case, so I would not remove it.

For Efl.Canvas.Text, I think it should be TextView (since it is most basic text element), TextLabel is more advanced element to show one line text.

Efl.Ui.Text can be "Textbox" or "Textblock" but again it may be conflicted with legacy canvas textblock

Question ?
Efl.Ui.Text and Efl.Canvas.Text are interfaces or objects ? if they are interfaces why donot we use "I" infront to detect that they are interfaces like Efl.UI.IText

Names containing the word View should be reserved for MVVM widgets. Otherwise it's going to be very confusing.
Other than that, I have no strong opinion. There cannot be name conflicts between Legacy and Unified APIs since they are in different namespaces.

The EFL C API does not use I to indicate interfaces. It was deemed too verbose. The C# bindings add the I prefix, though, because that's the common practice in that language.

If you open their eo files you can see that both Efl.Ui.Text and Efl.Canvas.Text are classes.

For Efl.Canvas.Text, I think it should be TextView (since it is most basic text element), TextLabel is more advanced element to show one line text.

Efl.Ui.Text can be "Textbox" or "Textblock" but again it may be conflicted with legacy canvas textblock

Question ?
Efl.Ui.Text and Efl.Canvas.Text are interfaces or objects ? if they are interfaces why donot we use "I" infront to detect that they are interfaces like Efl.UI.IText

The I prefix is a C#-specific thing for all interfaces. It is added by eolian_mono to generated code.

AFAIK at eolian/C level we have no such prefix for interfaces.

ali.alzyod added a comment.EditedJul 31 2019, 8:32 AM

Sorry I did not use EFL in C#.

Other Issue :
For most systems TextEdit or TextBox/block are inherited from TextView (or have same functionality)

But what is the relation between EFL_UI_TEXT and EFL_CANVAS_TEXT ? I think normal user should not use EFL_CANVAS_TEXT because it is supposed to be low level canvas, and the widgets founded in EFL_UI not CANVAS

Other Issue :
For most systems TextEdit or TextBox/block are inherited from TextView (or have same functionality)

What is the issue?

But what is the relation between EFL_UI_TEXT and EFL_CANVAS_TEXT ? I think normal user should not use EFL_CANVAS_TEXT because it is supposed to be low level canvas, and the widgets founded in EFL_UI not CANVAS

Agreed. Widgets are in the Efl.Ui namespace, low level drawing APIs are in the Efl.Canvas namespace.

ali.alzyod added a comment.EditedJul 31 2019, 10:29 AM

@segfaultxavi the issue I am talking about, TextView(or label) and TextEdit should be widgets
I think all ui components in this task for other platforms are (@YOhoho please correct me if i am wrong) are widgets.

And Efl_Canvas_Text is not widget, it is low level canvas.

So compare to other platforms TextView(lable) and TextEdit should come from Efl_UI and one is base to the other.
But As I see it, Efl_UI_Text is huge class contains everything, if you want specific text widget then user enable/disable properties to custom user needs

Android:
view.View -> widget.TextView
view.View -> widget.TextView -> widget.EditText

Xamarin:
Element -> NavigableElement -> VisualElement -> View -> Label
Element -> NavigableElement -> VisualElement -> View -> InputView -> Entry
Element -> NavigableElement -> VisualElement -> View -> InputView -> Editor

WPF, UWP:
UIElement -> FrameworkElement -> TextBlock
UIElement -> FrameworkElement -> Control -> TextBox

EFL
Efl.Canvas.Object -> Efl.Canvas.Text
Efl.Canvas.Object -> Efl.Canvas.Group -> Efl.Ui.Widget -> Efl.Ui.Layout_Base -> Efl.Ui.Text (Note: Efl.Ui.Text has Efl.Canvas.Text(composition))

It seems that only Android EditText is inherited from TextView.
In UWP case, TextBlock is not Control but it used for read-only text.

ali.alzyod added a comment.EditedAug 1 2019, 1:40 AM

I think WPF arrange things for user usage simplicity :)

When using WPF you will find TextBlock and TextBox in same control name space system.windows.controls. (Textblock or Textbox)
https://docs.microsoft.com/en-us/dotnet/api/system.windows.controls?view=netframework-4.8

So maybe there are two types of hierarchy, one for usage(visibility) and one for development

@tasn @cedric @zmike @bu5hm4n @segfaultxavi

Do you have other candidate names for Text classes ?
I also like the idea of WPF, but I hope to hear your ideas.

Env class has an env property. It is multi-valued, so it is not generating a problem for C# yet. But it may in the future.

tasn added a comment.Aug 19 2019, 1:23 AM

@woohyun, I'm going to reshuffle things in the text space so I wouldn't worry about making a decision/change yet. I'll take a look at the WPF naming scheme when changing though.