@Xenic

Quote:

he new MUI seems to use the screens.txt file instead of publicscreens.iff.

Strange, I do not have any screens.txt file at all in sys:

All I did was copy my old publicscreens.iff file and then all my old screens were there once more.

Um, the BIG problem with Amigas, is that you RUN Executable code, but Execute Script, that is Runable text.

Maybe if the functions had been renamed at the beginning, people wouldnt have problems with run startup-sequence and execute loadwb.

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@BillE
Quote:

Strange, I do not have any screens.txt file at all in sys:

I have one there. It's probably created as and when you configure and save any new screens?

Update...

Installed AmigaOS 4.1 Update 3 late evening on August 29,2011.

AMosaic1.2 croaks on launch with GR 80000003 DSI error. This is such an old program that it is pointless to pursue further.

All my other MUI applications work fine, including MUI-OWB.
All my other applications work fine, or as they did before the update.

The only other issue I had was when I tried my USB devices a few days after my update to Update 3. When I plugged in a USB stick, no disk icon .. 3rd system reset cleared the trouble. Good since.

MicroA1-C, IBM 750GX PPC CPU, 256 MB RAM, onboard Radeon 7000, 32 MB VRAM
PS/2 keyboard + PS/2 mouse
Both onboard VIA IDE interfaces set for auto-discovery (and best PIO by default).
Rear USB ports disabled
Front USB ports enabled
Current screenmode = 1024x768 32bit
Compositing (3D acceleration) = disabled.
Sreenblanker = disabled (removed from WBStartup)

I have commented out the following lines in Kicklayout ...
;MODULE Kickstart/a1floppy.device.kmod
;MODULE Kickstart/it8212ide.device.kmod
;MODULE Kickstart/lsi53c8xx.device.kmod
;MODULE Kickstart/sii0680ide.device.kmod
;MODULE Kickstart/sii3112ide.device.kmod
;MODULE Kickstart/sii3114ide.device.kmod
;MODULE Kickstart/sii3512ide.device.kmod
;MODULE Kickstart/3dfxVoodoo.chip
;MODULE Kickstart/ehci.usbhcd

---
redfox
MicroA1-C + AmigaOS 4.1 Update 3

I changed my onboard IDE interfaces to PIO many months ago after I developed problems with my Western Digital hard drive.

Last edited by redfox on 04-Sep-2011 at 10:35 PM.
Last edited by redfox on 04-Sep-2011 at 10:29 PM.
Last edited by redfox on 04-Sep-2011 at 10:27 PM.
Last edited by redfox on 04-Sep-2011 at 10:19 PM.

MUI Graphical corruption;

When selecting the pattern within NListviews/Colors/List - (click the large box bottom left),
Now click the buttons - OS4: - MUI/ - Patterns/ - (top right section) and there are horizontal black & white lines appearing within the list below.

NListviews/Colors/List - The selected background pattern will corrupt when scrolled.

I've tried the above in YAM and other MUI apps, all have the same graphics corruption.

Anyone confirm the same please?

@redfox Quote:

I have commented out the following lines in Kicklayout ... .... ;MODULE Kickstart/ehci.usbhcd

That would be a BAD idea, since it disables USB 2.0

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

redfox MicroA1-C + AmigaOS 4.1 Update 3

Doesn't matter much if he comments it out or not.

_________________
Common sense - So rare it's almost like a super power

@raumfahre

The dashed black&white lines in the image selection window are absolutely intentional. They indicate where a file with the currently displayed name would appear if it existed in that directory. For example the file "drive:foo/bar/boo/image.png" was selected at some time. Now you go up one directory to "drive:foo/bar" which contains the files "example1.png" and "workbench.jpg", but not "image.png". In this case the dashed bar would appear between these two files, because "image.png" would be sorted between these two, if it existed in that directory.

Which kind of background for NList are you talking about? A custom image like from the example above, or a pattern selected on the left side? A custom image requires an updated version of NList, which is not yet released. As such this is a known bug, which does not need to be reported in NList's bugtracker. Furthermore it is fixed already, but Jens wants to add some more features ahead of the next release.

_________________
Why stop it now, just when I am hating it?

Thore Böckelmann

@tboeckel
Quote:

The dashed black&white lines in the image selection window are absolutely intentional.

OK, thanks for the explanation.

Quote:

Which kind of background for NList are you talking about?

Yes I was meaning a custom image. But having just checked the 14 patterns on the left, these have glitches aswell when they are used and scrolled in a window.

Anyway, I guess the point is now moot, as these problems have already been fixed.

Thanks.

@Xenic

Quote:

If those protection bits are so crucial why aren't they set correctly and constistantly in the OS 4.1 updates? If you extract the Update3 lha file (using Unarc) you will see that all the documentation files have the executable bit set, the logo PNG file has the executable bit set, the text.datatype has executable bit set but the other datatype files do not, the table.image has the executable bit set but the other images do not, some of the libraries have the executable bit set and others do not, etc. etc. Why is it so important to preserve the protection bits if they aren't even set consistantly (or correctly) in the update??

For most files it doesn't matter. Having the execute bit set has been the default since the beginning. Only JXFS changed that default (which caused a minor havoc). However, some files probably need the script bit set (I presume) and if that bit isn't set, stuff won't work for those scripts.

Also, if you extract to a JXFS partition (which default to not set the execute bit) using lha (which defaults to leave bits as default) no executable files, binary or scripts, will work.

For pictures and stuff the only thing that really matters is the readable bit.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

so the problem is that lha leaves protection bits at default (sounds like a good behaviour?) and unarc sets executable bit to workaround jxfs? and therefore you are supposed to use unarc to update your system? weird.

@wawa

Quote:

so the problem is that lha leaves protection bits at default (sounds like a good behaviour?) and unarc sets executable bit to workaround jxfs? and therefore you are supposed to use unarc to update your system? weird.

Not at all. Lha default behavior is to not set protection bits at all, leaving it to the filesystem to decide. Unarc will use the protection bits set inside the archive.

Lha can be set to use the same behavior by using the "-a" option when extracting.

_________________
Common sense - So rare it's almost like a super power

@zerohero

filesystem decides how to set protection bits. aha. didnt know that.

@wawa

The default has always been +RWED. JXFS changed it to always be +RWD, I think.

_________________
Common sense - So rare it's almost like a super power

@BillE
It probably didn't appear until I saved the MUI prefs. I just hadn't looked in the ENVARC:MUI directory until I had some problems. Once I saw it, I renamed publicscreens.iff to see if MUI was using the new screens.txt file and everything seems to work normally. Only last night did I notice that if you select "About MUI.." in a program like YAM that has that menu, it tells you all the MUI libs that you can remove now that MUI is updated. However, the publicscreens.iff file isn't included in the list so it might be better to leave it there for now (as a precaution).

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

Quote:

However, the publicscreens.iff file isn't included in the list

Maybe that file wasn't listed because you renamed it.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Xenic

The About window shows no longer used files only. Since MUI will fall back to publicscreens.iff if screens.txt is missing/invalid this file cannot be deleted

_________________
Why stop it now, just when I am hating it?

Thore Böckelmann

I decided to download and install OS4.1 Update 3 this afternoon.

BUT, I stopped when I saw the size of the file on Hyperion's site is different than my downloaded file.

Hyperion site: 16,149,466
My download: 16,149,579

What gives?

EDIT:
Unarc won't unpack the downloaded .lha file saying that it doesn't know type of file it is.

Bazaar.

Last edited by Moxee on 07-Sep-2011 at 11:34 PM.

_________________
Moxee
AmigaOne X1000
AmigaOne XE G4
I'd agree with you, but then we'd both be wrong.

@Moxee

You didn't download it with IBrowse did you? The warning isn't just for show, their webserver adds invalid headers when you download with IBrowse, which sounds like the corrupt larger size you got.

My download was exactly 16149466 bytes.

_________________
Doing stupid things for fun...