Hi, Whilst more API may seem counterintuitive I am a proponent of each method does 1 thing well. Therefore if we want to handle markup and handle plain text then a 2* API count actually makes sense.
Andy On Mon, 17 Jul 2017 at 08:33 Carsten Haitzler <[email protected]> wrote: > On Wed, 5 Jul 2017 09:14:02 +0300 Daniel Hirt <[email protected]> said: > > > Hello all, > > > > > > On 07/05/2017 08:48 AM, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 05 Jul 2017 03:26:09 +0000 Andrew Williams < > [email protected]> > > > said: > > > > > >> Hi, > > >> > > >> Unfortunately I don't have time to reply to all of these thoughts > right now > > >> but I wanted to reply to the first one before any more replies > arrive. I am > > >> not (and nether is anyone else) suggesting that we remove markup > support. > > >> Please stop implying that. > > > i have clearly listed options on how to do it as an api. ONE of those > > > options is no markup in text_set etc. and HELPERS indstead that would > > > convert from makrup to plain text PLUS call the metadata api's to set > > > metadata correctly. you double up on your api's and the markup ones are > > > built on top of the plain text + metadata ones. i have been VERY clear > on > > > that. i have been EXPLICITLY discussing the problems with this path. > > > > > > you could implement both WITHOUT the markup being wrappers (and now > have to > > > support both as native internal paths). from an api view it loosk the > same, > > > internally it look different. > > > > There are benefits when going for the "wrappers" approach: > > > > 1. You offload the parsing logic to another source (as it should, it has > > little to do with the current implementation of formats/annotations). > > > > 2. You don't repeat your logic - less to maintain. By making things use > > "annotation" API, whether you want to use a markup or just the > > annotation API, you maintain only the annotation code (in most cases, as > > markup logic is only a wrapper). > > > > > an options was dave's "set a mode (markup or plain)"" method which > cuts down > > > our api's again to something nice BUT means we always have to switch > to a > > > specific mode then back to where it was each time. > > > > I would rather not do that. Setting "modes" is kind of unpleasant. > > > > > other methods were provide text format as a parameter with the string, > > > provide it as special chars at the start of the string as a format > header, > > > and you propose having special string objects vaguely (i havent gotten > > > something clear on it yet), and i think this is probably worse as you > have > > > to create string object from markup string, then set/provide string > object > > > to label/entry object, and the reverse (to get text, get string obj, > then > > > get string from string obj etc.). this double-object thing IMHO would > make > > > the api even worse to use than any of the other options. > > > > > > imho the simplest option is pick one encoding only and provide > converters > > > like: > > > > > > obj.text_set(to_markup("Hello\nWorld")); > > > text = to_plain(obj.text_get()); > > > > > > ALL you need to know is it's markup by default. this means all the > string > > > query and manipulation funcs only need a single markup version at the > api > > > since you lose no information. > > > > Not all usages of text require markup. SOME (even a lot) want it, but > > not all. > > The question is: can we allow having two different interpretations for > > "Efl.Text.text" property? > > My answer is "no". We should stick to it being a plain text. > > > > >> Also my email was about api and not about internal storage. If you > want to > > >> handle everything internally in some encoded form fine - just don't > push > > >> that choice on users of what looks like a text api. Supporting both > plain > > >> text and markuped text models does not mean lowest common denominator > > >> internally. > > > i am not talking about internal encoding at all. ONLY talking about > api. i > > > was saying that IF the "native model" for api is not markup (all data > > > inline in the blob of text) and has to be dealt with by various api's > > > defining content then defining format ranges (char 13 to 67 is "bold", > at > > > char 16 insert image item "bob.jpg", etc. for example). then the markup > > > api's will be build AROUND this and that makes them complex > internally. you > > > also double up on your api's - having markup versions for every plain > text > > > version. this is not a great thing. > > > > > > this morning i just personally spoke to 2 developers in the office and > the > > > BOTH were: "markup is great. we like it. everyone i know of liked it > and > > > had no issues with elm_entry being markup by default - they liked it". > these > > > people have interacted with dozens of developers using these api's... > their > > > experience is the polar opposite of yours. they had zero issues in > dealing > > > with markup by default. i'm warning - change defaults and a silent > happy > > > large group become noisy and unhappy. > > > > Markup is staying. The developer will just need to use > > "efl_text_markup_set/insert", instead. > > Using a different name shouldn't upset anyone, unless I am missing > > something? > > that was my point way way way up in the thread. if you want to do this way > you > need plain text AND markup versions of every api that deals with text on a > window. > > text_get() > text_cursor_range_get() > text_set() > text_cursor_range_replace() > text_cursor_prepend() > text_cursor_append() > text_prepend() > text_append() > > for example. now you need a markup version of every one of these: > > markup_get() > markup_cursor_range_get() > markup_set() > markup_cursor_range_replace() > markup_cursor_prepend() > markup_cursor_append() > markup_prepend() > markup_append() > > having 2x the api's to do this isn't nice either. the default not doing > markup > also is likely to cause issues as i have mentioned... there will be > expectations of it doing markup when it now doesn't. the happy existing > users > of the api for example. > > > Also, I am writing the "Efl.Markup" mixin, that will use the annotation > > API, right now. > > Just letting you know. > > > > -- herdsman. > > > > > before jumping into "the decision is made, but we have no numbers on > what is > > > popular" ... get some data on that first. i suspect you may be > surprised at > > > how many people find markup simple, obvious and easy to deal with. it > keeps > > > our api implementation simpler and api size smaller. > > > > > >> I'll get to the rest later, apologies for the partial reply) > > >> Andy > > >> On Tue, 4 Jul 2017 at 20:29, Carsten Haitzler <[email protected]> > wrote: > > >> > > >>> On Tue, 04 Jul 2017 18:50:34 +0000 Andrew Williams < > [email protected]> > > >>> said: > > >>> > > >>>> Hi, > > >>>> > > >>>> Apologies I did not realise it was a question that needed > answering. As I > > >>>> moved in to discuss if we are worrying about text manipulation in > our > > >>>> widgets then we probably have bigger issues around separation of > > >>> concerns. > > >>>> Our text handling apis should worry about that - and the widget > have a > > >>>> simple way to bind to a text model or have the resulting text set. > > >>> it's part of the concerns. if you want to drop markup entirely then > you're > > >>> going to REALLY annoy a lot of people used to inlining their > metadata. > > >>> dave is > > >>> the counter example i am pointing at (and i bet you there are many > more > > >>> like > > >>> him). > > >>> > > >>> i remember at e dev day we specifically skipped popularity with "we > have > > >>> no info on what people prefer and are not doing some popularity poll > > >>> here" or words to that effect. so the jury is still out on what > people > > >>> actually prefer. > > >>> i know what you prefer. i have heard what some others prefer. if its > 55v45 > > >>> in > > >>> favour of plain text + api's to define format regions/nodes i still > say > > >>> "stick > > >>> to markup as it will make a transition easier". if it's 80v20 in > favour of > > >>> plain then move, but you need some way to provide inlined format > handling > > >>> to > > >>> express a string of text WITH formatting embedded (ie markup). what > you > > >>> are presenting is a fait accompli that has clearly said "ignoring > the data > > >>> - making this decision anyway". > > >>> > > >>> and to do that then you would need to provide api's that set/get (and > > >>> otherwise > > >>> manipulate and query) that do both markup versions AND plain text > versions > > >>> given your design. the way we do it now is when going from markup > (all > > >>> data there) to plain - we just drop all the markup on the floor and > > >>> convert a very > > >>> tags (<br> for example) and vice-versa. > > >>> > > >>> when your metadata is out-of-band like proposed you have to now have > > >>> markup versions of every plain text api version on anything because > > >>> dealing with formatting requires more calls to go query the > formatting > > >>> info separately to > > >>> the text and it can't just be done in a "simple wrapper that > converts a > > >>> string" because you are not just stripping out data from a full data > set, > > >>> but > > >>> having to do multiple api's to query and rebuild it and vice-versa. > the > > >>> proposal for strings is to make them very very very dumb (plain > text) by > > >>> default and that is highly problematic from a technical point of > view. > > >>> popularity is totally unknown at this point, so just assuming its > 50v50, > > >>> choosing the path with far more technical issues at the api level is > a bad > > >>> choice, and plain text is just that. > > >>> > > >>> you can't separate out the choice of markup or not from designing > the api. > > >>> doing markup by default is "we choose to lose NO information by > default > > >>> and have all of it there and provide you with helpers to drop info > not > > >>> needed or > > >>> used". choosing plain text by default is "we already lost all the > info - > > >>> you > > >>> have to add it back with more api's by querying or providing it". if > you > > >>> provide markup versions of every text api then this would be dealt > with > > >>> BUT it > > >>> leads to doubling up of every text api that manipulates or queries a > > >>> string and > > >>> that is not exactly wonderful. unlike markup by default, you can't > just > > >>> provide > > >>> a simple "degrade it to plain text" helper (or promote to markup) > like we > > >>> do > > >>> now. you have to have the full set doubled up. > > >>> > > >>>> I appreciate that people have not had issues with the way it is, > but I > > >>>> don't think that is reason enough to dismiss the issues that are > reported > > >>>> or the confusion created... (I reference back to user enters 2>3 but > > >>>> text_get returns 2>3) > > >>> and removing markup by default creates other problems which i am > pointing > > >>> out > > >>> because it downgrades the information passed in and out BY DEFAULT > (plain > > >>> text > > >>> is downgraded vs markup). you will have issues EITHER way. plain > text is > > >>> not > > >>> magically so much better than markup. it switches a different base > > >>> assumption > > >>> on the text encoding (text is always encoded. UTF-8 plain text where > \n > > >>> means > > >>> go down 1 line and move cursor to left (or right) edge, char values > > 127 > > >>> e.g. > > >>> even for latin-1 are encoded with multiple byte sequences ala UTF-8 > ... > > >>> it's > > >>> ALWAYS encoded). markup is just an extended form of encoding on top > of > > >>> this. > > >>> and functions/helpers were provided to do this conversion. it's not > being > > >>> dismissed. far from it - it was already envisaged and addressed. > maybe the > > >>> helpers could now use eina_slstr to avoid needing to free strings > > >>> afterwards... > > >>> > > >>> but my point is that if the DEFAULT api were to be lossy (plain > text) then > > >>> you > > >>> create a huge amount of problems. if it were markup then you'd have > far > > >>> fewer > > >>> problems and just need the kind of convert funcs as we already have. > that > > >>> or > > >>> having to provide markup duplicates api's for every string > > >>> get/set/insert/fetch > > >>> substring etc. and from api size/complexity duplicating is generally > a bad > > >>> path > > >>> to go down. > > >>> > > >>> and ALL of this discussion at the technical api level hasn't even > got the > > >>> info > > >>> on what people prefer to be the default. to get a good feel for > this... > > >>> you NEED to give them some options on what to choose and thus design > > >>> api's to handle all cases and propose something and see that it > actually > > >>> can handle them... then find out what people think then about it - > the > > >>> kinds of users who > > >>> use the api regularly... THEN make a decision on what should be > done. well > > >>> if > > >>> you are planning on changing something AND the change is > controversial > > >>> (which > > >>> it seemingly is). > > >>> > > >>>> Encoding of text is not something that a widget should have to deal > with > > >>>> and decoding is not something that a cost char* text_get api > implies. > > >>> the documentation clearly says otherwise. if it makes you feel > better we > > >>> could: > > >>> > > >>> typedef Elm_Markup char; > > >>> > > >>> Elm_Markup *elm_object_text_get(Evas_object *obj); > > >>> > > >>> though it'd be a lie because some widgets dont do markup... but > entry and > > >>> label > > >>> do ... (and some parts in a layout do do markup if TEXTBLOCK and some > > >>> don't if > > >>> TEXT). > > >>> > > >>> we ALL agree that inconsistency is bad and this should be fixed. > > >>> > > >>>> Andy > > >>>> On Tue, 4 Jul 2017 at 13:23, Davide Andreoli < > [email protected]> > > >>> wrote: > > >>>>> 2017-07-04 14:22 GMT+02:00 Andrew Williams <[email protected]>: > > >>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> I jumped back to this email I sent a week ago and realised that we > > >>> have > > >>>>>> just spent a bunch of time revisiting a discussion that had > clearly > > >>>>> wrapped > > >>>>>> up at the EDD in Malta. One reason I wanted to post our conclusion > > >>> to the > > >>>>>> list was for visibility and a chance to comment for anyone who was > > >>> not > > >>>>> able > > >>>>>> to attend. Unfortunately instead we have had a lot of the same > points > > >>>>>> brought forward that were already discussed at the event which has > > >>> led to > > >>>>>> confusion and time wasting. > > >>>>>> > > >>>>>> There is a question in here about general API design that I will > > >>> start > > >>>>> in a > > >>>>>> new thread but i want to wrap up this discussion. Is there anyone > on > > >>> this > > >>>>>> list (except raster as Tizen developer proxy) who disagrees with > the > > >>>>>> approach as was laid out in my email of the 29th? > > >>>>>> > > >>>>> you still did not reply to the first raster's question: > > >>>>> do we will have a markup variant for every text operation? > (text_set, > > >>>>> text_append, text_insert...etc). > > >>>>> > > >>>>> To be honest I never had any issue with the current always-markup > > >>> model, > > >>>>> so for now I vote for keeping the legacy behavior also on the new > EO > > >>> api. > > >>>>> > > >>>>> > > >>>>>> I understand that this could be conceived as a massive change but > my > > >>>>>> understanding was that the Eo API was a chance to fix things up > to be > > >>>>>> better going forward and not to be shackled by our choices of the > > >>> past. > > >>>>> If > > >>>>>> that is not true then we will really struggle to make quality > > >>> bindings to > > >>>>>> higher level languages (in this context the difference between > plain > > >>> text > > >>>>>> and markedup/parameterised text and also the tight coupling of > text > > >>>>>> handling and the rendering). > > >>>>>> > > >>>>>> Thanks > > >>>>>> Andy > > >>>>>> > > >>>>>> On Thu, 29 Jun 2017 at 07:13, Andrew Williams < > [email protected]> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> 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 > > >>>>>>> > > >>>>>>> Thanks everyone for the discussion :) > > >>>>>>> Andy > > >>>>>>> > > >>>>>>> On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler < > > >>> [email protected]> > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli < > > >>>>>>>> [email protected]> > > >>>>>>>> said: > > >>>>>>>> > > >>>>>>>>> 2017-06-19 13:36 GMT+02:00 Daniel Hirt <[email protected]>: > > >>>>>>>>>> Hi, > > >>>>>>>>>> > > >>>>>>>>>> On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams < > > >>>>>>>> [email protected]> > > >>>>>>>>>> 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 > > >>>>>>>>>> [email protected] > > >>>>>>>>>> > > >>> 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 > > >>>>>>>>> [email protected] > > >>>>>>>>> > > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> ------------- Codito, ergo sum - "I code, therefore I am" > > >>>>> -------------- > > >>>>>>>> The Rasterman (Carsten Haitzler) [email protected] > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> ------------------------------------------------------------ > > >>>>>> ------------------ > > >>>>>>>> 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 > > >>>>>>>> [email protected] > > >>>>>>>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>>>>>> > > >>>>>>> -- > > >>>>>>> http://andywilliams.me > > >>>>>>> http://ajwillia.ms > > >>>>>>> > > >>>>>> -- > > >>>>>> 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 > > >>>>>> [email protected] > > >>>>>> 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 > > >>>>> [email protected] > > >>>>> 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 > > >>>> [email protected] > > >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>> > > >>> > > >>> -- > > >>> ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > >>> The Rasterman (Carsten Haitzler) [email protected] > > >>> > > >>> -- > > >> 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
