Talking about filesystems, it'd great to see AROS booting and working from a FAT32 USB stick. So, having FAT32 on par with SFS for being used as "system" filesystem.

Perl? Still alive? Perhaps time to port the Perl code to Python, and modernizing the build infrastructure?
I also booted Aros on a bare metal m1 for the first time yesterday.[/quote]
Kudos! :-)

Perl is still needed by quite a bit of tools in the build toolchain.

About filesystems, I'm building a new one in the spirit of the amiga.

It's called AFS+: https://github.co...nx/afsplus

Macaros and qemu can boot on it. t will be my default filesystem for Macaros and Macaros Native.

It's now faster the FFS and should solve most problems that we have. It's written in Rust but a C99 version is on it's way.

I also wrote an ExtFAT driver from the specs, I'll share soon. Aros can boot from that and will make it easy to share things with any other platform.

Aseprite migration has been finished but the original authors have declined the exception to distribute it so I will publish source and ways to build it on AROS and switch to other projects. Very likely to LibreSprite which is a fork of Aseprite when it was still GPL.

In other news, I am having a look at font rendering in AROS:



Here is an example of smart glyph replacement: if the selected font doesn't have the required glyphs, it falls back to the next font of the same style to fill them in. So it doesn't collapse the whole font; it doesn't render blocks - it falls back graciously.

Here Open Sans is used to fill in the blanks in the Vera Sans font

(x86_64) SVG data type with the option to read, render, and WRITE SVG:
https://drive.goo...drive_link

Reading works in Multiview. Any input on modifying Multiview? From what I see Multiview writes to IFF, I'd need to change it to RAW to support saving SVG from Multiview.

Other than that - one step closer to a vector graphics editor.

MultiView doesn't save anything other than IFF which applies to the Super Class for each datatype. For SVG datatype it's Picture Datatype.

If you open an SVG in MultiView then Save As should save a copy using the save function for the datatype using the RAW method for testing.

Multiview -> I think first thing to check is whether it had ability to save to anything other then IFF on AmigaOS. In other words is this a feature that needs some compatibility considerations or it is a new feature.

MultiView doesn't convert picture types. I wanted to insert Save As PNG in the Picture Menu but I soon realized that each datatype class has its own menu. You would need to add Save As ?? to each menu & it gets messy. Better to leave it pure.

Kalamatee had the idea to use Project->Export to open the export tool of your choice. In the MultiView icon set the EXPORT= tooltype to the DTConvert Utility or any conversion utility you want. You could set it to FFMedia to convert picture types.

Similarly, I expanded the idea to use EDIT PIC= EDIT SND= EDIT TXT= in the icon tooltypes for Edit->Edit File menu item to open any editor you want. The editor can convert also.

Both Export & Edit File menu items sends the current datatype name to the application that's being opened.

It's especially useful for pictures & text. How many times have I double clicked a text file to view contents then try to edit text, not realizing it's being displayed in MultiView. Just go to Edit->Edit File and it opens the file in Jano Editor for editing. Easy!

Oh yeah! But I haven't committed my code for Save As or Edit File. I'll post the code later today if you'd like to update MultiView.

I downloaded the SVG datatype for testing. I also found some images.

My version of MultiView has Save As which uses DTWM_RAW method to save a copy of the original in the same format. But it's not an exact copy. It uses the datatype save function. It can be used for example to remove unwanted JPEG Tags or PNG Chunks. The datatype save function usually only saves the necessary data, the rest is ignored.

Package manager as a CLI and as a GUI? Yep.

BTW, which GCC is best to use to compile for v11/v1 now? I think I initially picked up the wrong setup.

For ABIv11 there is only one option - it's the default one - GCC 10.5.0. If you use the ./rebuild.sh or just plain configure + make this is what you will get.

For ABIv1 I personally also selected (via options to configure) GCC 10.5.0 to be in sync. Different ABIv1 x86_64 targets use different compilers versions in nightly builds.

Confirmed. The SVG datatype Save Function is working correctly!

The screenshot with two images is the original and the one produced by MultiView - Project->Save As.

Any other datatypes require attention? I'm tempted to write something (obviously better as an alternative to multiview for AROS including a new Zune class.

Now that you asked TIFF datatype needs a Save Function, I believe. I checked a week ago and it wasn't implemented yet. Kalamatee wrote the Load Function (s) and he was very thorough about making it nicely compatible with many TIFF types.

Picture Datatypes have been pretty much covered. Sound Datatypes are needed though. Text Datatypes may also be needed. RTF datatype may be an option for Text Class.

We don't yet have an OGG datatype for OGG Vorbis, we have Wave but no WMA. Not sure if it's possible to write a MOD datatype for Amiga Music Mods, but why not try it?

Having an MP3 Datatype would be nice, although many music players can load and play MP3 files. It would be a good challenge to write a new datatype. Lib Mpega is already part of AROS and there's another one based on Lib Mad.

For music players I might be tempted to do something next month. Is there anything we use for podcasts, streaming and radio?

DOC/DOCX, RTF and Markdown will come one way or another - I'm working on something (on a very low priority)

There are two applications that are used for streaming audio & video. AmiTube for YouTube videos & also AmiNetRadio? Not sure about the last one. But those are a good start.

If you are interested in a programming challenge AROS needs support for Drawbridge equipped Usb Floppy Drives.

Amiga OS has the Waffle Reader that Reads & Writes Disk Images using Lib USB & Lib FTDI. The Windows version of DrawBridge uses FTDI drivers to interact with the Serial COM port (FTDI device).

I thought about a Poseidon USB Class for FTDI FT232R (the chip used in DrawBridge?). Either an FTDI Class Driver or Lib FTDI is needed. And the a GUI for the Disk Reader/ Writer like Amiga OS has already.

No hardware to experiment with. It's not a must-have if someone else has the hardware - just slow.