I haven't read the whole thread yet, so if this has been suggested, my apologies.


Instead of having different syntax highlighters hard coded, make it so the end user can create syntax highlighting. This way Amos, Blitz, C++ etc can all have syntax highlighting created.

This is IO intensive and slowest part of the system, better would be to recategorize types in scheduled( requires an OS scheduler) in system/IO idle time.

Speaking of which, OS scheduler for scripts like crontab?

That's actually in there, to eventually have a data-driven syntax highlighting model. But it's not for 3.2, and maybe not for 3.3 either.

Since reaction is coming how about an updated and enhanced Toolmaker to design Reaction GUI?
Protect RAD drives using MMU if présent.

I'm sure it's too late, but wondering if you are in need of any more beta testers?

My Hardware:

• A1200 OS 3.1.4
• 128GB PATA SSD
• Phase 5 BPPC with 060 and BVision card
• Indivision AGA
• FastATA IV
• Flash Floppy instead of physical floppy drive

I was a betat tester for Directory Opus on PC, and have a long history of using cutting edge software (ie. new stuff in beta phases).

That's not a job for people working on the OS, though, imo.. ;)

Hi,

For all those who wish to participate on the AmigaOS (68k) project as a beta tester, developer, or can help in a lot of Norsk and Dutch translations, please contact me by PM or at my email, available in my user profile.

Thanks

@Gulliver
PM sent

It was a CBM product developed by a guy I forgot the name, not sure if they still have the source code and rights.

The developer's name was Michael Erwin and "ToolMaker" was in development during 1991-1992 until it seems to have ground to a halt. Archival copies of the source code for "ToolMaker" exist, but it's hard to tell which state of development the application is in. The most up to date version seems to go back to July 1992.

Back when the "ToolMaker" was in development hints were dropped regularly that there was something coming to help in building applications and their user interfaces (InterfaceBuilder on NeXTstep being the inspiration), but those hints eventually stopped.

At this time more research into what the most recent source code can do would be needed. There must be a reason why the project came to a halt years before Commodore eventually went out of business.

I tried Toolmaker and it runs under AmigaOS 3.2.

I was able to open a window and make the program generate its C code.
Seems to have quite some functionality built-in.



http://imgur.com/83kqhxS

http://imgur.com/Jbkuk5Q

Anything to make it easier for people to develop new software has to be welcomed.

If it works it is a first step in the right direction.
To add fuel to my previous wishes, here a excerpt of the CD32 dev docs :

"Writing OS-friendly games benefits you, the developer, and the gamers who buy your games. It
ensures the viability of your code on all Amiga platforms, not just the one you used for development.
By allowing the OS to do the mundane details of opening screens and windows, you give yourself
more time to do the creative portions of your game. It does not matter how fast your game is if the
gameplay is lousy and the artwork looks amateurish.
An OS-friendly game is no longer something to be avoided. We’ve provided ample tools in the OS to
support your gaming needs, and we will continue to do so. To get you started, the examples on the
folowing pages show you how to set up your own View and ViewPort in both C and assembly
language. The sooner you write OS-friendly games, the sooner you’ll be prepared for the future."

"Writing
OS-Friendly
Games 33
Many Amiga programmers believe that the only way to write a whiz-bang, speed-of-light game is to
bypass the operating system and go straight to the hardware. A better approach is to write games that
are OS-friendly. The combination of the AA chipset and the latest V40 system software make
system-friendly solutions more possible than ever.
Why Use the Operating System?
Here are some reasons to use the OS for games:
? OS code runs out of ROM, which is faster than running equivalent code out of Chip RAM.
? Why reinvent the wheel? Spend your time doing things that only you can do.
? The OS automatically supports pre-ECS, ECS, and AA (and will support the next revision
of the Amiga chip set).
? There is less code to write. The OS has routines for handling all screen positions and
scrolls, mouse movement, etc. This means less development time and less time getting the
hardware to work, and more time making the game more playable.
? More robustness. For instance, the OS floppy disk code is far less picky about drive
parameters than 99% of custom floppy I/O code.
? Hides bugs and quirks of the chip set. The AA chip set has a few bugs which the OS hides
from you.
? Multiple platforms. OS code will run on all Amiga-based machines, whatever their flavor.
? Compatibility with future chipsets. The next revision of the Amiga chip set will not be
register-level compatible with AA.
Things the System Cannot Do
A long-term goal of the Amiga operating system is to support the common display tricks often used in
games. There are some things that can’t be done though:
? Scrolling individual scan lines of a ViewPort
? Using a copper list to fade a AA color register
? Dynamic updating of user copper lists.

All these are planned to be addressed in future OS releases. The goal is to allow these and other types
of operations within normal Intuition screens if possible."

Implement also what CBM planned for the future described in the 1993 Devcon.

That is fantastic. I don't go through Web pages, after Web pages as I know a lot of others do. I am glad to learn about the continued involvement with OS 4 developers. I have zero interest in the "flame wars". I agree, United is better. Bickering isn't solutions focused. Sure, notice the "Blllechh.." but then, don't harp on it..fix it if possible. When someone keeps focused on the negative, the mind then won't notice what can help...until a person chooses to refocus.



I'm using OS 3.1.4.1 kicked at times, still, it's pretty cool. I'm excited about 3.2. I'm still getting a big kick (joy) from the Intuition Workbench off screen ability.


I'm curious about CyberVisionPPC support. Since OS 4 team is still in contact, has that been any help in the direction of 3.2...and P96?

For ui I used GadtoolsBox 3 (its on Aminet) - it was pretty advanced modular ui designer and code generator. I believe it could be quite easily expanded to cover reaction gadgets. There is source code available and I can ask the original developer if he would like to improve it.

Not to keep this off-topic topic going, but aren't all of the ReAction code generators spew what is no longer idiomatic code? I know that's why the advice for OS4.x development is "don't use them", and I expect that ReAction in 3.2 is going to have more in common with its 4.x branch than how it was in 3.9.

We definitely could use some RAD tools for ReAction, but resurrecting the long-dead ones currently out there is probably not the best way to get them.

PM Sent, hopefully I can be a useful resource

It's probably not achievable for a 3.2 release, and pretty minor, but I'd like to see operations continue if you move or resize a window.

For example, running a script or copying large about of files in the CLI and moving/resizing the window seems to halt the operation.

@coldacid:

Unfortunately we don't have source code for ReActor so it would have to be rewritten from scratch before we could make improvements to it.

Programs built with ReActor will run on OS3.2, as long as resource.library is installed.

Yes, this is camilla´s Plan as far as I understood in the Dev-Mailinglist. Users can supply Syntax-highlighting on aminet for example.