What has VTermOutputDriver to do with FilePolicy? Le 23 oct. 2016 12:22, "stepharo" <[hidden email]> a écrit :
|
In reply to this post by stepharo
Hi,
> On Oct 23, 2016, at 12:18 PM, stepharo <[hidden email]> wrote: > > >> Hi Stef, >> >> We are not throwing away anything. The goal is not to produce a new model, the goal is to find one that matches the requirements. > Don't play with words. >> We already learnt a lot from TxText, but it has limitations in how to deal with things that are not only text. > I can imagine. >> We have no intention of producing an unfinished text model :). > Me neither with igor and txText yet life decided otherwise. You see I spent at 10 months of salary on txText. >> This is a critical component for us. Please let us work for a couple of months and we get back with news. I am really not playing with words :). We really have zero desire in working on the text editor. Just like we had zero desire in working on Sparta and Bloc. We are doing it because we need a sane infrastructure. We have halted the work on user interface of GT for more than 1 year just because it did not make engineering and economic sense to invest on the current infrastructure. We need an infrastructure to support at least the next 5-10 years of development, and we are decided to deliver on it. The investment in TxText is not at all wasted, it allowed us to bootstrap Bloc and to learn. We might end up with reusing parts of it, but the thing is that now we have new opportunities that come with Sparta. For example, all text measurements are super accurate and are available in image. This means that we can address text rendering in two ways: 1. treat text as one entity and embed graphics inside as elements in the text model. This is where TxText is. However, TxText does not have the support for non-text elements (at least not now). Furthermore, this approach makes floating images inside the text (images that allow text to wrap around) to not be really working. 2. split the text in different sections and lay it out together with other graphical elements using the layout engine from Bloc. Option 2 was not really an option until now because we did not have the performance and accuracy. Now it is an option and we want to investigate this as well before committing to a model. Cheers, Doru >> Cheers, >> Doru >> >> >>> On Oct 22, 2016, at 8:31 PM, stepharo <[hidden email]> wrote: >>> >>> Hi aliaksei >>> >>> I thought that you were just changing the internal representation of txText to use Ropes >>> and building on top of / improving txText >>> I did not think that you were throwing away all the work igor did. Because he spent a lot of time >>> >>> designing the text model and making it is scalable - and now I read that apparently it was not scalable enough. >>> I'm wondering what will happen if suddenly you disappear: we will get two unfinished textmodel >>> and use an old one? When do you think that you will have a working usable by other for real text model? >>> Stef >>> >>> Le 22/10/16 à 12:29, Aliaksei Syrel a écrit : >>>> As Doru already mentioned text editor is an important part of the tools. There are some requirements a text editor should fulfil. >>>> >>>> • Support of large files ( >> 100mb) >>>> • Support of large pieces of text located in memory >>>> • Allow developers to embed visual elements (pictures, interactive elements, custom elements) >>>> • Support of more sophisticated layouts rather than line-based. For example columns. >>>> • Line breaking >>>> • Text wrapping >>>> • Hyphens >>>> • Should be fast >>>> Tests show that TxText model is very nice for basic cases, works well for "normal" use. >>>> However, when it comes to extreme cases linked list of spans just fails, while rope shows great performance - and it also scales. >>>> >>>> Cheers, >>>> Alex >>>> >>>> On 19 October 2016 at 23:51, Denis Kudriashov <[hidden email]> wrote: >>>> >>>> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <[hidden email]>: >>>> - Added initial text support, for instance rendering and high precision measurement. >>>> >>>> I look at code and it seems you implemented another one new text model? Why you not use TxText? >>>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Some battles are better lost than fought." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her." |
Administrator
|
In reply to this post by stepharo
I'm not sure if the following qualifies as a rant, but I apologize in advance just in case... Hopefully the difference in this instance is that there is an entire team around this effort. It's just hard to be asked to trust after years of (albeit solo, usually unpaid) projects, touted as our future salvation, and then abandoned when "life got in the way" - e.g. (in no particular order, and some of these might not exactly fit into the above description) TxText, Nautilus, Spec, Amber, Simple Morphic / Morphic 3, NativeBoost, Rome (iirc the name), etc. The thing is that in niche (i.e. non-core dev) projects this path to failure seems to be the rule, and not an exception, especially when releases are put off indefinitely chasing perfection. I have a very personal experience of this since one of my first desires (a quick search of the mailing list shows a post as early as May 14, 2010!) was to implement VIM key bindings. Our exasperating text/editor model quickly ground the project to a halt. I feel like I've been waiting for a just-around-the-corner cleanup in this area for over 6 years now. Of course, I'm not complaining about the lack of result, just offering some context around the suspicion and concern about yet-another-reboot with not a single release in over 7 years. All that having been said, you're directions of investigation are very exciting and I look forward to the results!
Cheers,
Sean |
In reply to this post by philippe.back@highoctane.be
Not that I know. I did not get why Igor went totally off like that.
|
Free forum by Nabble | Edit this page |