On Sat, 01 Jul 2017 06:37:03 +0000 Andrew Williams <a...@andywilliams.me> said:
> Hi, > > This is not the first time this has come up (just search phab for "HTML" or > "encoding") and given that we agreed we don't have many app developers it > seems dismissive to state it's not a problem as we've had no complains from > app developers... first time it has come up on mailing lists or irc (as a question/disatisfaction). there are are probably several times more developers using it in tizen... and i have never heard a complaint out of them about it.\ i have seen many spreadsheets with complaints on efl from tizen base devs. never was markup one of them. it's not dismissive. it's me saying that you lack a perspective i do. you think this move would be an improvement yet you have never seen what i have ... and i have a deep worry that what goes from no complaints suddenly becomes "what i used to be able to use markup.. now i can't? how do i make my text bold now?" "oh you have to sue the markup versions of all the text interfaces" "what? i didn't see that. why did you not make it default like before?". ... i think YOU are begin dismissive of this scenario. we go from no complaints there to lots of them. > Markup vs text does not introduce cursor problems that otherwise are simple > - just supporting UTF8 means you can't make assumptions about cursor vs > text offset. Additionally that should only be a concern for entry which is > a very small subset of the text engine responsibilities. you can't make it WITH utf-8/unicode. read up the unicode standards and check with composite characters (รด == o + ^ unicode chars beside eachother for example... there's far more complex ones for various languages - i'm not talking input here... text strings). it's impossible to make an assumption that 1 utf8 char or even 1 unicdoe codepoint == 1 visible on screen character. it's impossible. if you go forward with this assumption you'll be bitterly disappointed. it's an issue that has to be handled anyway. > In terms of complexity or api confusion I return to the path of least > surprise. Text apis should not unexpectedly encode content such that input > != output. Splitting the data from the metadata or making the setting of see above. > marked up text explicit avoids this confusion. For inspiration I point you it does not. > to the iOS APIs where they have "attributedString" (get/set etc) which is > different to the plain text methods. Additionally they avoid the > insert/replace issues by pushing those features into the string handling > rather than the widget which makes a lot of sense now I think about it. > > Thanks, > Andy > On Sat, 1 Jul 2017 at 03:33, Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli <d...@gurumeditation.it > > > > > said: > > > > > 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. > > > > actually this would be worse. any code calling an api to get or manipulate > > text > > needs to also always query mode first (maybe change it, then change it > > back)... > > so now instead of > > > > text_set(obj, "Blah"); > > > > you have > > > > prev_mode = text_mode_get(obj); > > text_mode_set(obj, PLAIN); > > text_set(obj, "Blah"); > > text_mode_set(obj, prev_mode); > > > > we could make it a push and pop... just to cut this down so it goes from 4 > > ro 3 > > lines... but still./.. not great (and the implementation actually needs to > > keep > > a real stack then not a counter). > > > > not knowing how your text is interpreted at all is very bad. you need to > > know. > > if there is only one way then there is no problem. if we were going to have > > lots of text modes (plain, markup, full html, rtf, ...) then maybe we'd > > have to > > live with the above mode thing as the api's would multiply like crazy... > > the > > alternative is we must pass format every time WITH the text > > > > text_set(obj, PLAIN, "Blah"); > > > > everyone is probably going to hate this too. we could make use of > > "non-visible" > > ascii chars as format markers like magic numbers for file formats... > > > > #define PLAIN "" > > #define MARKUP "\001\001" > > #define HTML "\001\002" > > #define RTF "\001\003" > > > > etc. and we literally require you decode the header... (many values of the > > first 32 ascii values other than \000 could be used for this as they can > > never > > be visibly displayed or mapped to a glyph and make zero sense to use so we > > can > > use them as control chars like \n, \t and \r (\012, \011 \015) are format > > control chars and not directly mappable to a visible glyph on their own). > > so > > now you do: > > > > text_set(obj, "Blah"); > > text_set(obj, MARKUP"<b>Blah</b>"); > > > > etc. but people will probably dislike this too... no matter how you slice > > or > > dice this, people will hate something. so make take is, you either do plain > > text and give up on markup entirely other than having to use a whole bunch > > of > > metadata api's to apply it (that's going to be **FUN** on inserts ... - > > not), > > make wrappers that parse markup for you then do these (which means markup > > versions of every query, set, insert, append etc.) and the implementation > > is > > going to be "fun" (what is a cursor pos? a char pos #, a utf8 byte value > > offset? enjoy the figuring out of this as its likely going to be a visible > > glyph/char pos) ... > > > > or you just bite the bullet and say "it's all markup. DEAL WITH IT" (and > > provide some converters). only people i have heard complain are efl people > > and > > only now after many many many years who oddly didn't even read our own > > docs and > > find out it's markup... everyone else seems to be fine with it and expects > > markup... > > > > anecdotal statistics tells me that removing the "markup by default" is > > going to > > be a big mistake... > > > > > > > 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 > > > > > > > > > -- > > ------------- 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
