2017-06-30 1:37 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > 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. >
or something like "markup_mode_enabled" that you can set on the widget to enable/disable markup insert of text. > > > 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 > ------------------------------------------------------------------------------ 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
