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
