AmigaOS 3.2 and beyond

[boemann]

Originally Posted by Minuous

Incorporating it wholesale is not likely; it would be better to request a specific feature of it.

Indeed. Although this is very likely AmigaOS 3.4 timeline I can think of many features that we'd want to do: Separate tasks per wb-window, cut/copy/paste, (optional) tool bar, lha and zip support.

So if you guys have ideas for workbench please post them here. We will continously use the ideas to shape a grand plan (though likely not implementing before 3.4)

[kamelito]

I’ll be retired by then

[qz3fwd]

Well that is just awesome and what it should have always been. Slay the HDToolbox abomination Amiga users have suffered with for decades! Can’t wait to order the next OS release and look forward to the new tools which will make everyone’s lives easier.

[slaapliedje]

Originally Posted by klx300r

I'm more than happy with the current iBrowse and AmiSSL to visit my Amiga sites but you better have a strong CPU and lots of fast ram. As AmigaO4.1 users will tell you it's not about having a current modern web browser but having the qualified people to constantly update it

I think (and maybe more pertinent to a thread on AmigaOS 3.3) would be improvements tor Reaction, enough that IBrowse could be ported to it instead of MUI. Seems to me, since one of the advanced UI kits are part of the OS, it would eat less memory if MUI could be ditched. Granted there are tons of things depending on it, but I think IBrowse is probably the most used, no?

[slaapliedje]

Originally Posted by boemann

Indeed. Although this is very likely AmigaOS 3.4 timeline I can think of many features that we'd want to do: Separate tasks per wb-window, cut/copy/paste, (optional) tool bar, lha and zip support.

So if you guys have ideas for workbench please post them here. We will continously use the ideas to shape a grand plan (though likely not implementing before 3.4)

Ha, I always wonder what is going to happen when you start approaching 3.5? Are we going to eventually get to 3.10? (Maybe skip 3.5 and 3.9?)

[boemann]

Originally Posted by slaapliedje

Ha, I always wonder what is going to happen when you start approaching 3.5? Are we going to eventually get to 3.10? (Maybe skip 3.5 and 3.9?)

We are not diciding on that yet. Personally I would just go include 3.5 and 3.9 as skipping them would imply that the original verrsions with that number was in the same numberseries. And yes I do see 3.10 coming one day. Maybe except that with current speed that is what 20+ years into the future.

[Olaf Barthel]

Originally Posted by qz3fwd

Well that is just awesome and what it should have always been. Slay the HDToolbox abomination Amiga users have suffered with for decades!

"That is not dead which can eternal lie"

It certainly makes for one smashing example of how what used to be briefly among the best-designed tools for partitioning Amiga hard disk drives slowly but steadily lost its edge. What remained of the edge became blunt, then what was blunt acquired a shiny mirror finish surface.

Mind you, HDToolbox's shortcomings used to be its defining features: bad block remapping done entirely in software, support for interleaved storage and a rather large database for the drive models the A590, etc. supported at the time (you couldn't trust those drives in the day to tell you anything about themselves that wasn't in some way unreliable).

When hard disk drive firmware stopped being "dumb as rocks" and became more sophisticated and useful, you no longer needed all this collection of workarounds and the complex user interface which was built around it.

Sure enough, the old HDToolbox did outstay its welcome for a few decades. But it also documents how the sausage was sliced back in the day. Those who had the good misfortune of working with the code can probably tell the tallest tales of incredibly intricate and undocumented cryptic code that almost made sense, but not quite. Imagine H.P. Lovecraft becoming a software developer and you might get the general idea of how HDToolbox looks like from the inside. Except not quite as funny.

[tygre]

That story could be the content of a whole chapter in a book

[klx300r]

Originally Posted by tygre

That story could be the content of a whole chapter in a book

[aros-sg]

Originally Posted by cloverskull

Wow, those screenshots look great.

I don't know. When allowed by screenmode - a bit more color would not hurt. Here's how more than 20 years ago some prefs programs in AROS in standard OS/kickstart GUI (gadtools, boopsi, handmade stuff) looked like:

[boemann]

Originally Posted by aros-sg

I don't know. When allowed by screenmode - a bit more color would not hurt. Here's how more than 20 years ago some prefs programs in AROS in standard OS/kickstart GUI (gadtools, boopsi, handmade stuff) looked like:

It is actually a very deliberate choice that we don't use more colors. It is bad UI to overload the user with too much information to process with the eyes.

[A10001986]

Regarding timezones/locale:

(Disclaimer: I have no idea who timezones are handled in AmigaOS >3.1, so maybe this is all rubbish)

There is a good standard for defining time zones, including DST: Posix. Those are relatively easy to parse and easy to configure, here is a list: https://github.com/realA10001986/Tim.../timezones.csv (also available elsewhere)

I personally don't need a tool with a clickable world map for a selection I make exactly once. One selection for region, one for location (like in the list) would do.

[boemann]

Originally Posted by A10001986

Regarding timezones/locale:

(Disclaimer: I have no idea who timezones are handled in AmigaOS >3.1, so maybe this is all rubbish)

There is a good standard for defining time zones, including DST: Posix. Those are relatively easy to parse and easy to configure, here is a list: https://github.com/realA10001986/Tim.../timezones.csv (also available elsewhere)

I personally don't need a tool with a clickable world map for a selection I make exactly once. One selection for region, one for location (like in the list) would do.

So the prefs file format only allows us to specify a time offset. If we want to specify a timezone in the modern way we would need to extend the fileformat. It is doable for sure and AmigaOS 4 have already done something like that.

However for AmigaOS 3 we came to the consclusion that it is a step too far. Loading this huge list of timezones, that you helpfully linked to, takes up a lot memory. Remember that it basically needs to be translated to a lot of languages too.

What we really need is the timeoffset. Possibly we could also allow the user to entert daylight saving dates and by how much if we want to automate it.

So there is no real need for this huge list of timezones either. As you say it is specified so rarely.

What does count in favor of us keeping the monochrome world map is nostalgia. And also a way to quickly get a ballpark time offset from UTC.But mostly nostalgia.

[Minuous]

The linked list is useless anyway, eg. it is missing the national capital here (pop. almost half a million) but has one which is not even a state capital with under a thousand people. Similarly the second largest city in England is not included, etc. So you would generally have to already know your timezone anyway. Even the data that is provided is wrong (WTF is "Troll, Antarctica"!? :-D).

Also, the rules for when DST start and end (if at all), which particular areas are included in a certain timezone, etc. are always changing in an unpredictable manner for political reasons; therefore a one-time set of data like that, even if it was complete and correct at the time, is going to be out of date by the time the discs get pressed.

[Futaura]

Originally Posted by slaapliedje

I think (and maybe more pertinent to a thread on AmigaOS 3.3) would be improvements tor Reaction, enough that IBrowse could be ported to it instead of MUI. Seems to me, since one of the advanced UI kits are part of the OS, it would eat less memory if MUI could be ditched. Granted there are tons of things depending on it, but I think IBrowse is probably the most used, no?

There is much more to MUI than the visual element. IBrowse is built around MUI custom classes and ReAction simply does not provide a large portion of what MUI provides.

[A10001986]

OK, I gather
- a 15k list (which is created from /usr/share/zoneinfo, standard on all linux distributions, and updated on a regular basis) is "a step too far",
- changing a binary file format in shape of, what it is, 2 bytes, into a string, is trouble,
- and, oh dear, it is missing Canberra, and what the heck is "Troll/Antartica".

Thank you for your consideration!

[Lord Aga]

Originally Posted by tygre

That story could be the content of a whole chapter in a book

I grew a tentacle just by reading it

[boemann]

Originally Posted by A10001986

OK, I gather
- a 15k list (which is created from /usr/share/zoneinfo, standard on all linux distributions, and updated on a regular basis) is "a step too far",
- changing a binary file format in shape of, what it is, 2 bytes, into a string, is trouble,
- and, oh dear, it is missing Canberra, and what the heck is "Troll/Antartica".

Thank you for your consideration!

So you feel dismissed. I get that. But there there is no need to talk like that.

The change of binary file format is not a problem. I simply explained how things worked as you said you didn't know.

Also I see that what I wrote may sound like a dismissal of your specific proposal, but we had actually thought about these things several months ago.

A 15k list on it's own is not a problem, but if it has to be loaded and processed before the prefs editor can show up that can still take a while and will use up way more than 15k. Maybe 200k. This is a retro OS for retro machines.

But to be honest the biggest problem is that it is constantly changing, and we have about 20 languages that we need to translate it into, and being a retro OS delivered on disks there is no way we can keep the installation on users machines up-to-date. Would we really want to have this recurring trouble for something the user sets exactly once ?

Letting the user simply choose the offset is simple enough and will not require us to send out updates. Yes the map is horribly out of date, and is mostly there for nostalgia. We are well aware that even some towns have their own timezones.

We could spend months getting (and recurring time for updates) this list imported and working or we could do what we have decided and leave it simple, nostalgic, and future proof.

By not doing a complex solution we can spend that time on other parts of the OS instead

[tygre]

Originally Posted by A10001986

OK, I gather
- a 15k list (which is created from /usr/share/zoneinfo, standard on all linux distributions, and updated on a regular basis) is "a step too far",
- changing a binary file format in shape of, what it is, 2 bytes, into a string, is trouble,
- and, oh dear, it is missing Canberra, and what the heck is "Troll/Antartica".

Thank you for your consideration!

Hi A10001986 and all!

Not taking a position one way or another, I just wanted to mention that I've been using SetDST on my Amigas and it works very well but, as mentioned by Minuous, I had to fix the data file to adjust new daylight saving dates for Montréal

Cheers!

[boemann]

Originally Posted by tygre

Hi A10001986 and all!

Not taking a position one way or another, I just wanted to mention that I've been using SetDST on my Amigas and it works very well but, as mentioned by Minuous, I had to fix the data file to adjust new daylight saving dates for Montréal

Cheers!

Yes automation would be very nice - I'd like to implement this in the OS