Hi trixie. I've seen some of your tutorials on Reaction. Excellent work.
trixie wrote:Perhaps I'm not getting you right but shouldn't we strive for a generic formatted (rich) text datatype? I.e. one of which rtf / ww / doc / whatever would be subclasses?
I'm thinking not so much in terms of a generic rtf datatype so much as generalising the means for providing the data.
I think the real trick is how to get the data to the app in a way that it understands and can use as much of the data as possible.
At the same time I want to give more options on how the data is delivered.
trixie wrote:As a piece chain, for example. The entire document would be represented as an Exec list, with individual nodes containing a data structure that carries a pointer to a text buffer plus formatting flags. For instance, this following formatted text
Some examples; that's what I like. You provide a wonderful example to talk about.
Here again the important thing - from a datatypes perspective - has been to construct the data in memory in such a way that the app can then read that data.
In the example you provide the app would possibly then convert this standard form to its native in-memory form.
This isn't what I want to do and this is where I talk about taking a 180° approach.
Normally we think of a program accessing a file and loading it in (or saving it out).
This is pretty much the approach the datatypes continue to follow even though they put the data in memory. My approach is to reverse that.
To give an idea you might perhaps think of the app as the 'file' and the job of the fileclass type is to send their data to our app.
We don't load the data; the data is loaded into us; but via the receiver we provide.
Then it comes down to the interfaces for doing this rather than the format.
Taking your example the fileclass type could send your app receiver a text format indicator then some text, then the next text format indicator, then some more text, etc.
But, the important thing is that it hasn't told you how to store that information and hasn't done its own interim time consuming approximation.
gonegahgah wrote:I've seen some of your tutorials on Reaction.
I'm presently just working Reaction into my early code.
Initially, long ago, I thought it was incompatible with what I had been doing, but it was nice to see that it isn't.
I see that there have been some changes to Reaction along the way but I wouldn't know if the newer changes have helped this to be?
Presently all I've done is add the text pointer subclass to the Reaction string.gadget and made the button.gadget highlight when the mouse is over them (window active or not).
Sadly, due to pointers being tied to the active window, the mouse pointer only changes when over a zone in a window that is active.
Hopefully one day the zones can be incorporated with a slightly modified Intuition to utilise a global mouse pointer (on when set; ActiveWindow's mouse when NULL) so that it works even when the window is inactive.
It's nice for the mouse to always reflect what is going to happen when you click on the gadget; even when the window is currently inactive.
I imagine that normally the app has to take more active involvement to achieve either of these two things in Reaction so I wanted to make this process much simpler.
All the Amiga OS4 prefs use Reaction so it would be nice for them to be able to add these touches without doing very much at all.
I have discovered one conundrum which I'd like to look more into (apart from the mouse pointer tied to the active window).
I was having a crash - which I've resolved now - which had to do with my disposing objects that the window object had disposed of first.
As I say, I've fixed this in my code, but it does appear to raise some considerations. It might be worth exploring this more?