As I'm on the move I have no decent email app so I can't interleave with your replies so it's all up-top:
First time: Maybe not on ML but this has been discussed before on IRC, but that does not exactly make angood source of documentation for issues or api confusion. UTF8: we are in agreement here, I think you misread my comment - I was saying this complication is introduced by unicode so the markup does not add that complexity. Tizen: maybe this is the crux of the issue. I do not see Tizen developers coming to the efl community to feed back on any of this so we don't have good visibility. Are you therefore the champion for everything going on over there that we need to take on? It's kind of tricky to be spending lots of time building apps on our apis and yet find that invisible users of the api carry substantially more influence. The thing I get most from your email is that, as we decided to do markup by default in current apis, it is unwise to ever change it. If we will always be constrained by historical apis then why not just make an edict that the eo api must be a direct mirror of the legacy for compatibility reasons?... Andy On Sun, 2 Jul 2017 at 10:53, Carsten Haitzler <ras...@rasterman.com> wrote: > 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 > > -- 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
