evas_font_dir.c:723 already check for if (!font) so I do think it will case overwritten in this part.
Exactly, what data EDC/EINA type we should use to compile/decompile EDC files into Edje, and still be able to read these values.
Yes it passes
I also think parse_int(i) ("i" would be increased till the end of the input) can be used instead of string.
In edje_cc_handler.c , you can check how to use parse_int() easily :)
Tue, Oct 15
Because the Button widget uses the basic text object which doesn't support markup.
Are there any reason for button or other widgets to not implement Efl.Text.Content.Markup instead of Efl.Text.Content.Plain
I think it is great feature and already implemented, so why not to use it
Not sure I follow. The first two I already said we need, and are in the interface.
What interface ?
You don't need to range set, you just insert the markup again. So range get -> markup insert.
Mon, Oct 14
- Menu,Open Exist
- Menu,Closed Exist
- Menu,Preopen New allow the user to init menu (like add items) before opening it.
Do we really need two interfaces? we can combine them into one interface, since no one really uses interface Efl2.Text.Content.Plain but instead will use interface Efl2.Text.Content.Markup
So I think combining them into one make sense.
interface Efl2.Text.Content |├ (P) markup |├ (P) text |├ (P) bidi_delimiters
Tue, Oct 8
OK, just wanted to flag it because it looks like css but it behaves quite differently.
This is related to T8067
At this point I am not using CSS styles, But in some point in future we will have something like evas_textblock_css_style_set("color:rgba(255,255,255,1.0);"); which will be converted to EFL style which is "color=rgba(255,255,255,1.0)"
Thu, Oct 3
Well, markup handling is external to the text object, we can implement a "legacy_markup" class that translates legacy markup to current one and legacy applications can use. How does that sound?
I still hate there is no background compatibility, thats why I suggested having restriction Mode (NONE, RESTRICTED), where NONE will work the same as legacy one, but for restricted mode, we can add new rules that should be followed.
I have two comments:
is it ok now ?
These functionality already implemented and working, but you want to remove them, (At Widget/Canvas level)
So you are the one needs to give good argument why to remove them,
and the font_size_factor example is not right, the widget will not inherit this font other widget, and EFL was work fine for so long without this feature and we can add it at markup level If Markup can not be implemented externally it is ok, this will give us dynamic why to make a lot of additional features along the way,
Wed, Oct 2
Again, you misread what I said and this is not actually what's going on.
I plan on bringing back style_user, or the style stack. Essentially meaning you have two styles per object. I accidentally removed it, or maybe it was removed by Efl.Canvas.Text and I just forgot to add it back.
evas_object_textblock_style_user_push is legacy API, and with latest changes you can not use it with efl_canvas_text.
I meant the reading. Again we are talking about reading, not writing. I'm saying that in these other platforms you can't sensibly read the value and do something with it. Like you can't do with the EFL. Don't get hung up on the details. The point is that you can't do what you want to do here.
I got the syntax a bit wrong, sorry, but the value is still a string, and the user can't just get it and do something with it, which is what we are talking about here. Not without a lot of parsing, and even with the parsing (understanding what 100% means), they would still need to analyze the whole hierarchy. So I think you're making my argument for me on why this is bad to let people do it.
We are not talking about dataType of these properties, font size can be string/float/double/int, this is another discussion. but for this discussion, I can say you did not approve such approach on other frameworks.
I don't know what you mean by "I" and where exactly during run-time, and how will you hook on layouting?
As for having to look at our documentation, see the link I just posted to @segfaultxavi, it can and will be very short: https://developer.gnome.org/pygtk/stable/pango-markup-language.html
You are talking about markup, and for markup I am 100% with you, and it is dynamic because it is a script
For UI_TExt properties, these should not depend on script, they are values
I will try to split this into two main categories
(1) Setting style at the object level.
For most users setting font size should be as simple as **efl_text_font_size_set(ui_text, 25);** instead of **efl_text_style_set(ui_text, "font_size=25");** It will create alot of issues with first time users like "font_size" or "fontsize" or "font-size" and he needs to look at our documention to understand, I do not think it is good Idea to use special script to do simple things as setting object font size.
I think it is fine
Tue, Oct 1
I think we can stick with what we already have, in the previous EFL_UI_TEXT, since changes may need to be done on ecore level.
And what we already provided fair functionality for any user
Sun, Sep 29
All changes ready in this pull request into your branch
Fri, Sep 27
I would expect a bug if ot actaully is NULL, so i would put some EINA_SAFETY_ON_NULL_XXX macro after the two for loops. Which would also not require to check ot in the next few if's.
This will never happen, this patch just to fix compilation warning you have
init with null
Wed, Sep 25
A small suggestion to check D9490
If colors are save as bytes there are optimized techniques to avoid float point calculation. (I do not know if this is useful here :) )
Mon, Sep 23
We compare what we have with Android and IOS, I think we already have quite decent support, I think we will need to modify ecore to add additional support.
@tasn Please note these functions/events are not suggestions, they are actually used in edje_entry but we do not have them in the new design.
It was only ever used to get the line number (now line_number_get). If you want to get the geometry of a line you can get a range geometry, but again, no one ever needed/used that.
1- It is used for in edje_entry to get the geometry of the line, not line number only
2- no one ever needed/used that How do you know that? we internally use it, so it is logical other people use it too.
3- you can get a range geometry But I will need to create two cursors, then delete them after getting the range, is this efficient?
Sun, Sep 22
While porting from edje_entry we notice missing cursor functions
Wed, Sep 18
I have two notes:
Can you please explain more about cursor handle? We read the documentation and I do not see why would the user use it if he already has copy function
Tue, Sep 17
We are talking about TextDirection (which is related to text objects), Not LayoutDirection which can be applied to other types of objects (Child of containers for example)?
Sep 16 2019
For following event in RawEditable:
preedit,changed: void; Called when entry preedit changed
In legacy code this event expect info to be passed to it (not void)
Added two more examples
1 - Like here when you type @ followed by a username, that kind of auto completion (no need to actually do the pop-up menu, it's more about finding the correct place to put it.
2- Show word suggestions in the context menu, when you long-press on the word
3- Undo/Redo Example Updated
Sep 12 2019
@tasn can you please take a look at (Undo/Redo Example):
Sep 11 2019
Sep 10 2019
I do not know why I can not get this warning!
Anyway, this will fix it D9903
gcc or clang ?
@zmike do you have special configuration for compilation? (I did not get this error by default)
Sep 9 2019
For password properties : (password_mode and replacement_char)
Will it stay on Raw_Editable or we will move it to efl.canvas.text?
I am asking this because these options are implemented directly on evas_object_textblock level
It was designed this way so you could set a background color e.g. in the style, and just turn it on and off. It's not something I changed, it was designed this way by @raster like 15 years ago. :)
I'm not wedded to this, I'm OK with changing this, but this only solves it for background. Strikethrough may have different styles (like dashed). We can also change strikethrough and backing and etc to be on by default when you set a > > colour for example. That would be a nice solution I think without breaking this ability or without adding complexity.
You are right, it was designed this way, if it is on by default (or when color is set) this would be great
Regard these two properties which contain only on/off values:
@tasn for Undo/redo example
We do not have undo/redo functionality, So this will test events (implementation of undo/redo will be handled by user). right?
- upload new font file
Sep 8 2019
Sep 7 2019
- add panel_layout
- add prediction
- add autocapition
- add imf_event
Sep 6 2019
Anchor and Items ?
Like _anchors_update, _anchors_update_check, etc and Items functions like _edje_entry_item_geometry_get, _item_obj_del_cb, etc
@tasn No it is not, we are updating/porting current Efl.Ui.Internal.Interactive.c file with edje_entry.c
Do we need to port filter functions like _text_filter_text_prepend or _text_filter_markup_prepend, ... etc?
Changes are in D9838
I mean missing parts in efl.ui.internal.interactivetext
Sep 5 2019
@woohyun These are main parts needs port from entry_edje:
- Preedit Functinality (Missing Parts)
- Anchor Functinality (Missing Parts)
- SELECTION_CLEARED events (replace some of SELECTION_CHANGED)
- Port missing Keyboard handling functionality
- Undo/Redo (I think there should be way to trigger them by code)
- Filters --This needs new design logic
- Cursor down/up --This needs new design logic
Sep 4 2019
We collected features we could not find in :
Comparing Legacy to new Design we could not find following functionality:
How user can do text selection by code using new design (Raw_Edit)?
can we make efl2_text_attribute_factory_ref/unref return same passed pointer instead of void ?
@tasn Please take look when you have time
How about create subtask for main topics to discuss
And in Each task we will create subtask for issues regard main topic.
this make it more easy to review and disucss than keep adding comments and scrolling up/down
Where do you like to add comments: here or in Git ?
Like documentation issue, missing functionality compare to legacy, .. etc.
Regard this task
Should we make our start point :
Sep 3 2019
At this stage
For example We will replace events like _edje_emit("selection,cleared") with efl_event_callback_call(EFL2_TEXT_RAW_EDITABLE_SELECTION_CLEARED), right ?
I will create github repo.
I think the first step would be to anyway move edje_entry to its own objec
Do you mean EO object ?
This is repo for the examples :
I think we can reuse the code in efl.ui.internal.interactive, and move the remaining from edje_entry into Efl.Text.Raw_Editable
Sep 2 2019
1- Regard performance and memory, I think real test with heavy use on Text Widget can convince both of us, I hope we can find time to do it before release.
This is orthogonal to this issue. This needs to be done regardless if you change it as you suggested or not.
I like your idea, I will try to find better way so you can add your comments
This example about spell check (it is very bad Sorry), lets use it as starting point (comments start with //ali.m points about challenge I had)
Note Please forget about memory leak at this point
By lightweight I mean:
1- Less memory, it is not required to store extra information about selection/interactive/ .. etc.
2- Less internal processing
a - Less checks (isSelectable,isEditable)) for example when widget is clicked b - In label for example when you set content, you do not need to reset selection/interactive/ ...etc
3- Less initialization processing/time
If we replace all edje_entry functionality to be in Efl2.Text.Raw_Editable, it will make Raw_Editable feature rich object. (it is ok when used with efl.ui.text).