None of those are good enough. Just a simple process bar at the bottom is what's needed. You can see all windows at the same time and there's no extra steps you have to go through to select a window.
Er... SFS is loaded with the kickstart. If one file in Kickstart cannot be loaded, then you have a much bigger problem than your SFS partitions.
There are no obscure reasons whatsoever you would be able to boot at all but SFS would not load.
Let's assume that it's just a problem with just the SYS:Kickstart/SmartFileSystem file: wouldn't the FS stored in the RDB make for a good fallback FS? Another question: if the HD were attached to a Classic Amiga without AOS 4.x, wouldn't the FS enable the mounting of the partition (think of data recovery)? (Yeah, I know, these are definitely extreme cases...)
About AmiStart author and why it's been difficult to reach him.
I read a post on aros-exec.org recently from him where he had been in an accident (can't remember exactly) and had been in recovery for many months, and hence could not respond to mails or code.
So maybe there will be some updates when he is feeling better.
More not so serious issues: - softlinks to drawers are displayed just like drawers in WB TextMode (but are correctly handled in ASL requesters); - makelink does not trigger updating of WB listers; - Amidock background is not 100% transparent when Icon area is set to Transparent or Transparency is set to 100% (behaviour differs); - menus transparency is still fake (not a bug, though); - E-UAE crashes when stack is not big enough (wasn't automatic stack enlargement implemented?)
AccessDocky has a strange behaviour with [no title] dock, if you select it, than it disappears, and the olny way to re-shows it is to iconify/deiconify it. In Addition to this it should be configurable ("shows even window in other custom screen?", "max len of context menu item= n" or similar)
-Text labels of AmiDock on 4.1 don't look perfect, see docky clock in text mode, you have to set its font to bold for seeing something...; -On 4.1 AmiDock many ways doesn't show the double glow effect when you selected an icon, it seems to be "freezed" and when part of the relative program starts then it shows the "second part" of double glow effect (try with OWB). This is ambiguous, in fact I don't understand if I've right clicked on icon or not... -Many ways it happens you have to click more than once on a docky icon to executed the associated action (see docky icon of YAM, AmiFTP, NoWinED). In other word, in many occasions you have to perform a double click on a docky icon to be sure to execute the relative action;
AmiDock suggestions:
-AmiDock from OS4.0 PreRelease hasn't yet a way to "join" (magnetize?) a subdock with its icon which opens it; -AmiDock has not any kind of explanation of why there isn't yet a way to resize icons into it, in fact it is a new piece of software (while WB is yet the old one source code and I understand it's difficult to improve it) and when AmigaOS has new features like icon.library resize icon feature it should be simple to add this feature to AmiDock; -AmiDock has not any visual feedback when you are on the top of it with pointer, for example it could show selected icon image when you are on the top of it with pointer; -And it's even strange that we can't set AmiDock kind of border, it would be visually good and it would follow the personalization idea of new Intuition (And it is a Reaction program, so it should be simple to add something of this...);
About new skins:
-4.1a,4.1b and 4.1c images are very good, I love visual feedback which remembers glow effect (it could be painted a version with yellow glow...). However they give a little area on which you can click, this has compromised AmigaOS UI usability, in fact your click has to be precise otherwise you haven't any action executed; -The little click area of skin images led another usability problem in fact there is an ambigous behaviour of UI: when you "wrong" hold down on an image like "Close" or "Depht" gadget the new skins permit you to drag window from left top and right top angles of a window, it's totally wrong and have to be fixed IMO; -Title top border of active window trasparence is not configurable;
ASL issue:
-There is not any distintion between a load file requester and a save file requester. Before than now we can identify a save requester with different colours, this thing could be implementable now for example writting directory with a red colour and file with white color or similar. I hope we will can reaquire load/save distinction; -When it's opened a file requester in which you can select more files, it gives you a strange feature to select more the one directory. Ambiguos; -When you open a file requester and drop into it a directory, the focus is not just into string of name file, but it gains focus after you press a key, so if you want find in a directory file "foo" with keyboard like old ASL, if you write "foo", new ASL takes "oo". You must select name string with mouse befor to write any thing;
A little suggest to AmiPDF dev: Can you insert this behaviour (more intuitive and few errors from user use of the program while he reads a pdf):
-ArrowKeyUp/ArrowKeyDown: move up/down the visualized page (page n); -ArrowKeyLeft/ArrowKeyRight: move to (n-1) page/ move to (n+1) page;
-Text labels of AmiDock on 4.1 don't look perfect, see docky clock in text mode, you have to set its font to bold for seeing something...;
Can't reproduce that here.. but maybe it will show up while i'm working on another issue with clock.docky.
Quote:
-On 4.1 AmiDock many ways doesn't show the double glow effect when you selected an icon, it seems to be "freezed" and when part of the relative program starts then it shows the "second part" of double glow effect (try with OWB). This is ambiguous, in fact I don't understand if I've right clicked on icon or not...
I'll check that... i *think* i know what's causing that, but i'm not sure i can fix it without major rewrites of AmiDock (which i surely won't do).
Quote:
-Many ways it happens you have to click more than once on a docky icon to executed the associated action (see docky icon of YAM, AmiFTP, NoWinED). In other word, in many occasions you have to perform a double click on a docky icon to be sure to execute the relative action;
That's not a problem of AmiDock.. every (app)docky is free in its decision if it reacts on single- or doubleclicks. AmiDock just informs the docky about what happened, but the Docky itself is responsible to react to the action.
So if one docky opens a window on single click and another docky only after doubleclick, it was the decision of the dockycoder to do it that way and not AmiDocks.
Quote:
-AmiDock from OS4.0 PreRelease hasn't yet a way to "join" (magnetize?) a subdock with its icon which opens it;
We are at OS4.1 meanwhile.. ;)
AmigaOS 4 core developer www.os4welt.de - Die deutsche AmigaOS 4 Gemeinschaft
"In the beginning was CAOS.." -- Andy Finkel, 1988 (ViewPort article, Oct. 1993)
That's not a problem of AmiDock.. every (app)docky is free in its decision if it reacts on single- or doubleclicks. AmiDock just informs the docky about what happened, but the Docky itself is responsible to react to the action.
So if one docky opens a window on single click and another docky only after doubleclick, it was the decision of the dockycoder to do it that way and not AmiDocks.
I think that there could be problem instead: a couple (or few more) times it happened to me that I clicked on the icon of an application (not a docky) and it did not start.
This sounds strange (and serious): RAM does not get freed after usage of swap memory. Test: 1. copy to RAM Disk more stuff than than it can hold (swapping kicks in correctly); 2. delete everything from RAM Disk; 3. free RAM is reported to be 0 (or little more) even after an "avail FLUSH".
Edit: it does not seem to be a bug, but just a smarter way of allocating memory - here is a simple test that I did: 1. after a reboot, I opened a shell and executed avail FLUSH, which returned 185.196.544 bytes free; 2. I copied a ~28 Mb file to RAM disk; 3. I executed avail FLUSH, which returned 158.597.120 bytes free; 4. I deleted the file from RAM; 5. I executed avail FLUSH, which returned again 158.597.120 bytes free; 6. I copied the file again; 7. I executed avail FLUSH, which returned again 158.597.120 bytes free.
In a nutshell, the memory gets re-used and is re-/de-allocated only when strictly needed.