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
