Hello all,
On 07/05/2017 08:48 AM, Carsten Haitzler (The Rasterman) wrote:
On Wed, 05 Jul 2017 03:26:09 +0000 Andrew Williams <[email protected]> said:
Hi,
Unfortunately I don't have time to reply to all of these thoughts right now
but I wanted to reply to the first one before any more replies arrive. I am
not (and nether is anyone else) suggesting that we remove markup support.
Please stop implying that.
i have clearly listed options on how to do it as an api. ONE of those options
is no markup in text_set etc. and HELPERS indstead that would convert from
makrup to plain text PLUS call the metadata api's to set metadata correctly.
you double up on your api's and the markup ones are built on top of the plain
text + metadata ones. i have been VERY clear on that. i have been EXPLICITLY
discussing the problems with this path.
you could implement both WITHOUT the markup being wrappers (and now have to
support both as native internal paths). from an api view it loosk the same,
internally it look different.
There are benefits when going for the "wrappers" approach:
1. You offload the parsing logic to another source (as it should, it has
little to do with the current implementation of formats/annotations).
2. You don't repeat your logic - less to maintain. By making things use
"annotation" API, whether you want to use a markup or just the
annotation API, you maintain only the annotation code (in most cases, as
markup logic is only a wrapper).
an options was dave's "set a mode (markup or plain)"" method which cuts down
our api's again to something nice BUT means we always have to switch to a
specific mode then back to where it was each time.
I would rather not do that. Setting "modes" is kind of unpleasant.
other methods were provide text format as a parameter with the string, provide
it as special chars at the start of the string as a format header, and you
propose having special string objects vaguely (i havent gotten something clear
on it yet), and i think this is probably worse as you have to create string
object from markup string, then set/provide string object to label/entry
object, and the reverse (to get text, get string obj, then get string from
string obj etc.). this double-object thing IMHO would make the api even worse
to use than any of the other options.
imho the simplest option is pick one encoding only and provide converters like:
obj.text_set(to_markup("Hello\nWorld"));
text = to_plain(obj.text_get());
ALL you need to know is it's markup by default. this means all the string query
and manipulation funcs only need a single markup version at the api since you
lose no information.
Not all usages of text require markup. SOME (even a lot) want it, but
not all.
The question is: can we allow having two different interpretations for
"Efl.Text.text" property?
My answer is "no". We should stick to it being a plain text.
Also my email was about api and not about internal storage. If you want to
handle everything internally in some encoded form fine - just don't push
that choice on users of what looks like a text api. Supporting both plain
text and markuped text models does not mean lowest common denominator
internally.
i am not talking about internal encoding at all. ONLY talking about api. i was
saying that IF the "native model" for api is not markup (all data inline in the
blob of text) and has to be dealt with by various api's defining content then
defining format ranges (char 13 to 67 is "bold", at char 16 insert image item
"bob.jpg", etc. for example). then the markup api's will be build AROUND this
and that makes them complex internally. you also double up on your api's -
having markup versions for every plain text version. this is not a great thing.
this morning i just personally spoke to 2 developers in the office and the BOTH
were: "markup is great. we like it. everyone i know of liked it and had no
issues with elm_entry being markup by default - they liked it". these
people have interacted with dozens of developers using these api's... their
experience is the polar opposite of yours. they had zero issues in dealing with
markup by default. i'm warning - change defaults and a silent happy large group
become noisy and unhappy.
Markup is staying. The developer will just need to use
"efl_text_markup_set/insert", instead.
Using a different name shouldn't upset anyone, unless I am missing
something?
Also, I am writing the "Efl.Markup" mixin, that will use the annotation
API, right now.
Just letting you know.
-- herdsman.
before jumping into "the decision is made, but we have no numbers on what is
popular" ... get some data on that first. i suspect you may be surprised at how
many people find markup simple, obvious and easy to deal with. it keeps our api
implementation simpler and api size smaller.
I'll get to the rest later, apologies for the partial reply)
Andy
On Tue, 4 Jul 2017 at 20:29, Carsten Haitzler <[email protected]> wrote:
On Tue, 04 Jul 2017 18:50:34 +0000 Andrew Williams <[email protected]>
said:
Hi,
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.
I 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
text_get returns 2>3)
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).
Encoding 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.
Andy
On Tue, 4 Jul 2017 at 13:23, Davide Andreoli <[email protected]>
wrote:
2017-07-04 14:22 GMT+02:00 Andrew Williams <[email protected]>:
Hi,
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
up 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
to 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
new 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?
you still did not reply to the first raster's question:
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.
I 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
that 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
On Thu, 29 Jun 2017 at 07:13, Andrew Williams <[email protected]>
wrote:
Hi,
Just to wrap this thread up following EDD:
* no-one is proposing that we remove the ability to mark up text
through
the markup format mechanism, it is a great feature
* we cannot make changes to this legacy API as apps depend on it or
have
adapted 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
similar API leaving text_set/get to be plain text only
It was beileved that this would satisfy all requirements whilst
removing
any 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 Sat, 24 Jun 2017 at 05:39 Carsten Haitzler <
[email protected]>
wrote:
On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
[email protected]>
said:
2017-06-19 13:36 GMT+02:00 Daniel Hirt <[email protected]>:
Hi,
On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams <
[email protected]>
wrote:
Hi,
Looking at the tests you point me at - selection (and the
past)
is
a
plain
text copy with the markup stripped - exactly what I would
expect
for
text_get - but the current content transformed with the
helper
will
not
get
you there - there is no built in interpretation of
formatting -
just
rendered understands it.
"elm_entry_selection_get" returns the text in markup format.
The
test
prints
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,
so the pasted formatting is kept.
Overall the implementation feels wrong - supporting markup is
great
but
returning it inline in text_get feels like we are imposing
internal
choices
on other devs.
I note that the code considers format but only when
interacting
with
files
- 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
you
want to load (plaintext or markup). But, after the file is
loaded,
it's
discarded.
It's important to point out that because there's an actual
representation
(markup), it's costly to store both plaintext and markup
content
in
the
object.
Asking you to convert using "markup_to_utf8" is
understandable, as
it
what
we would actually do internally if we were to add API to get
the
text
in
plaintext. It's only one function call away, and it's easier
than
just add
more
API to the widget. No need for a new function if there's a
way to
do
this
already.
Lastly the documentation clearly discussed markup capability
but
it
*never*
discusses encoding and there is no explicit mention that your
text
will
be
transformed after text_set. If it were then it should be
symmetrically
transformed back on text_get - path of least surprise.
Actually, it is not transformed on "text_set". You are
expected to
enter a
markup-compatible text. Otherwise you will have the mentioned
special
characters (like "<") misinterpreted as markup. You can try
with
"elm_object_text_set" on an entry widget.
I don't quite understand why we would build formatting in as
mandatory,
functionality 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
that is the expectation we have set - consistency is very
important
indeed
and I think we don't have it in this regard.
Additionally I think the markup_to_utf8 methods are
peculiarly
named
-
they
do no character encoding so the usage of utf8 is probably
incorrect...
They're correct. UTF-8 is the standard plaintext encoding. We
support
UTF-8,
and provide converters for your convenience. You probably
won't
need
those
most
of the time.
Your plaintext is always "encoded", but you probably won't
notice
that
because
it's backward-compatible with US ASCII (1-byte per character).
Andrew
Lastly, I would like to mention "Efl.Ui.Text" - this new
widget
is a
part
of a
rework of the Textblock object. It's in BETA stage.
It does what you require: all text input is expected to be
plaintext.
There's no
"markup" logic in it. Instead, you format your text by setting
ranges
and
calling
functions to apply formatting. Again, markup does not exist in
this
object,
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
having to do it via api calls)... but the people giving the
opinions
on
this
aren't writing the apps.
maybe you c an convince them.
I'm using markup everywhere in my media center and I'm really
happy
with
it's usage.
too bad. plain text for you unless you call lots of api calls to
insert
it tag
by tag. have fun.
Please think carefully at my use case:
http://www.enlightenment.org/ss/e-594d67c3ee4752.10999768.jpg
Look at the the textblock in the lower-right corner,
the code to set the text is something like this:
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
!!
Another insurmountable problem of the API approach: the text in
my
example
comes 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
them back to the core. This means that the plugins do not have
access
to the
textblock API.
Some more examples:
https://github.com/DaveMDS/epymc/wiki/Screenshots
I can understand the initial issue Andrew was speaking in this
thread
(text_get
is difficult to use). And I agree that the default behavior
should
be
plain
text set/get,
BUT: we really need to implement something like:
text_markup_set(...)
To be more clear: loosing the markup ability (in textblock,
buttons,
and
any other widget) is a shame, we are loosing IMO the most
powerful
and
useful
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
port my
applications to the new API, until a "later stage" will
eventually
occur.
You can check its current state in "efl ui text" test in
elementary_test.
Feedback
will be very much appreciated.
Hope this answers a few of your questions.
Best,
--
Danny (herdsman) Hirt
------------------------------------------------------------
------------------
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am"
--------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------
------------------
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
