06 November 2023, 13:22 | #1821 | |
Camilla, AmigaOS Dev.
Join Date: Mar 2020
Location: Frederiksberg
Posts: 330
|
Quote:
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) |
|
06 November 2023, 20:34 | #1822 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,853
|
I’ll be retired by then
|
07 November 2023, 01:26 | #1823 |
Registered User
Join Date: Oct 2022
Location: Shelby Township
Posts: 83
|
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.
|
07 November 2023, 02:01 | #1824 | |
Registered User
Join Date: Jul 2010
Location: Utah, USA
Posts: 517
|
Quote:
|
|
07 November 2023, 02:03 | #1825 | |
Registered User
Join Date: Jul 2010
Location: Utah, USA
Posts: 517
|
Quote:
|
|
07 November 2023, 06:30 | #1826 |
Camilla, AmigaOS Dev.
Join Date: Mar 2020
Location: Frederiksberg
Posts: 330
|
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.
|
07 November 2023, 16:21 | #1827 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
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. |
|
08 November 2023, 03:12 | #1828 |
Returning fan!
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 1,438
|
That story could be the content of a whole chapter in a book
|
08 November 2023, 08:20 | #1829 |
Registered User
Join Date: Oct 2007
Location: ManCave, Canada
Posts: 1,639
|
|
08 November 2023, 08:53 | #1830 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 192
|
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: |
09 November 2023, 10:56 | #1831 |
Camilla, AmigaOS Dev.
Join Date: Mar 2020
Location: Frederiksberg
Posts: 330
|
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.
|
10 November 2023, 11:53 | #1832 |
Registered User
Join Date: Jun 2017
Location: 1986
Posts: 79
|
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. |
11 November 2023, 18:19 | #1833 | |
Camilla, AmigaOS Dev.
Join Date: Mar 2020
Location: Frederiksberg
Posts: 330
|
Quote:
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. |
|
11 November 2023, 20:08 | #1834 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,679
|
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. Last edited by Minuous; 11 November 2023 at 20:27. |
12 November 2023, 23:32 | #1835 | |
Registered User
Join Date: Aug 2018
Location: United Kingdom
Posts: 198
|
Quote:
|
|
13 November 2023, 14:29 | #1836 |
Registered User
Join Date: Jun 2017
Location: 1986
Posts: 79
|
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! |
13 November 2023, 16:10 | #1837 |
MI clan prevails
Join Date: Jul 2010
Location: Belgrade, Serbia
Posts: 1,443
|
|
13 November 2023, 16:39 | #1838 | |
Camilla, AmigaOS Dev.
Join Date: Mar 2020
Location: Frederiksberg
Posts: 330
|
Quote:
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 |
|
13 November 2023, 16:40 | #1839 | |
Returning fan!
Join Date: Jan 2011
Location: Montréal, QC, Canada
Posts: 1,438
|
Quote:
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! |
|
13 November 2023, 16:45 | #1840 | |
Camilla, AmigaOS Dev.
Join Date: Mar 2020
Location: Frederiksberg
Posts: 330
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AmigaOS 3.1.x v 3.9 | steve_mynott | New to Emulation or Amiga scene | 35 | 19 April 2020 06:23 |
AmigaOS 3.9 | PoLoMoTo | support.WinUAE | 8 | 27 August 2011 18:06 |
AmigaOS 3.5 or 3.9 | maddoc666 | support.Apps | 12 | 22 February 2010 08:02 |
AmigaOS | koncool | request.Apps | 6 | 04 June 2003 17:45 |
AmigaOS XL | sturme | New to Emulation or Amiga scene | 4 | 15 January 2002 02:13 |
|
|