Some OS4.1 bugs

Since this is apparently the official place to report OS4 bugs, I'm starting-off by posting a few simple ones which have NOT been fixed by Update 2:


* I use TuneNet a lot, which means I get a lot of Ringhio notifications. I also use different screen for different apps, but unfortunately when I close such a program when a Ringhio notification is visible, the screen (opened by the program) is never closed.

Now, I know that Rigo claimed this is the fault of the programs for not following AmigaOS guidelines, and he is probably right.... But when EVERY SINGLE PROGRAM that I use has this problem, I think the pragmatic solution is to fix OS4 (perhaps just Ringhio), especially when I guess such a fix should be quite easy. Here is a short list of affected programs:
+ Multiview (which comes with OS4) !
+ OWB (which comes with OS4).
+ SimpleMail (which comes with OS4), and MUI is presumably to blame.
+ Every single MUI program (and MUI comes with OS4).

This annoys the hell out of me, as it requires a reboot to fix. BTW, my imagined fix: When Ringhio closes it's window, it asks OS4 is there are any windows on the screen, if not then it asks OS4 if anyone has a lock on the screen, and if not then it closes the screen. Perhaps such a fix couldsimply be part of OS4, and done for all "visitor" windows (not just Ringhio's)?


* I often Leave Out files on Workbench's desktop. Typically they don't have a real icon, so DefIcons has to determine their filetype to show the right icon (and double-click action). This works fine when you FIRST leave-out such icons, but after a reboot all such icons are generic "blank page" icons, as if DefIcons did not recognise them.

I even saw this bug found during a video presentation of OS4.1 Update 1, and the beta tester said he would make a note of it & report it.... Looks like he never did


* Not exactly a bug, but it is very bad/strange behaviour: When you choose Scale (or Scale Well) for Workbench backdrop pictures, it doesn't maintain the aspect ratio, such that everything (esp people) look stretched/squashed. I don't know why, since OS3.9 did it correctly, and it's not exactly hard to maintain the aspect ratio (just a few lines of additonal code I think).

"Scale" should be renamed "Stretch", for those that want such odd behaviour, and "Scale" should then do what you would expect. No need for any borders, just chop-off the bits of the picture that won't fit (i.e. choose the maximum scale value, not the minimum), and centre the part of the picture that will fit.


I think there are a lot more (and more serious) bugs, but those are the ones I remembered for the moment (and which are easily reproduced & which I have tested are not fixed by Update 2). More to come, and hopefully kas1e will join me since he apparently knows a lot of OS4 bugs....

@ChrisH

It should be noted, that anyone wanting to post bugs here *please* also produce a step by step guide to reproduce it, and preferable on a default OS4.1 update 2 install. The more details you can give the better it is, dont worry about taking up space on the forum.

Other OS4 devs can then confirm if it is a bug, and add it to the 'list'.

@ChrisH

Quote:

They did. Its in the database.

@ChrisH

I just tried this with YAM, the only app I know that uses Ringhio.

You are correct, if the programme is closed while the notification is still up then the screen does not close, normally a MUI screen closes when a third party window is closed. I know that as I tend to use KingCon shells on other screens often and after sending the CLI back to WB or closing it, screens close as they should. So it looks as if Ringhio is not telling the screen/system that it has finished with its window.

As I am unlilkey to want to close YAM before the notification telling me I have mail to read disappears I am not /that/ worried

OK, another "not exactly a bug" but really bad behaviour. Just tested, and it was not fixed by Update 2:

* OS4 can be stuck on the "OS4 booting" screen, and appear to never finish booting (in reality it will after 1.5 minutes but most people never wait that long), when it is set-up to obtain an IP address via DHCP, but is unable to due to the ethernet lead being disconnected (or the DHCP server being switch off, etc).

To be brutally honest, such behaviour is not acceptable for new users (they will think OS4 is crap & perhaps give-up on their first try using it), and worse it will happen VERY OFTEN with new user. The network cable is typically the LAST thing you plug in, and maybe you don't when first trying your shiny new OS4 machine because you don't have a suitable cable yet. Or they plug it into the wrong socket on a Sam440 (which has 2 sockets!) It happened to me, and without asking someone else I would not have had a clue why it was happening. Most new users do not (and probably never will) even have an account on AW.net or Amigans.net.

Now, I know this behaviour is semi-intentional, because otherwise it could theoretically cause problems if someone wanted to run a server style program on their machine. But exactly how many users want to run such a program on OS4? 1 in a 100? And how many new users will be stuck waiting for DHCP? I'd guess at least 1 in 10, maybe as many as 1 in 3. Doesn't really look like a good trade-off does it? Especially as it ruins many users' first impressions of OS4.

I have also heard the argument that users would be upset if they started (say) OWB, and found they could not access the internet, because DHCP had not quite finished yet. Well, big deal, really! I doubt many will start an internet program the very instant OS4 boots, but in such a case they can click the refresh/retry button. And really, this is no worse than under (say) Windows where unhibernating requires that it re-requests DHCP (if the IP address has expired), but you can still start Internet Explorer before an IP address is ready.

Probably the reason it has not been fixed yet is that the OS4 devs want to "do it right", and the "right way" would be a complex general-purpose "services" system. But when there is an EXTREMELY SIMPLE way to solve the problem, which would even answer every criticism, then I think they should be pragmatic and use it.

Instead of the line "C:AddNetInterface QUIET DEVS:NetInterfaces/~(#?.info)" in S:Startup-sequence, you would have "Run >Nil: C:Execute S:Network-Startup". And the S:Network-Startup file would contain this:
Quote:
Finally, the Workbench titlebar would end with the text " %e Sys/NetInterfaceStatus" so that the network status was displayed. If you want, you could show it in a Docky instead, but this is the really easy way.

Now, if the (1 in a 100) user ever installs a server program, that program should append itself to the S:Network-Startup file, just like some programs do to the S:User-Startup file. That way they can guarantee that they are not started until DHCP has completed (or failed).

And if the user tries to run OWB/etc before DHCP has completed, they might work out why they have a problem, because the Workbench titlebar will initially say "Network OFFLINE", and only later say "Network Online".

@ChrisH

Quote:

Also in the Bugzilla database already.

@ChrisH

Quote:
+100 !!!!!!!!! I support that idea as big time as possible.

@all

I have another weird(?) behaviour

Whenever a program (window) uses the the new fancy fade in/out feature of update 1(?) the window pops up fully for a second before it closes finally.
This looks ... awkward and not very nice

Examples (just close the window - it will fade out and then pop up fully before closing):
TuneNet's SkinFX window
MPlayer's GUI window

Do i need to change some settings or is this behaviour normal?

@Raziel

Quote:
Not happening here.

@TSK

Yes, found it

AutoPoint from Commodities is the culprit.

Having it run and letting it stay above the closing window lets the window fade to nearly being invisible, then autoactivate the window below (or WB) which makes the fading out window come to a full view for a second again before it goes away finally

In both cases (fading in and fading out) the behaviour can be worked around by moving the mouse away from the fading window (but honestly, i never do that)

Is this a bug in AutoPoint and could it be fixed?

I am so used to AutoPoint that i wouldn't want to leave it again

@BillE

Quote:

This sounds like Ringhio keep a lock on the screen, which would be a bug.

Correct behaviour is to lock the screen, open your window on it, unlock the screen. No need to keep the lock since your window would hold a lock on its own. SOunds like Ringhio never releases the lock.

Another small bug in OS4:

When a Ringhio notification appears above a window, it is *impossible* to move that window to the back. Normally one would click the depth gadget twice (first to bring it to the front, and then second time to put it to the back), but because the notification is always the top window, the depth gadget only tries to bring it to the top (and "fails" because the notification is still above it) and so it never tries to put the window to the back.


BTW, an unrelated minor suggestion, OS4 should add something like the following line to the S:Startup-Sequence :
Quote:
You obviously need the icon file to already exist! That way the Ram Disk's icon snapshot state is remembered after a reboot.

@ChrisH

Quote:

Better make that:
C:MakeLink RAM:Disk.info ENVARC:Sys/def_ram.info SOFT FORCE

I alredy have this command in User-Startup BTW.

@salass00

Why?

@cha05e90

The file ENVARC:Sys/def_ram.info already exists on a default OS install and contains a RAM disk icon. S:RAM_Disk.inf OTOH does not and is also a misuse of the SYS:S directory which is supposed to be used for scripts only.

@cha05e90

it will remember your snapshot RAM disk icon on all further reboots, just like with HD icons

@salass00

Quote:
Then again, since the def_ram.info file already exists (or at least is expected to), the FORCE parameter is not a good idea. From the MakeLink docs:

Quote:
So using FORCE, you risk creating a link to nothing useful without being alerted to the fact.

Best regards,

Niels

@Raziel
Yes, but why copy an icon FROM ENVARC: to ram disk? If you want to snapshot your ram disk icon - snapshot it and a disk.info will appear in the ram disk root directory. Copy this to ENVARC: as "def_ramdisk.info" and on next reboot this (with your personal snapshot information) will appear at the snapshotted position. There's AFAIK no need to copy it to the ram:'s root directory on every boot. It might/should work this way since OS3.9.

@cha05e90

Who COPIES anything???

You make a LINK to the file (that is already there on EVERY OS4 installation)

And NO, on a reboot WON'T be any disk.info file in RAM: (because it has been recreated without any), that's why one needs the LINK

@nbache

I stand corrected. For some reason I assumed the FORCE option of MakeLink would work more or less the same way as the -f/--force option of the UNIX ln command (replace RAM:Disk.info if the file already exists for some reason).