Various smaller bugs

A forum for general AmigaOS 4.x support questions that are not platform-specific
User avatar
mrupp
Posts: 39
Joined: Sat Jun 18, 2011 12:19 pm
Location: St. Gallen, Switzerland

Various smaller bugs

Post by mrupp »

Hi there

While using OS 4.1 Update 2 on my Sam440Flex (800 Mhz, 1 GB Ram, Radeon 9250 128 MB), I stumbled over some smaller issues and each time wrote them down. So here's my little collection of smaller bugs and other issues, that I would appreciate a lot, if addressed. I try to be as specific as possible in showing the steps to reproce, but if anything's unclear, just tell me and I'll upload a screenshot or another to clearify...

WB-Windows:
- After dragging the slider, the size of the slider is not being recalculated. It then indicates to have some content even if there isn't. The recalculation only happens when resizing the window or pressing a slider-arrow.

Prefs/Locale:
- Country: Thai-Fonts seem not to be present (shows squares in column "Local name") --> this means the default font doesn't include thai characters. It would be nice to have a default font that does.

Prefs/Pointer:
- When using a 16:9 resolution, the color chooser is not drawn as a proper circle.
- The new default 32bit mouse pointers are very nice, but it's very confusing, that this (meaning: the existence of def_pointer.info in ENVARC:Sys/) overrides the settings of the Pointer prefs. 'Pointer' should be updated to be able to handle / edit the new 32bit pointers.

Prefs/WBPattern:
- using the layout "Scale" or "Scale well" in OS3.9, an image would always keep its proportions. Now the image is streched to fit the screen. It would be best to have both options: "Scale (fit screen)" and "Scale (keep proportions)". The layout "Scale [not well]" could even be dropped, imho.

Prefs/Palette:
- Not really a bug, but compared to OS3.x this is missing a color chooser control.

IconEdit:
- This seems to be outdated, it's not possible to create or edit OS4 icons, only OS3.9 icons (and older) are supported. A very good replacement (or addition for backward compatibilitys sake) might be this: http://os4depot.net/index.php?function= ... editor.lha
- When using a 16:9 resolution, the color chooser is not drawn as a proper circle.

DepthToFront:
- When using Styles in the GUI preferences, the sensitive area to open the dropdown menu does not fit with the style used. What I mean is this: The menu should appear right clicking the depth gadget. Now, when using a style (such as "Curvy"), clicking on the right half of the gadget shows the menu, clicking on left half doesn't.

AsyncWB:
Having the history enabled (= disabling the NOHISTORY tooltype), a history file is being written: ENVARC:Sys/AsyncWB.history
Filesize is 5130 bytes. It does contain the history (3 entries in my case) but fills its size up with... well, probably just anything that was in the memory, is my guess... Here's an example:

screenmode
pointer
notepad
***END***
>
<!DOCTYPE pobjects PUBLIC "-//Amiga Inc.//DTD POBJECTS 1.0//EN" "http://www.amiga.com/DTDs/PrefsObjects-1.0.dtd">
<pobjects version="1.0">
<dict>
<key>LastUsedApplications</key>
<array>
<dict>
<key>openDate</key>
<date>2010-04-30, 16:10:16</date>
<key>appIdentifier</key>
<string>RINGHIO.soft3dev.net</string>
<key>appName</key>
<string>RINGHIO</string>
</dict>
<dict>
<key>openDate</key>
<date>2010-04-16, 15:18:55</date>
<key>appIdentifier</key>
<string>DvPlayer</string>
<key>appName</key>
<string>DvPlayer</string>
</dict>
(...)

Ideas for improvements:
- USB 2, of course (as stated a lot already)
- GUI: A test-button would be great.
- Improvement of the Shell: Should just work like KingCON, because there's not a lot to improve anymore when having that one installed (but I think there's no OS4 native version, unfortunately).
- It would be great to have the possibility to show window contents as previews (thumbnails of images, etc.)
- Currently, it seems that buttons in requesters cannot be chosen by keyboard, only by mouse. It would be nice to be able to 'jump' from one button to the next using tab key (like in ReqAttack).


@any Betatesters: It would be great if you could counter-test these issues and post them as bugs to be addressed... (I'm sure, some of them probably are already posted, aren't they?)

@all OS4 developers: Great work, guys, keep the updates rolling...! :D
------------------------------------------------------------------------------
Check out TAWS - The Amiga Workbench Simulation
https://taws.ch
chris
Posts: 562
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: Various smaller bugs

Post by chris »

mrupp wrote: - When using a 16:9 resolution, the color chooser is not drawn as a proper circle.
This is a colorwheel.gadget issue. I can hazard a guess as to why it happens:

In the DisplayInfo database, AmigaOS does not differentiate between normal (4:3) and widescreen (16:9) displays (or, technically, does not even recognise the latter). As far as it is concerned, a 1024x768 display has square pixels on both monitors. This is, of course, incorrect, as that resolution on a 16:9 display will be stetched so the pixels are wider than they are tall. Similarly, a native 16:9 resolution on a 16:9 display will be deemed to have tall pixels (like hires mode under AGA) even though they are actually square.

Basically DisplayInfo.ResInfo needs updating so it corrects for the aspect ratio of the display. I'm not sure if there is some automated way to find out the aspect ratio of the display, if there isn't then this isn't going to be easy to fix. However it will be impacting anything which looks at those values to correct the display. colorwheel.gadget should be using them to ensure the wheel is circular no matter what display it is being drawn on. If it is, then the problem is the values are wrong on widescreen displays (which they are; I had cause to test this only a few days ago). If it isn't, then it should be, and of course the DisplayInfo ResInfo values will then show up as a problem.
User avatar
nbache
Beta Tester
Beta Tester
Posts: 1714
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: Various smaller bugs

Post by nbache »

mrupp wrote: WB-Windows:
- After dragging the slider, the size of the slider is not being recalculated. It then indicates to have some content even if there isn't. The recalculation only happens when resizing the window or pressing a slider-arrow.
I can't reproduce this (at least not immediately). You may need to give us screenshots showing how your WB window looks before and after dragging and specify which scroller you drag and how far.
Prefs/Locale:
- Country: Thai-Fonts seem not to be present (shows squares in column "Local name") --> this means the default font doesn't include thai characters. It would be nice to have a default font that does.
There are fonts out there which implement most of the characters of the more "exotic" languages. I myself use the Arial Unicode MS TTF which I snatched from my wife's old Win XP laptop. But there is also a freely distributable one; check OWB's documentation, I believe it refers to it. The big problem with those fonts is that they are very big in filesize, so they are probably not good choices as default fonts.
Prefs/Pointer:
- When using a 16:9 resolution, the color chooser is not drawn as a proper circle.
The "color chooser" is a separate component, colorwheel.gadget, so it is the same one used in both Prefs/Pointer and other places. About the aspect of the circle: It draws fine here on 1920×1200 (16:10). Are you sure your monitor has square pixels?
[...]

AsyncWB:
Having the history enabled (= disabling the NOHISTORY tooltype), a history file is being written: ENVARC:Sys/AsyncWB.history
Filesize is 5130 bytes. It does contain the history (3 entries in my case) but fills its size up with... well, probably just anything that was in the memory, is my guess... Here's an example:

[...]
I believe this is on purpose. Normally you don't have any need to read this file directly, as the history is presented in the Execute Command requester on WB. The file is written with a fixed size because this means it is not necessary to modify the directory blocks on the disk when writing to the file (which could have been necessary if the file size increased to need another block). This means the risk of invalidating the disk is reduced, in situations where e.g. a command you execute crashes badly at the exact time where the history is being written.

Best regards,

Niels
User avatar
mrupp
Posts: 39
Joined: Sat Jun 18, 2011 12:19 pm
Location: St. Gallen, Switzerland

Re: Various smaller bugs

Post by mrupp »

nbache wrote: I can't reproduce this (at least not immediately). You may need to give us screenshots showing how your WB window looks before and after dragging and specify which scroller you drag and how far.
OK, I'm attaching a screenshot to clearify... see "Scrollbar.png". Make sure you try the same procedure on OS3.x as well and you'll see... ;)
Scrollbar.png
(79.13 KiB) Downloaded 1283 times
nbache wrote: There are fonts out there which implement most of the characters of the more "exotic" languages. I myself use the Arial Unicode MS TTF which I snatched from my wife's old Win XP laptop. But there is also a freely distributable one; check OWB's documentation, I believe it refers to it. The big problem with those fonts is that they are very big in filesize, so they are probably not good choices as default fonts.
Alright.
nbache wrote: The "color chooser" is a separate component, colorwheel.gadget, so it is the same one used in both Prefs/Pointer and other places. About the aspect of the circle: It draws fine here on 1920×1200 (16:10). Are you sure your monitor has square pixels?
Yes, I'm using 1920x1080, a screenshot will follow...
nbache wrote: I believe this is on purpose. Normally you don't have any need to read this file directly, as the history is presented in the Execute Command requester on WB. The file is written with a fixed size because this means it is not necessary to modify the directory blocks on the disk when writing to the file (which could have been necessary if the file size increased to need another block). This means the risk of invalidating the disk is reduced, in situations where e.g. a command you execute crashes badly at the exact time where the history is being written.
Alright.
------------------------------------------------------------------------------
Check out TAWS - The Amiga Workbench Simulation
https://taws.ch
User avatar
mrupp
Posts: 39
Joined: Sat Jun 18, 2011 12:19 pm
Location: St. Gallen, Switzerland

Re: Various smaller bugs

Post by mrupp »

chris wrote: This is a colorwheel.gadget issue. I can hazard a guess as to why it happens:

In the DisplayInfo database, AmigaOS does not differentiate between normal (4:3) and widescreen (16:9) displays (or, technically, does not even recognise the latter). As far as it is concerned, a 1024x768 display has square pixels on both monitors. This is, of course, incorrect, as that resolution on a 16:9 display will be stetched so the pixels are wider than they are tall. Similarly, a native 16:9 resolution on a 16:9 display will be deemed to have tall pixels (like hires mode under AGA) even though they are actually square.
I am actually using a square pixel mode, usually 1920x1080. I'm not sure if this really is a colorwheel issue or not, because when calling the wheel from GUI / Effects / Button "Colour" on the right, it draws correctly, no matter what screenmode is currently set. Here are 2 screenshots to clearify, one is 4:3 (800x600) and one 16:9 (1280x720):
4-3.jpg
(80.39 KiB) Downloaded 1278 times
16-9.jpg
(137.05 KiB) Downloaded 1278 times
------------------------------------------------------------------------------
Check out TAWS - The Amiga Workbench Simulation
https://taws.ch
User avatar
nbache
Beta Tester
Beta Tester
Posts: 1714
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: Various smaller bugs

Post by nbache »

mrupp wrote:OK, I'm attaching a screenshot to clearify... see "Scrollbar.png".
Scrollbar.png
Okay, I see what you mean. In fact I find its behaviour logical; as long as we accept as a feature, not a bug, that it is possible to expand the window area (in effect adding new empty space to the right of the icons) by clicking on the right arrow (and this is debatable IMO), once we have explicitly expanded the window area, the scroller should, as it does, acknowledge the size of the newly expanded area and be calculated in relation to that. But that's just my 2 øre.
Make sure you try the same procedure on OS3.x as well and you'll see... ;)
Yes, I can see it works differently, it tries to "reclaim" the added space, but seems to miscalculate how far the window contents should be scrolled back. At least on the 3.1 A1200 I had available to try this on, the icons ended up slightly farther to the left than their original position after scrolling back by dragging the knob all the way to the left.

Best regards,

Niels
User avatar
ZeroG
Posts: 124
Joined: Sat Jun 18, 2011 11:31 am
Location: Germany

Re: Various smaller bugs

Post by ZeroG »

Prefs/Pointer:
- When using a 16:9 resolution, the color chooser is not drawn as a proper circle.
This could be a missing

Code: Select all

WHEEL_KeepAspect, TRUE,
in the sourcecode of Prefs/Pointer.
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Various smaller bugs

Post by trixie »

@mrupp
mrupp wrote: IconEdit:
- This seems to be outdated, it's not possible to create or edit OS4 icons, only OS3.9 icons (and older) are supported.[/url]
A new Icon Editor has been developed as part of the OpenAmiga initiative in cooperation with AmigaBounty. It is likely it will be included in OS4 as a replacement. Before that happens, you can download the editor from http://www.os4depot.net/index.php?funct ... iconed.lha.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Various smaller bugs

Post by trixie »

@nbache
nbache wrote: as long as we accept as a feature, not a bug, that it is possible to expand the window area (in effect adding new empty space to the right of the icons) by clicking on the right arrow (and this is debatable IMO), once we have explicitly expanded the window area, the scroller should, as it does, acknowledge the size of the newly expanded area and be calculated in relation to that.
I see this differently. The window arrows do not expand the window area - the size gadget does! The arrows (and the scroller) are there to let you scroll and view the window contents that does not fit in the window area. The scroller, then, shows how far beyond you are. If there is no contents beyond the window area, the scroller should not let you scroll. So what mrupp describes is a bug in my view.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
abalaban
Beta Tester
Beta Tester
Posts: 456
Joined: Mon Dec 20, 2010 2:09 pm
Location: France
Contact:

Re: Various smaller bugs

Post by abalaban »

trixie wrote:I see this differently. The window arrows do not expand the window area - the size gadget does! The arrows (and the scroller) are there to let you scroll and view the window contents that does not fit in the window area. The scroller, then, shows how far beyond you are. If there is no contents beyond the window area, the scroller should not let you scroll. So what mrupp describes is a bug in my view.
Yes I totally agree, in fact I already reported this problem long time ago but I don't remember what I was answered. It's a bug not a feature because the behaviour is not consistant in all cases. I'm not in front of my machine right now but IIRC for example when you are at step 3 of mrupp explanation hitting the right arrow will recalculate the scrollbar (TO BE VERIFIED).
AmigaOne X1000 running AOS 4 beta
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
Post Reply