Post by Andrew WilliamsHi,
Apologies I did not realise it was a question that needed answering. As I
moved in to discuss if we are worrying about text manipulation in our
widgets then we probably have bigger issues around separation of concerns.
Our text handling apis should worry about that - and the widget have a
simple way to bind to a text model or have the resulting text set.
it's part of the concerns. if you want to drop markup entirely then you're
going to REALLY annoy a lot of people used to inlining their metadata. dave is
the counter example i am pointing at (and i bet you there are many more like
him).
i remember at e dev day we specifically skipped popularity with "we have no
info on what people prefer and are not doing some popularity poll here" or
words to that effect. so the jury is still out on what people actually prefer.
i know what you prefer. i have heard what some others prefer. if its 55v45 in
favour of plain text + api's to define format regions/nodes i still say "stick
to markup as it will make a transition easier". if it's 80v20 in favour of
plain then move, but you need some way to provide inlined format handling to
express a string of text WITH formatting embedded (ie markup). what you are
presenting is a fait accompli that has clearly said "ignoring the data
- making this decision anyway".
and to do that then you would need to provide api's that set/get (and otherwise
manipulate and query) that do both markup versions AND plain text versions
given your design. the way we do it now is when going from markup (all data
there) to plain - we just drop all the markup on the floor and convert a very
tags (<br> for example) and vice-versa.
when your metadata is out-of-band like proposed you have to now have markup
versions of every plain text api version on anything because dealing with
formatting requires more calls to go query the formatting info separately to
the text and it can't just be done in a "simple wrapper that converts a
string" because you are not just stripping out data from a full data set, but
having to do multiple api's to query and rebuild it and vice-versa. the
proposal for strings is to make them very very very dumb (plain text) by
default and that is highly problematic from a technical point of view.
popularity is totally unknown at this point, so just assuming its 50v50,
choosing the path with far more technical issues at the api level is a bad
choice, and plain text is just that.
you can't separate out the choice of markup or not from designing the api.
doing markup by default is "we choose to lose NO information by default and
have all of it there and provide you with helpers to drop info not needed or
used". choosing plain text by default is "we already lost all the info - you
have to add it back with more api's by querying or providing it". if you
provide markup versions of every text api then this would be dealt with BUT it
leads to doubling up of every text api that manipulates or queries a string and
that is not exactly wonderful. unlike markup by default, you can't just provide
a simple "degrade it to plain text" helper (or promote to markup) like we do
now. you have to have the full set doubled up.
Post by Andrew WilliamsI appreciate that people have not had issues with the way it is, but I
don't think that is reason enough to dismiss the issues that are reported
or the confusion created... (I reference back to user enters 2>3 but
and removing markup by default creates other problems which i am pointing out
because it downgrades the information passed in and out BY DEFAULT (plain text
is downgraded vs markup). you will have issues EITHER way. plain text is not
magically so much better than markup. it switches a different base assumption
on the text encoding (text is always encoded. UTF-8 plain text where \n means
go down 1 line and move cursor to left (or right) edge, char values > 127 e.g.
even for latin-1 are encoded with multiple byte sequences ala UTF-8 ... it's
ALWAYS encoded). markup is just an extended form of encoding on top of this.
and functions/helpers were provided to do this conversion. it's not being
dismissed. far from it - it was already envisaged and addressed. maybe the
helpers could now use eina_slstr to avoid needing to free strings afterwards...
but my point is that if the DEFAULT api were to be lossy (plain text) then you
create a huge amount of problems. if it were markup then you'd have far fewer
problems and just need the kind of convert funcs as we already have. that or
having to provide markup duplicates api's for every string get/set/insert/fetch
substring etc. and from api size/complexity duplicating is generally a bad path
to go down.
and ALL of this discussion at the technical api level hasn't even got the info
on what people prefer to be the default. to get a good feel for this... you
NEED to give them some options on what to choose and thus design api's to
handle all cases and propose something and see that it actually can handle
them... then find out what people think then about it - the kinds of users who
use the api regularly... THEN make a decision on what should be done. well if
you are planning on changing something AND the change is controversial (which
it seemingly is).
Post by Andrew WilliamsEncoding of text is not something that a widget should have to deal with
and decoding is not something that a cost char* text_get api implies.
the documentation clearly says otherwise. if it makes you feel better we could:
typedef Elm_Markup char;
Elm_Markup *elm_object_text_get(Evas_object *obj);
though it'd be a lie because some widgets dont do markup... but entry and label
do ... (and some parts in a layout do do markup if TEXTBLOCK and some don't if
TEXT).
we ALL agree that inconsistency is bad and this should be fixed.
Post by Andrew WilliamsAndy
Post by Andrew WilliamsPost by Andrew WilliamsHi,
I jumped back to this email I sent a week ago and realised that we have
just spent a bunch of time revisiting a discussion that had clearly
wrapped
Post by Andrew Williamsup at the EDD in Malta. One reason I wanted to post our conclusion to the
list was for visibility and a chance to comment for anyone who was not
able
Post by Andrew Williamsto attend. Unfortunately instead we have had a lot of the same points
brought forward that were already discussed at the event which has led to
confusion and time wasting.
There is a question in here about general API design that I will start
in a
Post by Andrew Williamsnew thread but i want to wrap up this discussion. Is there anyone on this
list (except raster as Tizen developer proxy) who disagrees with the
approach as was laid out in my email of the 29th?
do we will have a markup variant for every text operation? (text_set,
text_append, text_insert...etc).
To be honest I never had any issue with the current always-markup model,
so for now I vote for keeping the legacy behavior also on the new EO api.
Post by Andrew WilliamsI understand that this could be conceived as a massive change but my
understanding was that the Eo API was a chance to fix things up to be
better going forward and not to be shackled by our choices of the past.
If
Post by Andrew Williamsthat is not true then we will really struggle to make quality bindings to
higher level languages (in this context the difference between plain text
and markedup/parameterised text and also the tight coupling of text
handling and the rendering).
Thanks
Andy
Post by Andrew WilliamsHi,
* no-one is proposing that we remove the ability to mark up text
through
Post by Andrew WilliamsPost by Andrew Williamsthe markup format mechanism, it is a great feature
* we cannot make changes to this legacy API as apps depend on it or
have
Post by Andrew WilliamsPost by Andrew Williamsadapted to it
* the new textblock API, which is currently plain text only is being
extended with a solid markup API
* The existing markup format will be supported through _markup_text_set
or
Post by Andrew Williamssimilar API leaving text_set/get to be plain text only
It was beileved that this would satisfy all requirements whilst
removing
Post by Andrew WilliamsPost by Andrew Williamsany confusion about the nature of text encoding when using plain text.
This allows us to take a path-of-least-surprise approach for the new Eo
based text APIs
Thanks everyone for the discussion :)
Andy
On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
Post by Daniel HirtHi,
On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams <
Post by Andrew WilliamsHi,
Looking at the tests you point me at - selection (and the past)
is
will
Post by Andrew WilliamsPost by Andrew Williamsnot
Post by Daniel Hirtget
Post by Andrew Williamsyou there - there is no built in interpretation of formatting -
just
Post by Andrew WilliamsPost by Daniel HirtPost by Andrew Williamsrendered understands it.
"elm_entry_selection_get" returns the text in markup format. The
test
Post by Andrew WilliamsPost by Daniel Hirtprints
both types one after another (markup followed by plaintext) using
"elm_entry_markup_to_utf8".
It is essential for copy & paste of markup text between two entry
clients,
Post by Daniel Hirtso the pasted formatting is kept.
Post by Andrew WilliamsOverall the implementation feels wrong - supporting markup is
great
internal
Post by Andrew WilliamsPost by Andrew WilliamsPost by Daniel Hirtchoices
Post by Andrew Williamson other devs.
I note that the code considers format but only when interacting
with
Post by Andrew WilliamsPost by Daniel Hirtfiles
Post by Andrew Williams- so I can have plain text files but not plain text input.
Right, it's a feature so you can load plain files. You specify the
format
Post by Daniel Hirtyou
want to load (plaintext or markup). But, after the file is loaded,
it's
Post by Daniel Hirtdiscarded.
It's important to point out that because there's an actual
representation
Post by Daniel Hirt(markup), it's costly to store both plaintext and markup content
in
Post by Andrew WilliamsPost by Andrew Williamsthe
Post by Daniel Hirtobject.
Asking you to convert using "markup_to_utf8" is understandable, as
it
Post by Andrew Williamswhat
Post by Daniel Hirtwe would actually do internally if we were to add API to get the
text
Post by Andrew Williamsin
Post by Daniel Hirtplaintext. It's only one function call away, and it's easier than
just add
Post by Daniel Hirtmore
API to the widget. No need for a new function if there's a way to
do
it
text
Post by Andrew WilliamsPost by Andrew Williamswill
Post by Daniel Hirtbe
Post by Andrew Williamstransformed after text_set. If it were then it should be
symmetrically
Post by Daniel HirtPost by Andrew Williamstransformed back on text_get - path of least surprise.
Actually, it is not transformed on "text_set". You are expected to
enter a
Post by Daniel Hirtmarkup-compatible text. Otherwise you will have the mentioned
special
Post by Andrew WilliamsPost by Daniel Hirtcharacters (like "<") misinterpreted as markup. You can try with
"elm_object_text_set" on an entry widget.
Post by Andrew WilliamsI don't quite understand why we would build formatting in as
mandatory,
Post by Daniel HirtPost by Andrew Williamsfunctionality is great but it should be possible to turn it off.
I agree that people complain when markup is not supported in a
widget but
Post by Daniel HirtPost by Andrew Williamsthat is the expectation we have set - consistency is very
important
Post by Andrew WilliamsPost by Andrew WilliamsPost by Daniel Hirtindeed
Post by Andrew Williamsand I think we don't have it in this regard.
Additionally I think the markup_to_utf8 methods are peculiarly
named
Post by Andrew Williams-
Post by Daniel Hirtthey
Post by Andrew Williamsdo no character encoding so the usage of utf8 is probably
incorrect...
Post by Daniel HirtThey're correct. UTF-8 is the standard plaintext encoding. We
support
Post by Andrew WilliamsPost by Daniel HirtUTF-8,
and provide converters for your convenience. You probably won't
need
Post by Andrew WilliamsPost by Andrew Williamsthose
Post by Daniel Hirtmost
of the time.
Your plaintext is always "encoded", but you probably won't notice
that
Post by Andrew WilliamsPost by Daniel Hirtbecause
it's backward-compatible with US ASCII (1-byte per character).
Lastly, I would like to mention "Efl.Ui.Text" - this new widget
is a
Post by Andrew WilliamsPost by Andrew Williamspart
Post by Daniel Hirtof a
rework of the Textblock object. It's in BETA stage.
It does what you require: all text input is expected to be
plaintext.
Post by Andrew WilliamsPost by Daniel HirtThere's no
"markup" logic in it. Instead, you format your text by setting
ranges
Post by Andrew Williamsand
Post by Daniel Hirtcalling
functions to apply formatting. Again, markup does not exist in
this
Post by Andrew WilliamsPost by Andrew WilliamsPost by Daniel Hirtobject,
What? no more markup support? This is really, really sad to hear :(
i've ben trying to tell people that markup is LESS bad than no markup
(or
Post by Andrew Williamshaving to do it via api calls)... but the people giving the opinions
on
Post by Andrew WilliamsPost by Andrew Williamsthis
aren't writing the apps.
maybe you c an convince them.
Post by Daniel HirtI'm using markup everywhere in my media center and I'm really happy
with
Post by Andrew Williamstoo bad. plain text for you unless you call lots of api calls to
insert
Post by Andrew WilliamsPost by Andrew Williamsit tag
by tag. have fun.
Post by Daniel Hirthttp://www.enlightenment.org/ss/e-594d67c3ee4752.10999768.jpg
Look at the the textblock in the lower-right corner,
text = sprintf("<title>%s</> <small>%s</small><br>"
"<small><name>%s</> %s <name>/ %s %s</><br>"
"<views>%s %s</> <name>/</> "
"<likes>%s %s</> <name>/</> "
"<comments>%s %s</></small><br>%s",
video.name, video.duration,
_('user'), video.user,
_('uploaded'), relative_date(video.created_time),
views, ngettext('view', 'views', views),
likes, ngettext('like', 'likes', likes),
comments, ngettext('comment', 'comments', comments),
video.description)
..thats it, and I have those beautiful (theme-able!) formatted text.
Now try to think at the code needed to do the same with the "new"
API
Post by Andrew Williams!!
Post by Andrew WilliamsPost by Daniel HirtAnother insurmountable problem of the API approach: the text in my
example
Post by Daniel Hirtcomes from plugins (the vimeo plugin in this case) that are separate
processes
from the core mediacenter, plugins just fetch datas from the net and
pass
Post by Daniel Hirtthem back to the core. This means that the plugins do not have
access
Post by Andrew WilliamsPost by Andrew Williamsto the
Post by Daniel Hirttextblock API.
https://github.com/DaveMDS/epymc/wiki/Screenshots
I can understand the initial issue Andrew was speaking in this
thread
Post by Andrew WilliamsPost by Andrew WilliamsPost by Daniel Hirt(text_get
is difficult to use). And I agree that the default behavior should
be
text_markup_set(...)
Post by Andrew WilliamsPost by Andrew WilliamsPost by Daniel HirtTo be more clear: loosing the markup ability (in textblock, buttons,
and
Post by Andrew WilliamsPost by Daniel Hirtany other widget) is a shame, we are loosing IMO the most powerful
and
Post by Andrew WilliamsPost by Andrew WilliamsPost by Daniel Hirtuseful
feature of textblock in efl.
can be re-added as a module in later stages.
Please, please, please re-added it now, otherwise I will not be able
to
Post by Andrew WilliamsPost by Daniel Hirtport my
applications to the new API, until a "later stage" will eventually
occur.
Post by Daniel HirtYou can check its current state in "efl ui text" test in
elementary_test.
Post by Daniel HirtFeedback
will be very much appreciated.
Hope this answers a few of your questions.
Best,
--
Danny (herdsman) Hirt
------------------------------------------------------------
------------------
Post by Andrew WilliamsPost by Daniel HirtCheck out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------
------------------
Post by Andrew WilliamsPost by Daniel HirtCheck out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am"
--------------
Post by Andrew WilliamsPost by Andrew Williams------------------------------------------------------------
------------------
Post by Andrew WilliamsCheck out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
http://andywilliams.me
http://ajwillia.ms
--
http://andywilliams.me
http://ajwillia.ms
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
http://andywilliams.me
http://ajwillia.ms
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ***@rasterman.com
