On Thu, 29 Jun 2017 11:13:51 +0000 Andrew Williams <a...@andywilliams.me> said:
> 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 you have to have a markup version of everything. set, append, prepend, insert, replace etc. > 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 > ------------------------------------------------------------------------------ > 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
