On Wed, 5 Jul 2017 09:14:02 +0300 Daniel Hirt <hirt.da...@gmail.com> said:

> 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 <a...@andywilliams.me>
> > 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?

that was my point way way way up in the thread. if you want to do this way you
need plain text AND markup versions of every api that deals with text on a
window.

text_get()
text_cursor_range_get()
text_set()
text_cursor_range_replace()
text_cursor_prepend()
text_cursor_append()
text_prepend()
text_append()

for example. now you need a markup version of every one of these:

markup_get()
markup_cursor_range_get()
markup_set()
markup_cursor_range_replace()
markup_cursor_prepend()
markup_cursor_append()
markup_prepend()
markup_append()

having 2x the api's to do this isn't nice either. the default not doing markup
also is likely to cause issues as i have mentioned... there will be
expectations of it doing markup when it now doesn't. the happy existing users
of the api for example.

> 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 <ras...@rasterman.com> wrote:
> >>
> >>> On Tue, 04 Jul 2017 18:50:34 +0000 Andrew Williams <a...@andywilliams.me>
> >>> 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&gt;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 <d...@gurumeditation.it>
> >>> wrote:
> >>>>> 2017-07-04 14:22 GMT+02:00 Andrew Williams <a...@andywilliams.me>:
> >>>>>
> >>>>>> 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 <a...@andywilliams.me>
> >>>>>> 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 <
> >>> ras...@rasterman.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
> >>>>>>>> d...@gurumeditation.it>
> >>>>>>>> said:
> >>>>>>>>
> >>>>>>>>> 2017-06-19 13:36 GMT+02:00 Daniel Hirt <hirt.da...@gmail.com>:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams <
> >>>>>>>> a...@andywilliams.me>
> >>>>>>>>>> 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
> >>>>>>>>>> enlightenment-devel@lists.sourceforge.net
> >>>>>>>>>>
> >>> 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
> >>>>>>>>> enlightenment-devel@lists.sourceforge.net
> >>>>>>>>>
> >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> ------------- Codito, ergo sum - "I code, therefore I am"
> >>>>> --------------
> >>>>>>>> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ------------------------------------------------------------
> >>>>>> ------------------
> >>>>>>>> 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
> >>>>>>>> enlightenment-devel@lists.sourceforge.net
> >>>>>>>> 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
> >>>>>> enlightenment-devel@lists.sourceforge.net
> >>>>>> 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
> >>>>> enlightenment-devel@lists.sourceforge.net
> >>>>> 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
> >>>> enlightenment-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>>>
> >>>
> >>> --
> >>> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> >>> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> >>>
> >>> --
> >> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to