AmigaOS 3.2 released!

[boemann]

Originally Posted by hth313

Having watched the video about 3.2 I must say that I am impressed.

One of the cool things is that I can finally get the 1.x look and feel back, I love it! There are many other nice things too. I never really cared about MUI so Reaction is welcome. And finally a mouse pointer editor that does not open a new low-res screen.

I have a some questions related to documentation. While it is good to have online help, I wonder about three things.

1. With RTG, is multi monitor setup supported (native plus RTG)? That could be useful when display documentation while doing other things.
2. Can I use the online documentation, like HTML or something, on (cough cough) other computers? I may do cross development and it would be useful to have it on the non Amiga computer.
3. What about printed RKM books? Is there going to be a new set?

1) RTG is not really part of the OS. You buy and install P96, but no afaik they have not really solved that yet.

2) the ndk documentation is in plain text as well as amigaguide. Both of which can be converted to something you can view outside the amiga. Also have a bit of patience. We want it on the web too.

3) There is not going to be a new set no, but and you heard it here first: Jason and I are working on a single new volume about things that have changed since the 2.x times. Obviously it is a huge undertaking so will go rather slow, but the plan is to do online drops of the the current state of the "book". For now I've written about 14 pages and I started over 1 year ago, and you know how large these books typically are so that is why we are not going to sit on it until it is completely written.

[systmcrsh]

Originally Posted by boemann

... Someone might also want to create an easier configurable plugin when non-programmers could specify the markup in some kind of configuration file. I hope to see a lot of creativity from the community

^ that seems like the ideal way to do it. i think ultraedit does it this way too... where a user creates their own markups in a config, or xml, etc., that is based on a set of markup styles/rules that ultraedit defines.

so perhaps something like a user created markup config that just identifies keywords/characters or combinations of (and wildcards), and can also specify in the same config, the type or style of markup to be applied by the editor for each user identifier. <- something like that

edit:

oh, and ultraedit automatically selects the the proper config to use based on file extension (that i think the user provides in the config), ie, hello.e, hello.c, hello.rexx, etc

edit 2: actually the file extension isn't defined in the user created config... it's the extension of the config.file that ultraedit reads in its wordlist directory... ie, wordlist/path/amigae-rules.e, wordlist/path/whateverfilename-rules.c, wordlist/path/python_RULEZ.py, perl_SUX.perl, arexx.rexx, etc

anyways, not trying to recreate ultraedit on the amiga, i just think it had a very flexible and friendly way to add any language you want, and someone might get some good ideas from it

Originally Posted by boemann

Hi So we have flype, you, and one of our betatesters interested in an E highlighter. Please pm me so I can put you in touch.

pm sent, willing to contribute in any way that i can

[boemann]

Originally Posted by systmcrsh

^ that seems like the ideal way to do it. i think ultraedit does it this way too... where a user creates their own markups in a config, or xml, etc., that is based on a set of markup styles/rules that ultraedit defines.

so perhaps something like a user created markup config that just identifies keywords/characters or combinations of (and wildcards), and can also specify in the same config, the type or style of markup to be applied by the editor for each user identifier. <- something like that

edit:

oh, and ultraedit automatically selects the the proper config to use based on file extension (that i think the user provides in the config), ie, hello.e, hello.c, hello.rexx, etc

edit 2: actually the file extension isn't defined in the user created config... it's the extension of the config.file that ultraedit reads in its wordlist directory... ie, wordlist/path/amigae-rules.e, wordlist/path/whateverfilename-rules.c, wordlist/path/python_RULEZ.py, perl_SUX.perl, arexx.rexx, etc

anyways, not trying to recreate ultraedit on the amiga, i just think it had a very flexible and friendly way to add any language you want, and someone might get some good ideas from it



pm sent, willing to contribute in any way that i can

Just keep in mind that the amiga doesn't have a powerful cpu like modern machines, so if you want something as powerful as being able to highlight based on config files the will be a performance penalty

As for automatically detecting the highlighter then TextEdit already does that too. It uses deficons to detect the type and activates the filetype based on that

[systmcrsh]

Originally Posted by boemann

Just keep in mind that the amiga doesn't have a powerful cpu like modern machines, so if you want something as powerful as being able to highlight based on config files the will be a performance penalty

my philosophy is that maybe performance penalty is ok.

it depends on what the penalty is though... is the penalty only in regards to syntax highlighting or does the penalty affect the overall experience?

maybe highlighting is off by default, or maybe highlighting is off by default but enabled by default for os-specific files (startup-sequence, etc)

my personal opinion is that any code that is part of the os should be bare-bones-stock-amiga compatible... so if it takes 30 secs to open a text file and highlight 100 lines of code on a bare bones amiga compared to a fraction of a second on an expanded amiga -> that can be the user's choice. like "hey, here's some modern stuff that is cool, but if you have a stock machine there will be a performance delay". i think people will understand that.

plus, sometimes people are patient and are willing to wait for results, especially if they are using a stock machine and choosing an option that is optional, as long as the results are consistent and accurate.

i guess i'm also curious... in what way would a config type plugin differ from any other or currently existing plugin besides memory or disk usage (performance penalty)?

i haven't received my copy of 3.2 yet and i've only seen screenshots of textedit... is it the kind of editor that auto-corrects as you type?

i think there's a blitz editor that does this... when you type something like blitzcommand and hit [space], the editor immediately corrects it to BlitzCommand

^ anyways, some opinions up there, but its just opinion, and don't wanna derail the thread so feel free to break off this reply to a separate thread if someone wants... and really looking forward to 3.2 and textedit, and everything else

Originally Posted by boemann

As for automatically detecting the highlighter then TextEdit already does that too. It uses deficons to detect the type and activates the filetype based on that

awesome!

[boemann]

Originally Posted by systmcrsh

i've only seen screenshots of textedit... is it the kind of editor that auto-corrects as you type?

i think there's a blitz editor that does this... when you type something like blitzcommand and hit [space], the editor immediately corrects it to BlitzCommand

The built in filetypes do highlighting and nothing else. However the Filetype API does allow for autocorrection to be implemented. My idea with this is so code can be auto formatted whenever you press say semicolon. This is not implemented in any filetype. but I've tested that it is possible to manipulate the text when certain keys are pressed.

A spelling corrector could indeed wait for space to be pressed and then correct the word to the left of the inserted space.

This is the part of the API I'm not 100% certain of yet.

[alancfrancis]

Originally Posted by boemann

1) you heard it here first: Jason and I are working on a single new volume about things that have changed since the 2.x times. Obviously it is a huge undertaking so will go rather slow, but the plan is to do online drops of the the current state of the "book". For now I've written about 14 pages and I started over 1 year ago, and you know how large these books typically are so that is why we are not going to sit on it until it is completely written.

This is incredibly exciting! :-). Will it be focussed on 3.1.4/3.2 and not all the other post-2.x amiga-ish OSes ?

This has been a huge issue for me getting back into programming my Amiga after 30 years, any information I can find online has to be run through a "do they mean 4.0 or 3.9 or MorphOS or ScalOS or ApolloOS or AROS or WinUAE or PPC or is this something I can actually use on my physical 3.1 Amiga ?" filter.

Would be great to have a more modern 3.1/3.2 development guide.

[boemann]

Originally Posted by alancfrancis

This is incredibly exciting! :-). Will it be focussed on 3.1.4/3.2 and not all the other post-2.x amiga-ish OSes ?

This has been a huge issue for me getting back into programming my Amiga after 30 years, any information I can find online has to be run through a "do they mean 4.0 or 3.9 or MorphOS or ScalOS or ApolloOS or AROS or WinUAE or PPC or is this something I can actually use on my physical 3.1 Amiga ?" filter.

Would be great to have a more modern 3.1/3.2 development guide.

It will be 3.0/3.1/3.1.4/3.2

[Phantasm]

i do a lot of coding in Amiga E and I made a highlighter configuration for notepad++ that might be useful as a reference

https://drive.google.com/file/d/13t8...ew?usp=sharing

[boemann]

I've made a project on gitlab which contains an example filetype plugin. There is currently no makefile. Feel free to contribute on. In general I don't intend to contribute much going forward but will obviously follow along to make sure it get's a good start and that all the initial questions gets answered.

https://gitlab.com/boemann/texteditfiletypeplugins

[alancfrancis]

Originally Posted by boemann

It will be 3.0/3.1/3.1.4/3.2

THERE WAS MUCH REJOICING.

If you need any help from a review or amiga newb perspective I'd be delighted :-)

[boemann]

Jason and I have begun writing on this.

https://www.retro-commodore.eu/rkrm-...Mmt_o0EsY4WELk

We'd appreciate feedback

[PeterK]

Originally Posted by boemann

Jason and I have begun writing on this.

https://www.retro-commodore.eu/rkrm-...Mmt_o0EsY4WELk

Wow, that's great!

But it's also a lot of hard work. I recently tried to write a small guide file for my icon.library, but after 30-40% I already lost my motivation to continue and finish it.

[boemann]

Originally Posted by PeterK

Wow, that's great!

But it's also a lot of hard work. I recently tried to write a small guide file for my icon.library, but after 30-40% I already lost my motivation to continue and finish it.

Yes there is a real risk of that, but at least we will have written what we have, and hopefully it will help developers out there

[robinsonb5]

Originally Posted by boemann

We'd appreciate feedback

Looks great - it's detailed without being overwhelming, it's well presented - excellent!

[digiflip]

if anyone likes to use xbench on amiga os 3.2 worked out to get working. you need to copy execute from amiga os 3.1 c folder to amiga os 3.2 c folder.

[digiflip]

does anyone know when remus be updated to support 3.2 kickstart roms and begin the one meg custom kickstarts lol

[alancfrancis]

Originally Posted by boemann

Jason and I have begun writing on this.

https://www.retro-commodore.eu/rkrm-...Mmt_o0EsY4WELk

We'd appreciate feedback

This is a fantastically positive start :-). It seems like exactly what I was looking for when I blew the dust off my A1200 and put the new OS on it. I really appreciate the "tutorial" feel of it, and the sample code. Much more readable than a list of API details like the van den Oosterkamp book (which I have to say was still very useful).

If there's a way to pay for it early, and watch out develop, like the pragmatic programmers beta books, or lean-pub or something, I'd be absolutely up for that.

Thanks for all your hard work!

Alan

[boemann]

Originally Posted by PeterK

Wow, that's great!

Originally Posted by robinsonb5

Looks great - it's detailed without being overwhelming, it's well presented - excellent!

Originally Posted by alancfrancis

This is a fantastically positive start :-). It seems like exactly what I was looking for when I blew the dust off my A1200 and put the new OS on it. I really appreciate the "tutorial" feel of it, and the sample code. Much more readable than a list of API details like the van den Oosterkamp book (which I have to say was still very useful).

If there's a way to pay for it early, and watch out develop, like the pragmatic programmers beta books, or lean-pub or something, I'd be absolutely up for that.

Thanks for all your hard work!

Alan

Thanks all of you for the encouraging reception - we will continue

[digiflip]

found an hacky way to use best classic wb with 3.2 install cd atop of an clean 3.14 made best classic wb hdf [ Show youtube player ]

[Rotzloeffel]

Originally Posted by boemann

1) RTG is not really part of the OS. You buy and install P96, but no afaik they have not really solved that yet.

Picasso96 will support this in the next version.... There are some minor issues on Cybervision-3D in a Zorro3 Machine. But Thomas will solve them and I will do more testing... actually works with native Screen and RTG on a Z2 machine


Further testing required actually.....