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.
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) 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. 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
