2017-07-01 4:28 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > 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). >
I was supposing the developer to set the mode right after object creation and then stay with that, ex: lb = elm_label_add(...) elm_text_mode_set(lb, MARKUP) and then always use markup in your code for that widget, Isn't this the 99% of the usage case? > > 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
