On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo. I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
For me the problem with the TxText model is that it blocks the possibility of doing that later, if and when there is enough development capacity to invest in this. Stephan
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
For me the problem with the TxText model is that it blocks the possibility of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this). Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all). Thierry
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
For me the problem with the TxText model is that it blocks the possibility
of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there? It is nice to dream time to time, but let us be realistic.
Thierry
-- Best regards, Igor Stasenko.
2016-04-04 14:24 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
I think that if we didn't have unrealistic goals, we wouldn't be in that community :)
For me the problem with the TxText model is that it blocks the
possibility of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there?
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
It is nice to dream time to time, but let us be realistic.
I'd say that we have an environment where we can dream; where reinventions can be done at low cost (or at lower cost than others), that we can even afford to be wrong and throw a project away. Otherwise we wouldn't have Athens / TxText / GT ... Mind you, I'm not asking you to do it :) I simply know that some of TxText stuff is usable in that context. And that given the goal, shortcuts are possible. Regards, Thierry
On 4 April 2016 at 15:44, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 14:24 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
I think that if we didn't have unrealistic goals, we wouldn't be in that community :)
For me the problem with the TxText model is that it blocks the
possibility of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there?
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
It is nice to dream time to time, but let us be realistic.
I'd say that we have an environment where we can dream; where reinventions can be done at low cost (or at lower cost than others), that we can even afford to be wrong and throw a project away. Otherwise we wouldn't have Athens / TxText / GT ...
Mind you, I'm not asking you to do it :) I simply know that some of TxText stuff is usable in that context. And that given the goal, shortcuts are possible.
But do you realising that we talking here about different scales of things? Let me drive an analogy: - you found an engineer that created a rocket engine in his garage. Engine is perfect, stable, works well etc etc etc.. And you asking him: - can we fly to the Moon tomorrow? Huh? Okay, if you find specialist, who can plan the mission, find the producer of solar panels, find specialist of long range communications, find specialists of long-range observations to determine the landing site, find god know how many other specialist and experts in various areas, only then you could possibly find and answer to your question. But asking such question to just a rocket engine specialist.. is just foolish.
Regards,
Thierry
-- Best regards, Igor Stasenko.
2016-04-04 15:02 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 15:44, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 14:24 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
I think that if we didn't have unrealistic goals, we wouldn't be in that community :)
For me the problem with the TxText model is that it blocks the
possibility of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there?
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
It is nice to dream time to time, but let us be realistic.
I'd say that we have an environment where we can dream; where reinventions can be done at low cost (or at lower cost than others), that we can even afford to be wrong and throw a project away. Otherwise we wouldn't have Athens / TxText / GT ...
Mind you, I'm not asking you to do it :) I simply know that some of TxText stuff is usable in that context. And that given the goal, shortcuts are possible.
But do you realising that we talking here about different scales of things? Let me drive an analogy: - you found an engineer that created a rocket engine in his garage. Engine is perfect, stable, works well etc etc etc.. And you asking him: - can we fly to the Moon tomorrow?
Huh?
Okay, if you find specialist, who can plan the mission, find the producer of solar panels, find specialist of long range communications, find specialists of long-range observations to determine the landing site, find god know how many other specialist and experts in various areas, only then you could possibly find and answer to your question. But asking such question to just a rocket engine specialist.. is just foolish.
Don't do analogies, they don't work. First I said: for Pillar users, a word processing software is not that useful. If you're using Pillar, you're not looking for a Microsoft Word GUI, otherwise you'd be using Microsoft Word and not Pillar :) Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :) Regards, Thierry
Regards,
Thierry
-- Best regards, Igor Stasenko.
On 4 April 2016 at 16:14, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:02 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 15:44, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 14:24 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
I think that if we didn't have unrealistic goals, we wouldn't be in that community :)
For me the problem with the TxText model is that it blocks the
possibility of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there?
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
It is nice to dream time to time, but let us be realistic.
I'd say that we have an environment where we can dream; where reinventions can be done at low cost (or at lower cost than others), that we can even afford to be wrong and throw a project away. Otherwise we wouldn't have Athens / TxText / GT ...
Mind you, I'm not asking you to do it :) I simply know that some of TxText stuff is usable in that context. And that given the goal, shortcuts are possible.
But do you realising that we talking here about different scales of things? Let me drive an analogy: - you found an engineer that created a rocket engine in his garage. Engine is perfect, stable, works well etc etc etc.. And you asking him: - can we fly to the Moon tomorrow?
Huh?
Okay, if you find specialist, who can plan the mission, find the producer of solar panels, find specialist of long range communications, find specialists of long-range observations to determine the landing site, find god know how many other specialist and experts in various areas, only then you could possibly find and answer to your question. But asking such question to just a rocket engine specialist.. is just foolish.
Don't do analogies, they don't work.
First I said: for Pillar users, a word processing software is not that useful. If you're using Pillar, you're not looking for a Microsoft Word GUI, otherwise you'd be using Microsoft Word and not Pillar :)
Analogies don't work. Right :) I never used Pillar and have remote ideas
about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Regards,
Thierry
-- Best regards, Igor Stasenko.
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :) Regards, Thierry
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
But i don't know what Pillar is. Never used it. I'm not lying here. I seen people doing something with it time to time.. but never got my eyes on it. Or would you prefer that i would pretend that i know something and can continue discussion about things related to it? Waving hands, pointing to milestones, drawing diagrams? :)
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :)
Okay, let me elaborate what was the whole point behind TxText project.
It was part of work we were doing to migrate from old Canvas & BitBlt Morphic rendering towards vector-based rendering using Athens. Basically in a nutshell TxText is a model and rendering engine for text rendering. Does it means it can serve as a base of full-fledged word processing software in a future? Sure thing. Why not? But does it means i should care or have interest in pursuing that direction? No. It is not on my radar and not among my interests.
Regards,
Thierry
-- Best regards, Igor Stasenko.
2016-04-04 15:49 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
But i don't know what Pillar is. Never used it. I'm not lying here. I seen people doing something with it time to time.. but never got my eyes on it. Or would you prefer that i would pretend that i know something and can continue discussion about things related to it? Waving hands, pointing to milestones, drawing diagrams? :)
Yes, diagrams :) Ok, I don't know that much Pillar in details myself; except as one of those things where some of your characters in the text are used to build a layout on a target.
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :)
Okay, let me elaborate what was the whole point behind TxText project.
It was part of work we were doing to migrate from old Canvas & BitBlt Morphic rendering towards vector-based rendering using Athens. Basically in a nutshell TxText is a model and rendering engine for text rendering.
I'd say it is more: it is an interactive model for text editing and rendering. How much of it is "interactive" by opposition to pure rendering? Can they be easily separated?
Does it means it can serve as a base of full-fledged word processing software in a future? Sure thing. Why not?
Ok.
But does it means i should care or have interest in pursuing that direction? No. It is not on my radar and not among my interests.
You made that point clear :) Regards, Thierry
On 4 April 2016 at 17:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:49 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
But i don't know what Pillar is. Never used it. I'm not lying here. I seen people doing something with it time to time.. but never got my eyes on it. Or would you prefer that i would pretend that i know something and can continue discussion about things related to it? Waving hands, pointing to milestones, drawing diagrams? :)
Yes, diagrams :) Ok, I don't know that much Pillar in details myself; except as one of those things where some of your characters in the text are used to build a layout on a target.
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :)
Okay, let me elaborate what was the whole point behind TxText project.
It was part of work we were doing to migrate from old Canvas & BitBlt Morphic rendering towards vector-based rendering using Athens. Basically in a nutshell TxText is a model and rendering engine for text rendering.
I'd say it is more: it is an interactive model for text editing and rendering. How much of it is "interactive" by opposition to pure rendering? Can they be easily separated?
Well, there is a model, TxModel, which is domain-based. Means it is abstract and agnostic from any kind of rendering engine or UI. It represents an object that contains text and allows certain operation on it, like selection, deletion, insertion etc. And rendering engine bridges that model with morphic and athens. It cannot be separated, since it implies using such model for computing layout, and implies to use Athens for rendering.. And implies to exist in Morphic (or some other kind of UI environment) for UI interaction, to be represented as a widget on screen and receive events and mouse/keyboard input etc. So, what kind of separation you trying to see there?
Does it means it can serve as a base of full-fledged word processing software in a future? Sure thing. Why not?
Ok.
But does it means i should care or have interest in pursuing that direction? No. It is not on my radar and not among my interests.
You made that point clear :)
Regards,
Thierry
-- Best regards, Igor Stasenko.
2016-04-04 16:14 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 17:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:49 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
But i don't know what Pillar is. Never used it. I'm not lying here. I seen people doing something with it time to time.. but never got my eyes on it. Or would you prefer that i would pretend that i know something and can continue discussion about things related to it? Waving hands, pointing to milestones, drawing diagrams? :)
Yes, diagrams :) Ok, I don't know that much Pillar in details myself; except as one of those things where some of your characters in the text are used to build a layout on a target.
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :)
Okay, let me elaborate what was the whole point behind TxText project.
It was part of work we were doing to migrate from old Canvas & BitBlt Morphic rendering towards vector-based rendering using Athens. Basically in a nutshell TxText is a model and rendering engine for text rendering.
I'd say it is more: it is an interactive model for text editing and rendering. How much of it is "interactive" by opposition to pure rendering? Can they be easily separated?
Well, there is a model, TxModel, which is domain-based. Means it is abstract and agnostic from any kind of rendering engine or UI. It represents an object that contains text and allows certain operation on it, like selection, deletion, insertion etc. And rendering engine bridges that model with morphic and athens. It cannot be separated, since it implies using such model for computing layout, and implies to use Athens for rendering.. And implies to exist in Morphic (or some other kind of UI environment) for UI interaction, to be represented as a widget on screen and receive events and mouse/keyboard input etc. So, what kind of separation you trying to see there?
I was trying to evaluate how much of it was tied to an underlying text model, and a specific interaction approach / global high level view of the UI. A short look through the layout part of it and I saw it has support for arbitrary object spans. It also supposes a certain API from it's model (interacting back to indicate where lines should be ended). A text is a list of spans, isn't it? And spans are flat (no span inside span). One could imagine extending attributes for spans / type of spans and get customized rendering / handling for those. For now, external objects can't extend below the baseline. Position inside spans can be ambiguous: last position of a span and first position of the next span are the same position. Thierry
On 4 April 2016 at 17:47, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 16:14 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 17:03, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:49 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
But i don't know what Pillar is. Never used it. I'm not lying here. I seen people doing something with it time to time.. but never got my eyes on it. Or would you prefer that i would pretend that i know something and can continue discussion about things related to it? Waving hands, pointing to milestones, drawing diagrams? :)
Yes, diagrams :) Ok, I don't know that much Pillar in details myself; except as one of those things where some of your characters in the text are used to build a layout on a target.
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :)
Okay, let me elaborate what was the whole point behind TxText project.
It was part of work we were doing to migrate from old Canvas & BitBlt Morphic rendering towards vector-based rendering using Athens. Basically in a nutshell TxText is a model and rendering engine for text rendering.
I'd say it is more: it is an interactive model for text editing and rendering. How much of it is "interactive" by opposition to pure rendering? Can they be easily separated?
Well, there is a model, TxModel, which is domain-based. Means it is abstract and agnostic from any kind of rendering engine or UI. It represents an object that contains text and allows certain operation on it, like selection, deletion, insertion etc. And rendering engine bridges that model with morphic and athens. It cannot be separated, since it implies using such model for computing layout, and implies to use Athens for rendering.. And implies to exist in Morphic (or some other kind of UI environment) for UI interaction, to be represented as a widget on screen and receive events and mouse/keyboard input etc. So, what kind of separation you trying to see there?
I was trying to evaluate how much of it was tied to an underlying text model, and a specific interaction approach / global high level view of the UI.
A short look through the layout part of it and I saw it has support for arbitrary object spans. It also supposes a certain API from it's model (interacting back to indicate where lines should be ended). A text is a list of spans, isn't it? And spans are flat (no span inside span). One could imagine extending attributes for spans / type of spans and get customized rendering / handling for those.
Correct.
For now, external objects can't extend below the baseline.
Slightly not like that. An external object are bound to concrete position in text. And layout of a single line are computed based on dimensions of that object, as well as dimensions of other parts of a line. The text flow are not affected by the object in terms that there is no capability to compute wrapping text around it or align it left/right whatever separately from text. It means that basically external object is like a special kind of glyph/icon that uses same layout rules as character glyphs, but just rendered separately.
Position inside spans can be ambiguous: last position of a span and first position of the next span are the same position.
Well, for some operation the are treated as same, for some - don't.
Since there's nothing can be between two positions at the ends of adjacent spans, from standpoint of user they represent same position in text. But from standpoint of model they are different since position are belong to different spans. Sure thing, there certain pieces added to avoid problems with such ambiguity, so that it don't causing problems on user-level. Thierry
-- Best regards, Igor Stasenko.
2016-04-04 17:07 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
For now, external objects can't extend below the baseline.
Slightly not like that. An external object are bound to concrete position in text. And layout of a single line are computed based on dimensions of that object, as well as dimensions of other parts of a line. The text flow are not affected by the object in terms that there is no capability to compute wrapping text around it or align it left/right whatever separately from text. It means that basically external object is like a special kind of glyph/icon that uses same layout rules as character glyphs, but just rendered separately.
I understood as much. I've just seen code that such a "special" glyph can only contribute to text ascent (since, per comment, it is aligned to the baseline). Not very important, just a detail.
Position inside spans can be ambiguous: last position of a span and first position of the next span are the same position.
Well, for some operation the are treated as same, for some - don't.
Since there's nothing can be between two positions at the ends of adjacent spans, from standpoint of user they represent same position in text. But from standpoint of model they are different since position are belong to different spans. Sure thing, there certain pieces added to avoid problems with such ambiguity, so that it don't causing problems on user-level.
Ok. Thierry
On 04-04-16 16:47, Thierry Goubier wrote:
A short look through the layout part of it and I saw it has support for arbitrary object spans. It also supposes a certain API from it's model (interacting back to indicate where lines should be ended). A text is a list of spans, isn't it? And spans are flat (no span inside span). One could imagine extending attributes for spans / type of spans and get customized rendering / handling for those. Yes, a flat list of spans vs a composite structure might cause performance problems.
Stephan
On 4 April 2016 at 16:49, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it. Forgive my ignorance.. but i am not omniscient.
False humility doesn't work there, Igor :)
But i don't know what Pillar is. Never used it. I'm not lying here. I seen people doing something with it time to time.. but never got my eyes on it. Or would you prefer that i would pretend that i know something and can continue discussion about things related to it? Waving hands, pointing to milestones, drawing diagrams? :)
Second is: Pharo (and all smalltalks) is the place where supposedly impossible stuff can be developed, simply because it takes far less lines than anywhere else. No guarantees, but, at the rate we're dropping projects by the side of the road (and reinventing stuff multiple times over), we have manpower to spare :)
But that is orthogonal. It is possible to do anything on turing-complete environment. Taking shortcuts etc etc yadda yadda. Now do such statements alone can bring us anywhere closer to grand goals and grand projects? Nope. Only hard day to day work could bring us there.. Not talks about how cool we are.
Hard day to day work, yes. But if you make it that uninteresting, yes, I'm sure we will never get there :)
Okay, let me elaborate what was the whole point behind TxText project.
It was part of work we were doing to migrate from old Canvas & BitBlt Morphic rendering towards vector-based rendering using Athens. Basically in a nutshell TxText is a model and rendering engine for text rendering. Does it means it can serve as a base of full-fledged word processing software in a future? Sure thing. Why not?
But does it means i should care or have interest in pursuing that direction? No. It is not on my radar and not among my interests.
.. My interest was to migrate Pharo to run using vector-based graphics. And without text rendering, that apparently would be incomplete. What you can do on top of that, is beyond that scope. My personal interest and interest of our team was to make a platform, so you can do it yourself.
Regards,
Thierry
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote ideas about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it.
Please see... [1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf [2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfu... Most (all?) of docs at [3] are done using Pillar... [3] https://github.com/SquareBracketAssociates cheers -ben
On 5 April 2016 at 04:16, Ben Coman <btc@openinworld.com> wrote:
On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 April 2016 at 16:32, Thierry Goubier <thierry.goubier@gmail.com>
wrote:
2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Analogies don't work. Right :) I never used Pillar and have remote
ideas
about what it does or requires. From that perspective you appeal to wrong person. On your place i would be asking a guy who knows Pillar innards about it.
Please see...
[1] http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf
Okay. Now i remember. Yeah, i can easily imagine making a transformer that renders a pillar markup text into TxText instance, by implementing an yet another exporter, like PRTxTextWriter. Certain features would be impossible right now, but for simple docs i guess it may work just fine.
[2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfu...
Most (all?) of docs at [3] are done using Pillar... [3] https://github.com/SquareBracketAssociates
cheers -ben
-- Best regards, Igor Stasenko.
On Apr 4, 2016 3:03 PM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 4 April 2016 at 15:44, Thierry Goubier <thierry.goubier@gmail.com>
wrote:
2016-04-04 14:24 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com>
wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not
a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for
many Pharo users.
AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
I think that if we didn't have unrealistic goals, we wouldn't be in that community :)
For me the problem with the TxText model is that it blocks the
possibility of doing
that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there?
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
It is nice to dream time to time, but let us be realistic.
I'd say that we have an environment where we can dream; where reinventions can be done at low cost (or at lower cost than others), that we can even afford to be wrong and throw a project away. Otherwise we wouldn't have Athens / TxText / GT ...
Mind you, I'm not asking you to do it :) I simply know that some of TxText stuff is usable in that context. And that given the goal, shortcuts are possible.
But do you realising that we talking here about different scales of things? Let me drive an analogy: - you found an engineer that created a rocket engine in his garage. Engine is perfect, stable, works well etc etc etc.. And you asking him: - can we fly to the Moon tomorrow?
Huh?
Okay, if you find specialist, who can plan the mission, find the producer of solar panels, find specialist of long range communications, find specialists of long-range observations to determine the landing site, find god know how many other specialist and experts in various areas, only then you could possibly find and answer to your question. But asking such question to just a rocket engine specialist.. is just foolish.
Is there a doc explaining TxText somewhere? One of first things I wanted to do in Pharo (was 1.2 or 1.3 at the time) was to have text with clickable links, pictures etc. And not in a web page. So, I ended up in ParagraphEditor, Text attributes etc. I still want to make that work and I think that TxText is suitable from what I saw. Any pointers? Phil
Regards,
Thierry
-- Best regards, Igor Stasenko.
On 4 April 2016 at 16:14, philippe.back@highoctane.be < philippe.back@gmail.com> wrote:
Is there a doc explaining TxText somewhere?
One of first things I wanted to do in Pharo (was 1.2 or 1.3 at the time) was to have text with clickable links, pictures etc. And not in a web page.
So, I ended up in ParagraphEditor, Text attributes etc.
I still want to make that work and I think that TxText is suitable from what I saw.
Any pointers?
Most of it in class comments i guess. I did not created any sort of other documentation for TxText. Apologies. And i don't know what is state of it since year i have left. Did it picked up by someone in community, or it stays at same stage where i left it?
Phil
-- Best regards, Igor Stasenko.
philippe.back@highoctane.be wrote
So, I ended up in ParagraphEditor, Text attributes etc.
Ugh. How many beautiful projects have died because of Paragraph and associated editors?! This is where my vim keybindings experiment came screeching to a halt. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
philippe.back@highoctane.be wrote
So, I ended up in ParagraphEditor, Text attributes etc.
Ugh. How many beautiful projects have died because of Paragraph and associated editors?!
A damn lot, I can tell you.
This is where my vim keybindings experiment came screeching to a halt.
----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-04-06 7:57 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
philippe.back@highoctane.be wrote
So, I ended up in ParagraphEditor, Text attributes etc.
Ugh. How many beautiful projects have died because of Paragraph and associated editors?!
A damn lot, I can tell you.
This is where my vim keybindings experiment came screeching to a halt.
What are the main problems with Text, Paragraph, ... and other old TextComponents? And how are these solved with TxText?
----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 6 April 2016 at 10:07, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 7:57 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
philippe.back@highoctane.be wrote
So, I ended up in ParagraphEditor, Text attributes etc.
Ugh. How many beautiful projects have died because of Paragraph and associated editors?!
A damn lot, I can tell you.
This is where my vim keybindings experiment came screeching to a halt.
What are the main problems with Text, Paragraph, ... and other old TextComponents?
1. No support for vector graphics 2. Most operations are bound to text size.
And how are these solved with TxText?
1. By implementing new view, rendered by Athens 2. By introducing new model for storing text to overcome mentioned limitations.
----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
2016-04-06 9:59 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 10:07, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 7:57 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
philippe.back@highoctane.be wrote
So, I ended up in ParagraphEditor, Text attributes etc.
Ugh. How many beautiful projects have died because of Paragraph and associated editors?!
A damn lot, I can tell you.
This is where my vim keybindings experiment came screeching to a halt.
What are the main problems with Text, Paragraph, ... and other old TextComponents?
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView I don't see where the models (Text vs. TxText) is the problem.
2. Most operations are bound to text size.
In what use cases is this a problem ? (Paragraph and DisplayScanner have good support for justified text (left / right / center), indentation wrapping and (I don't know if this works in pharo anymore but squeak had) even filling text in arbitary shaped polygons ( that was pretty cool). And even for text of different size and with different emphasis.
And how are these solved with TxText?
1. By implementing new view, rendered by Athens
Ok ,but this could have be done (or is done) with the old Text class as well (no?)
2. By introducing new model for storing text to overcome mentioned limitations.
But this is exactly what I don't understand. How is storing the text in TxText model better than the old Text. Given that we don't have any (beside TxWorkspace) tools actually using this model. I have a faint idea how TxText could be easier for building advanced tools, but I don't see that this model is a crucial point in developing good/better tools for text editing.
----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888515.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 9:59 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 10:07, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 7:57 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <sean@clipperadams.com
wrote:
philippe.back@highoctane.be wrote
So, I ended up in ParagraphEditor, Text attributes etc.
Ugh. How many beautiful projects have died because of Paragraph and associated editors?!
A damn lot, I can tell you.
This is where my vim keybindings experiment came screeching to a halt.
What are the main problems with Text, Paragraph, ... and other old TextComponents?
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView I don't see where the models (Text vs. TxText) is the problem.
2. Most operations are bound to text size.
In what use cases is this a problem ? (Paragraph and DisplayScanner have good support for justified text (left / right / center), indentation wrapping and (I don't know if this works in pharo anymore but squeak had) even filling text in arbitary shaped polygons ( that was pretty cool). And even for text of different size and with different emphasis.
It is about text size (the total number of characters in Text). I am aware about those features in Text and of course i feel a pity that we lost some of them in new TxText, because there was so many to make everything at once.
And how are these solved with TxText?
1. By implementing new view, rendered by Athens
Ok ,but this could have be done (or is done) with the old Text class as well (no?)
It could be done. Except that model for text scanning and layout in DisplayScanner & friends are nailed to pixel grid. (You know , all that glyph width + 1, line height - 1.. and things like that all over the place). It is virtually impossible to turn that into vector-compliant thing. Because it is pixel based from its very birth.. and trying to convert it to vector form, would be going against the nature of code itself and all design decisions made, centered around the fact that we dealing with pixels. You right, that asking this question. I was attempted to approach it , because for a lazy person like me, i didn't wanted to start from scratch.. But after wasting couple weeks on that, i came to conclusion that it is hopeless. Or maybe because i incapable to do it.. choose what you like most :)
2. By introducing new model for storing text to overcome mentioned limitations.
But this is exactly what I don't understand. How is storing the text in TxText model better than the old Text. Given that we don't have any (beside TxWorkspace) tools actually using this model. I have a faint idea how TxText could be easier for building advanced tools, but I don't see that this model is a crucial point in developing good/better tools for text editing.
I giving you a hint: try opening a hundred kilobytes text in TextMorph.
Or just a method with lots of source code in it (we have a number of those in image) -- Best regards, Igor Stasenko.
On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess@gmail.com> wrote:
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView
Sorry, missed to reply to that important point. It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form on Athens surface. So, that is why it 'works' :) -- Best regards, Igor Stasenko.
2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess@gmail.com> wrote:
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView
Sorry, missed to reply to that important point. It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form on Athens surface.
Nah, actually it works a bit different. Many (Form)Canvas methods are reimplemented on Athens API. But yes, I used some hacks as well.
So, that is why it 'works' :)
-- Best regards, Igor Stasenko.
On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess@gmail.com> wrote:
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView
Sorry, missed to reply to that important point. It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form on Athens surface.
Nah, actually it works a bit different. Many (Form)Canvas methods are reimplemented on Athens API. But yes, I used some hacks as well.
Didn't knew. Aha.. i see AthensCanvasWrapper. Ohh.. that's so much pain :)
So, that is why it 'works' :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
btw, if you wanna feel a difference, why we wanted vector based rendering, by yourself, open: Morph comment asText asMorph openInSceneView and then | sceneView view | sceneView := AthensSceneView new. view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. sceneView scene: view. sceneView openInWindow and try zooming it in and out with mouse wheel. On 6 April 2016 at 17:58, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess@gmail.com> wrote:
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView
Sorry, missed to reply to that important point. It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form on Athens surface.
Nah, actually it works a bit different. Many (Form)Canvas methods are reimplemented on Athens API. But yes, I used some hacks as well.
Didn't knew. Aha.. i see AthensCanvasWrapper. Ohh.. that's so much pain :)
So, that is why it 'works' :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 06-04-16 10:36, Nicolai Hess wrote:
In what use cases is this a problem ? (Paragraph and DisplayScanner have good support for justified text (left / right / center), indentation wrapping and (I don't know if this works in pharo anymore but squeak had) even filling text in arbitary shaped polygons ( that was pretty cool). And even for text of different size and with different emphasis.
|t1 t2 ball page| page := Morph new. page bounds: (100@100 corner: 300@300). page color: Color gray. t1 := TextMorph new. t1 autoFit:false. t1 bounds: (105@105 corner: 195@295). t1 backgroundColor: Color white. t1 occlusionsOnOff. page addMorph: t1. t2 := TextMorph new. t2 autoFit: false. t2 bounds: (205@105 corner: 295@295). t2 backgroundColor: Color white. t2 occlusionsOnOff. page addMorph: t2. t1 setSuccessor: t2. t2 setPredecessor: t1. ball := CircleMorph new. ball bounds: (160@160 corner: 240@240). page addMorph: ball. page openInWorld
Nice! 2016-04-06 12:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 06-04-16 10:36, Nicolai Hess wrote:
In what use cases is this a problem ? (Paragraph and DisplayScanner have good support for justified text (left / right / center), indentation wrapping and (I don't know if this works in pharo anymore but squeak had) even filling text in arbitary shaped polygons ( that was pretty cool). And even for text of different size and with different emphasis.
|t1 t2 ball page| page := Morph new. page bounds: (100@100 corner: 300@300). page color: Color gray. t1 := TextMorph new. t1 autoFit:false. t1 bounds: (105@105 corner: 195@295). t1 backgroundColor: Color white. t1 occlusionsOnOff. page addMorph: t1. t2 := TextMorph new. t2 autoFit: false. t2 bounds: (205@105 corner: 295@295). t2 backgroundColor: Color white. t2 occlusionsOnOff. page addMorph: t2. t1 setSuccessor: t2. t2 setPredecessor: t1. ball := CircleMorph new. ball bounds: (160@160 corner: 240@240). page addMorph: ball. page openInWorld
What are the main problems with Text, Paragraph, ... and other old TextComponents? And how are these solved with TxText? Stephan Eggermont wrote
|t1 t2 ball page| page := Morph new. ...
Yes, this example brackets the situation quite nicely. The current text system "makes hard things easy, and the easy things impossible". Text winding around little Morphic tubes, while the coolest thing ever, is rarely useful, but try changing the caret and you will end up in hell: [rant]I find the whole text system very confusing. What the heck does a paragraph know about insertion points?? A view has one paragraph object, even if there are several paragraphs (as understood by the rest of humanity as a block of text with breaks between the adjoining ones. Editors and Paragraphs are thrown out and replaced on a whim. I'm finding it very hard to understand and modify[/rant] [1] [rant] Of course, the instant I touched Paragraph/XxxEditor, and friends I got lost down the rabbit hole of incomprehensibility... like Paragraph, which draws the cursor and keeps track of the selection, obviously... not! wtf ?! Quick definition... paragraph |ËparÉËgraf| noun a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering. Where, tell me, does it say anything about cursors and selections?? [/rant] [2] 1. http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tt464024... 2. http://forum.world.st/Re-Vim-Keys-tt4657381.html#a4657594 ----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888748.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I have two or three Moleskine books full of notes about all of this text stuff. Still a maddening thing to deal with. Especially when you send wrong things and the whole UI freezes all over. Phil On Wed, Apr 6, 2016 at 7:31 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
What are the main problems with Text, Paragraph, ... and other old TextComponents? And how are these solved with TxText? Stephan Eggermont wrote
|t1 t2 ball page| page := Morph new. ...
Yes, this example brackets the situation quite nicely. The current text system "makes hard things easy, and the easy things impossible". Text winding around little Morphic tubes, while the coolest thing ever, is rarely useful, but try changing the caret and you will end up in hell:
[rant]I find the whole text system very confusing. What the heck does a paragraph know about insertion points?? A view has one paragraph object, even if there are several paragraphs (as understood by the rest of humanity as a block of text with breaks between the adjoining ones. Editors and Paragraphs are thrown out and replaced on a whim. I'm finding it very hard to understand and modify[/rant] [1]
[rant] Of course, the instant I touched Paragraph/XxxEditor, and friends I got lost down the rabbit hole of incomprehensibility... like Paragraph, which draws the cursor and keeps track of the selection, obviously... not! wtf ?!
Quick definition... paragraph |ËparÉËgraf| noun a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering.
Where, tell me, does it say anything about cursors and selections?? [/rant] [2]
1.
http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tt464024... 2. http://forum.world.st/Re-Vim-Keys-tt4657381.html#a4657594
----- Cheers, Sean -- View this message in context: http://forum.world.st/TxText-model-tp4888199p4888748.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 06-04-16 19:31, Sean P. DeNigris wrote:
[rant]I find the whole text system very confusing. What the heck does a paragraph know about insertion points?? A view has one paragraph object, even if there are several paragraphs (as understood by the rest of humanity as a block of text with breaks between the adjoining ones. Editors and Paragraphs are thrown out and replaced on a whim. I'm finding it very hard to understand and modify[/rant] [1] [rant] Of course, the instant I touched Paragraph/XxxEditor, and friends I got lost down the rabbit hole of incomprehensibility... like Paragraph, which draws the cursor and keeps track of the selection, obviously... not! wtf ?!
There is both a lot of inherent, as well as accidental complexity there. Paragraph is obviously not such a good name for what it does, but at least it has a clear comment saying what it's for. It seems the right place to deal with the display parts of selection, though delegating that to a separate class might clean up things a bit. The number of things that are just broken is rather annoying as is the lack of tests and examples. Stephan
Hi 2016-04-06 9:07 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?
I don't want to write crappy words. But to understand what was wrong you can try with them: - remove blinking cursor for specific morph instance - hide selection or change it color for specific morph instance - implement validation for input when only digits are allowed - implement masked fields - try to make all this composable It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.
On 6 April 2016 at 11:56, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
2016-04-06 9:07 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?
I don't want to write crappy words. But to understand what was wrong you can try with them:
- remove blinking cursor for specific morph instance - hide selection or change it color for specific morph instance - implement validation for input when only digits are allowed - implement masked fields - try to make all this composable
It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.
Yes, Denis, that was i did not mentioned. But as i said my main focus was not trying to fix all of the above , but to enable vector-based rendering for text. The rest was coming as a bonus and future work. Because else, all of it worth nothing if you cannot even render text with Athens.. -- Best regards, Igor Stasenko.
On Wed, Apr 6, 2016 at 11:02 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 April 2016 at 11:56, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
2016-04-06 9:07 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?
I don't want to write crappy words. But to understand what was wrong you can try with them:
- remove blinking cursor for specific morph instance - hide selection or change it color for specific morph instance - implement validation for input when only digits are allowed - implement masked fields - try to make all this composable
It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.
Yes, Denis, that was i did not mentioned. But as i said my main focus was not trying to fix all of the above , but to enable vector-based rendering for text. The rest was coming as a bonus and future work. Because else, all of it worth nothing if you cannot even render text with Athens..
I tried to do some decent hypertext and noticed that features that allowed to do this in Squeak were scrapped (for good reason, but still). And yeah, for long chunks of text... that's a big no no. Note that ParagraphEditor gets recreated all the time. And that rendering of text when there is bold text + italic + normal just didn't aligned properly on the computed text metrics (with StrikeFont at the time, I do not know if this is solved with TrueType fonts and Cairo). Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings. Doru did something for Pillar at one point (apparently using PetitParser and island parser). I am also looking at Grafoscopio but need more time to understand what's in it. Still TxText is a good thing to have. We must have proper text management for such an OO platform. They manage to do things in Jetbrains tools (IDEA, WebStorm...) and that's pure Java/Swing (from what I know having worked extensively in Swing at one point is that internals of Swing are also messy, but less, and in other ways) Doable then. Big hopes in Bloc/Brick here, will try to do my ideas again with them. Phil
-- Best regards, Igor Stasenko.
On 06-04-16 11:13, phil@highoctane.be wrote:
Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings.
Styling with different stylers worked in TextMorph. In Squeak it is easy to add styling for a different language in the class browser. Levente did that for PostgreSQLv3. Stephan
Ok. Call me stupid but in Pharo I don't see how to do that easily. Phil On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 06-04-16 11:13, phil@highoctane.be wrote:
Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings.
Styling with different stylers worked in TextMorph. In Squeak it is easy to add styling for a different language in the class browser. Levente did that for PostgreSQLv3.
Stephan
2016-04-06 18:11 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Ok. Call me stupid but in Pharo I don't see how to do that easily.
Phil
At least for Rubric, it can not be that difficult. I saw a GT-Inspector with a XML-styer
On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 06-04-16 11:13, phil@highoctane.be wrote:
Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings.
Styling with different stylers worked in TextMorph. In Squeak it is easy to add styling for a different language in the class browser. Levente did that for PostgreSQLv3.
Stephan
The only thing required for styling is to specify the attributes for the runs associated with the text. A simple example: | text attributes oldRuns clr| text := (String loremIpsum: 1234) asText. attributes := Array new: text size. clr := TextColor color: Color random. 1 to: text size do: [ :index | attributes at: index put: { clr. TextFontChange font2 }. (text at: index) isSeparator ifTrue: [ clr := TextColor color: Color random ] ]. text runs: (RunArray newFrom: attributes). text Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Wednesday, April 6, 2016 8:23 PM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] TxText model 2016-04-06 18:11 GMT+02:00 phil@highoctane.be<mailto:phil@highoctane.be> <phil@highoctane.be<mailto:phil@highoctane.be>>: Ok. Call me stupid but in Pharo I don't see how to do that easily. Phil At least for Rubric, it can not be that difficult. I saw a GT-Inspector with a XML-styer On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont <stephan@stack.nl<mailto:stephan@stack.nl>> wrote: On 06-04-16 11:13, phil@highoctane.be<mailto:phil@highoctane.be> wrote: Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings. Styling with different stylers worked in TextMorph. In Squeak it is easy to add styling for a different language in the class browser. Levente did that for PostgreSQLv3. Stephan
On 6 April 2016 at 21:49, Henrik Nergaard <henrik.nergaard@uia.no> wrote:
The only thing required for styling is to specify the attributes for the runs associated with the text.
A simple example:
| text attributes oldRuns clr|
text := (String loremIpsum: 1234) asText.
attributes := Array new: text size.
clr := TextColor color: Color random.
1 to: text size do: [ :index |
attributes at: index put: {
clr.
TextFontChange font2
}.
(text at: index) isSeparator ifTrue: [ clr := TextColor color: Color random ]
].
text runs: (RunArray newFrom: attributes).
text
Same for TxText: | text selection | text := (String loremIpsum: 1234) asTxModel. selection := text newSelection. "set font to whole text" selection applyAttribute: (TxFontAttribute with: MyFont). selection end moveToStart. [ selection end isAtEnd ] whileFalse: [ selection end moveDown. selection applyAttribute: (TxForeColorAttribute with: Color random). selection start: selection end. ]. text editInWindow
Best regards,
Henrik
*From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf Of *Nicolai Hess *Sent:* Wednesday, April 6, 2016 8:23 PM *To:* Pharo Development List <pharo-dev@lists.pharo.org> *Subject:* Re: [Pharo-dev] TxText model
2016-04-06 18:11 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
Ok. Call me stupid but in Pharo I don't see how to do that easily.
Phil
At least for Rubric, it can not be that difficult. I saw a GT-Inspector with a XML-styer
On Wed, Apr 6, 2016 at 5:41 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 06-04-16 11:13, phil@highoctane.be wrote:
Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings.
Styling with different stylers worked in TextMorph. In Squeak it is easy to add styling for a different language in the class browser. Levente did that for PostgreSQLv3.
Stephan
-- Best regards, Igor Stasenko.
2016-04-06 10:56 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi
2016-04-06 9:07 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
What are the main problems with Text, Paragraph, ... and other old TextComponents?
I don't want to write crappy words. But to understand what was wrong you can try with them:
- remove blinking cursor for specific morph instance - hide selection or change it color for specific morph instance - implement validation for input when only digits are allowed - implement masked fields - try to make all this composable
It seems that first two items are really simple tasks. But it is huge pain and hacks at the end.
Thanks Denis, yes this are good points I didn't thought about.
On 4 April 2016 at 15:44, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
Nope. Text processing was never on radar of my interests. And fact that we can reproduce same functionality in our environment won't bring us anywhere closer to LaTex or any other word-processing beasts. As i said, being able to make rocket engine doesn't means you can travel to the Moon. Or Mars. Yes, it is minimal requirement.. but just one of many. -- Best regards, Igor Stasenko.
2016-04-04 15:10 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 15:44, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Have you really looked into what is the core of the TeX algorithm? The fact that an interactive version of it was done multiple times in history? (Self / InterViews to cite the ones I know and have used)
Nope. Text processing was never on radar of my interests. And fact that we can reproduce same functionality in our environment won't bring us anywhere closer to LaTex or any other word-processing beasts.
Ok. Sending you over to the TeX algorithm was not a good idea ;) I agree with you that copying those is not a good idea. Now, extending TxText (or doing something that handles Pillar better) is not redoing LaTeX.
As i said, being able to make rocket engine doesn't means you can travel to the Moon. Or Mars. Yes, it is minimal requirement.. but just one of many.
Regards, Thierry
-- Best regards, Igor Stasenko.
Oh, and aside all of that.. Making a full-fledged word processor is not just a regular engineering task. You need an expert of publishing, expert in fonts and typography. That's right from the beginning. And i am not that expert in this domain(s). So, next time, when we start talking about things like page layouts, columns, margins, tabs, references and other stuff, first find an expert who will be able to transform these terms into technical requirements. If you think it so simple, it is not: because all those terms came from paper-publishing domain, that existed even before first computer came to existence. The capabilities of TxText and whether it will be capable to handle well complexities of full-fledged word processing features, at this point, without having an expert is nothing but just a speculation. On 4 April 2016 at 15:24, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 April 2016 at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-04-04 13:18 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
If it is for Pillar, then you don't really need a full-fledged, paper oriented layout engine. A web-like layout environment is probably enough, and much less costly to build.
Now count, how much world-wide resources are dedicated to web-based and browser-based technology development and compare with our resource base. I think it is foolish to set an unrealistic goals.
For me the problem with the TxText model is that it blocks the
possibility of doing that later, if and when there is enough development capacity to invest in this.
There is enough technology in the Pharo universe to do it (or at least something approaching). Sometimes, what you need is the ideas / the rationale from a project to do it. And I do believe TxText has some of it, even if you consider that TxText can't be extended to do it (and I'll consider that you are right on this).
Now, it's on nobody's roadmap, so it may take a while to emerge (if it does at all).
Last time, i installed LaTex package on my mac, it took maybe hour or so.. About 1Gb of files, tools, compilers, GUI, text editors.. Now think, how much years it would take to get remotely close to such level of development? And where are those people or money that would allow us to think this is viable path and we should throw everything into it to get there? It is nice to dream time to time, but let us be realistic.
Thierry
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
2016-04-04 14:49 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Oh, and aside all of that.. Making a full-fledged word processor is not just a regular engineering task. You need an expert of publishing, expert in fonts and typography. That's right from the beginning.
That's why I said that I believe the shortcut is to not focus on the paper-like; for pillar, just use a pdf converter (latex output or whatever).
And i am not that expert in this domain(s).
Neither am I.
So, next time, when we start talking about things like page layouts, columns, margins, tabs, references and other stuff, first find an expert who will be able to transform these terms into technical requirements. If you think it so simple, it is not: because all those terms came from paper-publishing domain, that existed even before first computer came to existence. The capabilities of TxText and whether it will be capable to handle well complexities of full-fledged word processing features, at this point, without having an expert is nothing but just a speculation.
And a lot of time... agreed. Thierry
On 04-04-16 14:49, Igor Stasenko wrote:
Oh, and aside all of that.. Making a full-fledged word processor is not just a regular engineering task. You need an expert of publishing, expert in fonts and typography. That's right from the beginning. And i am not that expert in this domain(s). So, next time, when we start talking about things like page layouts, columns, margins, tabs, references and other stuff, first find an expert who will be able to transform these terms into technical requirements. If you think it so simple, it is not: because all those terms came from paper-publishing domain, that existed even before first computer came to existence. The capabilities of TxText and whether it will be capable to handle well complexities of full-fledged word processing features, at this point, without having an expert is nothing but just a speculation.
I know enough about typesetting and producing technical documentation. Stephan
2016-04-04 16:04 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 15:49, Thierry Goubier wrote:
Are you thinking of writing a text typesetting engine in Pharo?
Would I like to? Sure. Don't know how to finance that, though.
Framemaker-like or web-page like? Thierry
Stephan
2016-04-04 17:10 GMT+02:00 Stephan Eggermont <stephan@stack.nl>:
On 04-04-16 16:49, Thierry Goubier wrote:
Framemaker-like or web-page like? Thierry
Framemaker.
Really challenging. Did you had a look at the Doc code (of Design Pattern fame)? It has allways been freely available. Thierry
On 4 April 2016 at 17:21, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Did you had a look at the Doc code (of Design Pattern fame)? It has allways been freely available.
no, what is it? do you have a link? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Le 04/04/2016 22:02, Damien Pollet a écrit :
On 4 April 2016 at 17:21, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Did you had a look at the Doc code (of Design Pattern fame)? It has allways been freely available.
no, what is it? do you have a link?
It's an old WYSIWIG text editor written in C++, implementing the TeX typesetting, and source of a bunch of patterns of the Design Patterns book (flyweight for character glyphs). It was a part of the InterViews toolkit (J. Vlissides et al), and was maintained (and is still maintained) as ivtools (http://www.ivtools.org). Somewhere in there one could find a way to build Doc, but I can't find it anymore. Haven't built it in more than ten years... Thierry
Le 04/04/2016 22:02, Damien Pollet a écrit :
On 4 April 2016 at 17:21, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Did you had a look at the Doc code (of Design Pattern fame)? It has allways been freely available.
no, what is it? do you have a link?
Found it: it's in the original InterViews tar file: http://www.ivtools.org/ivtools/faq.html#whataboutdoc And, as they say: it should built against the interviews library in ivtools. Someone with a stackoverflow account could complement the answers :) http://stackoverflow.com/questions/4829227/gang-of-four-lexi-editor-c-source Regards, Thierry
On 4 April 2016 at 16:41, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-04-16 14:49, Igor Stasenko wrote:
Oh, and aside all of that.. Making a full-fledged word processor is not just a regular engineering task. You need an expert of publishing, expert in fonts and typography. That's right from the beginning. And i am not that expert in this domain(s). So, next time, when we start talking about things like page layouts, columns, margins, tabs, references and other stuff, first find an expert who will be able to transform these terms into technical requirements. If you think it so simple, it is not: because all those terms came from paper-publishing domain, that existed even before first computer came to existence. The capabilities of TxText and whether it will be capable to handle well complexities of full-fledged word processing features, at this point, without having an expert is nothing but just a speculation.
I know enough about typesetting and producing technical documentation.
And i have no idea what typesetting means. I can only guess , since it is compound from familiar 'type' and 'setting' words. And technical documentation.. now i start having a headache :)
Stephan
-- Best regards, Igor Stasenko.
On Apr 4, 2016 3:54 PM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 4 April 2016 at 16:41, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-04-16 14:49, Igor Stasenko wrote:
Oh, and aside all of that.. Making a full-fledged word processor is not just a regular engineering task. You need an expert of publishing,
expert
in fonts and typography. That's right from the beginning. And i am not that expert in this domain(s). So, next time, when we start talking about things like page layouts, columns, margins, tabs, references and other stuff, first find an expert who will be able to transform these terms into technical requirements. If you think it so simple, it is not: because all those terms came from paper-publishing domain, that existed even before first computer came to existence. The capabilities of TxText and whether it will be capable to handle well complexities of full-fledged word processing features, at this point, without having an expert is nothing but just a speculation.
I know enough about typesetting and producing technical documentation.
And i have no idea what typesetting means. I can only guess , since it is compound from familiar 'type' and 'setting' words. And technical documentation.. now i start having a headache :)
Is TxText part of the image? Any configuration? Phil
Stephan
-- Best regards, Igor Stasenko.
2016-04-04 16:02 GMT+02:00 philippe.back@highoctane.be < philippe.back@gmail.com>:
On Apr 4, 2016 3:54 PM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 4 April 2016 at 16:41, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-04-16 14:49, Igor Stasenko wrote:
Oh, and aside all of that.. Making a full-fledged word processor is not just a regular engineering task. You need an expert of publishing,
expert
in fonts and typography. That's right from the beginning. And i am not that expert in this domain(s). So, next time, when we start talking about things like page layouts, columns, margins, tabs, references and other stuff, first find an expert who will be able to transform these terms into technical requirements. If you think it so simple, it is not: because all those terms came from paper-publishing domain, that existed even before first computer came to existence. The capabilities of TxText and whether it will be capable to handle well complexities of full-fledged word processing features, at this point, without having an expert is nothing but just a speculation.
I know enough about typesetting and producing technical documentation.
And i have no idea what typesetting means. I can only guess , since it is compound from familiar 'type' and 'setting' words. And technical documentation.. now i start having a headache :)
Is TxText part of the image?
It is. Five packages, 1609 + 2647 lines of code (excluding tests and styler). I think Denis has worked on it (and extended it). Thierry
Any configuration?
Phil
Stephan
-- Best regards, Igor Stasenko.
2016-04-04 16:11 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
It is. Five packages, 1609 + 2647 lines of code (excluding tests and styler).
I think Denis has worked on it (and extended it).
History was that: At some point I realised that I can't use old TextMorph anymore. For my project I needed flexible editors which allows me implement validation, mask fields, secrete fields and others. It was almost impossible to hack old text morph to support these features. I read about Igor project TxText. It included only model at that time which was very similar to my ideas. So I decided to implement editors on top of it. I was try to not touch model itself and only fix bugs. But during development I saw all weakness of model and I start refactoring with idea of active text which announces any changes. And in same time Igor returned to this project. He saw all problems with model and started refactoring too. But his idea was opposite to my. At the end I forked my refactored version of TxText into separate project Twisty. So I think current TxText not includes any my code.
2016-04-04 16:47 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
2016-04-04 16:11 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
It is. Five packages, 1609 + 2647 lines of code (excluding tests and styler).
I think Denis has worked on it (and extended it).
History was that: At some point I realised that I can't use old TextMorph anymore. For my project I needed flexible editors which allows me implement validation, mask fields, secrete fields and others. It was almost impossible to hack old text morph to support these features. I read about Igor project TxText. It included only model at that time which was very similar to my ideas. So I decided to implement editors on top of it. I was try to not touch model itself and only fix bugs. But during development I saw all weakness of model and I start refactoring with idea of active text which announces any changes. And in same time Igor returned to this project. He saw all problems with model and started refactoring too. But his idea was opposite to my. At the end I forked my refactored version of TxText into separate project Twisty. So I think current TxText not includes any my code.
Twisty renders only on Athens too? Twisty is on Smalltalkhub, right? Thierry
On 4 April 2016 at 17:47, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-04-04 16:11 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
It is. Five packages, 1609 + 2647 lines of code (excluding tests and styler).
I think Denis has worked on it (and extended it).
History was that: At some point I realised that I can't use old TextMorph anymore. For my project I needed flexible editors which allows me implement validation, mask fields, secrete fields and others. It was almost impossible to hack old text morph to support these features. I read about Igor project TxText. It included only model at that time which was very similar to my ideas. So I decided to implement editors on top of it. I was try to not touch model itself and only fix bugs. But during development I saw all weakness of model and I start refactoring with idea of active text which announces any changes. And in same time Igor returned to this project. He saw all problems with model and started refactoring too. But his idea was opposite to my.
I would not say it opposite. You see, you started implementing advanced features, right from the beginning, while we didn't even finished the basic set of features, like simple text input/editing. The only 'opposite' to your direction was decision to stop thinking upfront how much steroids we can put into model & editor and concentrate on completing a bare bone feature set, so that we can replace morphic text editor with it. Adding steroids can wait :)
At the end I forked my refactored version of TxText into separate project Twisty. So I think current TxText not includes any my code.
Glad to hear that you did not thrown away your project.
-- Best regards, Igor Stasenko.
2016-04-04 17:16 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
Glad to hear that you did not thrown away your project.
If you skip my announcement it here http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-November/116.... And look at videos.
On Apr 4, 2016 4:24 PM, "Sven Van Caekenberghe" <sven@stfx.eu> wrote:
On 04 Apr 2016, at 16:02, philippe.back@highoctane.be <
philippe.back@gmail.com> wrote:
Is TxText part of the image?
Try (in 5.0):
TxViewContainer exampleOneLineEditor.
TxViewContainer editText: 'Philippe Back'.
Thx Sven. I'll try that out. Phil
Sven
On 4 April 2016 at 14:18, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
AFAIK there are a lot of car drivers.. does it means Pharo should focus development towards needs of car drivers? :)
For me the problem with the TxText model is that it blocks the possibility of doing that later, if and when there is enough development capacity to invest in this.
Why you have such impression? I just said that primary focus was to deliver model that works fine for our current needs. For something more sophisticated simply we had no resources. Take that into account. I had no focus or plans for turning model into full-fledged word processor in future. Right. But i don't see how the model could block such development, if such need would arise at some point. If you have doubts about model, feel free to point it out and we can discuss details.
Stephan
-- Best regards, Igor Stasenko.
2016-04-04 14:14 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 4 April 2016 at 14:18, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo.
I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
AFAIK there are a lot of car drivers.. does it means Pharo should focus development towards needs of car drivers? :)
For me the problem with the TxText model is that it blocks the possibility of doing that later, if and when there is enough development capacity to invest in this.
Why you have such impression? I just said that primary focus was to deliver model that works fine for our current needs. For something more sophisticated simply we had no resources. Take that into account.
I had no focus or plans for turning model into full-fledged word processor in future. Right. But i don't see how the model could block such development, if such need would arise at some point.
If you have doubts about model, feel free to point it out and we can discuss details.
I was hoping for that sentence ! Regards, Thierry
Stephan
-- Best regards, Igor Stasenko.
On 4 April 2016 at 16:31, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-04-16 14:14, Igor Stasenko wrote:
If you have doubts about model, feel free to point it out and we can discuss details.
As a text storage model it works pretty well. My major concerns are with the line-breaking.
Go on.. elaborate your concern. I will gladly answer.
Stephan
-- Best regards, Igor Stasenko.
On 04-04-16 13:18, Stephan Eggermont wrote:
On 04-04-16 11:58, Igor Stasenko wrote:
Apart from being 'cool to have', full-fledged word processing is not a thing, that you dealing with on a daily basis in environment, like Pharo. I'm sure that is the case for you. I wonder if that is the case for many Pharo users. AFAIK there are a lot of pillar users.
For me the problem with the TxText model is that it blocks the possibility of doing that later, if and when there is enough development capacity to invest in this. Sorry Igor, I got confused by the moveDown: of TxTextPosition, and only later realized there is TxAthensLayoutPosition. I retract that statement.
Stephan
participants (13)
-
Ben Coman -
Damien Pollet -
Denis Kudriashov -
Henrik Nergaard -
Igor Stasenko -
Nicolai Hess -
phil＠highoctane.be -
philippe.back＠highoctane.be -
Sean P. DeNigris -
Stephan Eggermont -
Sven Van Caekenberghe -
Thierry Goubier -
Torsten Bergmann