Page MenuHomePhabricator

efl.ui.textbox: clean text box from unused interfaces implementation (FILE interface)
AbandonedPublic

Authored by ali.alzyod on Tue, Jan 7, 6:41 AM.

Details

Summary

remove Efl.File interface, currently it loads plaintext. no way to specify the file format. This better to be added later (If it make sense to add it), also we need to give user the option to load specific format, second: this can be done externally by user

Diff Detail

Repository
rEFL core/efl
Branch
arcpatch-D11043
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 15295
Build 10535: arc lint + arc unit
ali.alzyod created this revision.Tue, Jan 7, 6:41 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

ali.alzyod requested review of this revision.Tue, Jan 7, 6:41 AM

Why are these interfaces being removed? I see a lot of code there... @woohyun, is Access not needed anymore?

ali.alzyod updated this revision to Diff 27998.Tue, Jan 7, 7:30 AM

remove file interface too

ali.alzyod edited the summary of this revision. (Show Details)Tue, Jan 7, 7:32 AM
bu5hm4n requested changes to this revision.Wed, Jan 8, 1:15 AM

Again, Why ?

This revision now requires changes to proceed.Wed, Jan 8, 1:15 AM

@segfaultxavi
Later, all the access classes would be modified, so I thought deleting current implementation would not be a problem.
But, as a history keeping for later implementation, I never object to not remove them from current codes.

@ali.alzyod
How do you think about my opinion ?

ali.alzyod added a comment.EditedWed, Jan 8, 1:59 AM

@ali.alzyod
How do you think about my opinion ?

I am totally fine with it, as long as I do not get complains about them from reviewers to fix it :))

I will remove FileInterface implementation only and keep the access interfaces

@woohyun, out of curiosity, what are the plans for Access? Is there anybody working on it?

ali.alzyod updated this revision to Diff 28045.Thu, Jan 9, 3:27 AM

file only interfaces

ali.alzyod edited the summary of this revision. (Show Details)Thu, Jan 9, 3:27 AM
ali.alzyod retitled this revision from efl.ui.textbox: clean text box from unused interfaces implementation to efl.ui.textbox: clean text box from unused interfaces implementation (FILE interface).Thu, Jan 9, 3:27 AM

This looks good for me now :)
Another opinion ?

I still don't know why you're removing the File interface from Textbox.
I never liked this feature very much, but it was already there, so I guess somebody liked it.
Did anybody ask for this removal?

@segfaultxavi

I still don't know why you're removing the File interface from Textbox.
I never liked this feature very much, but it was already there, so I guess somebody liked it.
Did anybody ask for this removal?

It's there becuase legacy elm_entry has it.
That is, all the features of efl_ui_textblox were C&P from elm_entry without any cleanup.

I think it can be applied later to a class which extends this efl_ui_textbox (if there is request for this feature).
The feature (in elm_entry) has rarely been used (honestly never be used in Tizen).
So, I agree to remove this feature from this "default text ui class".

Just for the record, I think that feature is in use in Ecrire, Edi and Enlightenment.
These apps will have to work a bit more to be ported to the Unified interface if we drop this feature.
But OK, we can do it later.

To be honest, i would either like to see something replacing this feature. But never just removing it ... The listing of Apps that use this stuff is showing quite a bit that we have a rather big community interest for this.

ali.alzyod added a comment.EditedSat, Jan 11, 11:33 PM

We want to remove this interface because it has a lot of problem in implementation, And I think this can be added later, from user side setting content of File in UI.TextBox should be a simple task and saving the content into file is also a simple task.
I think we need to rethink about this interface support in UI.TextBox before stabilization (It will be hard to remove it then). -- I mean after stabilize this class we can add file support in next version, after giving it more thinking

For example:
1- Is it a must feature for stabilization. (I do not think it is important to be supported internally)
2- We do not have Document file support (like reading Doc, Docx, rtf,) and this feature can be confusing that we support reading document files.
3- Now we can either read files as Plain-Text or EFL-Markup, And currently there are no way to detect file format(no headers for these files), So we need to pass the format along with file save and load, which means: (Do we need to extend the interface, or add properties inside UI.TextBox).

So I think give it more time of rethinking is better than adding it now.

But then better create some placeholder API that just does that (maybe not on efl.ui.textbox). I really have a bad feeling just removing a feature, better stick it in a other place where we can refactor it later on.

ali.alzyod abandoned this revision.Thu, Jan 16, 1:44 AM