Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: Matt_H on January 16, 2010, 10:56:23 PM
-
Sigh. What on earth is going on in the proverbial OS4 development labs? It seems like every new release I enjoy less and less. This update feels like a disparate collection of improvements that no one thought to analyze how they worked together usability-wise. Overbearing/bad management may have killed Commodore, but the utter lack of management and lack of an overall vision for the design of OS4 is effectively driving me away - me, a will-be-the-last-Amiga-user-on-Earth kind of guy! What is going on?
Some observations I've made so far:
* No PNG icon support out of the box
There's really no excuse for this. A PNG icon module exists, why is it not bundled? Better yet, why doesn't icon.library support PNGs directly?
* Deprecated tools
IconEdit (still!) doesn't support the 32bit icon format introduced in 4.0
The 2bit Pointer prefs tool doesn't do anything since the default pointer is a 24bit one controlled by the presence/content of a deficon buried in ENVARC:Sys
This will no doubt confuse the hell out of new users. Why haven't these tools been updated?
*Another new icon set
These new icons have been appearing in releases of OWB and other programs for months/years already, and now they're system-wide. Personally, I don't care for them. They're absolutely gigantic, too.
*Inconsistent icon scaling
Fortunately, Workbench prefs now includes an option to set limits on the sizes of icons. It's adjustable to the exact pixel and there are separate scales for the Workbench itself and within drawer windows. Unfortunately, AmiDock is unaffected by the settings. I've had to remove programs from my dock in order to not have it look like a screen real estate monstrosity.
*Nonexistent bitmap scaling
Back in the 4.0 days, gadget images came in several different sizes, each suitable for different screen resolutions. Now there's only one size, so many options in GUI prefs end up having no effect (like attempting to reduce the height of the window titlebar). Scaling for gadgets should be a priority for the next release.
What I've done is created a virtually empty bitmap set - the only things in it are the Amiga key, checkbox, and Boing Ball. Everything else falls back to vector-based gadgets which, though lacking in polish, behave how I expect them to.
*Still no Preview/Test option in GUI prefs
GUI prefs is an absolute mess. There are too many options and it's not clear what they all do. There was a "Preview" button in early releases of 4.0 which said something along the lines of "Not working yet" when pressed. It was cleverly removed in later releases, but the problem of not being able to quickly test what each option does remains.
*Disappointing redesign of ASL requesters
Just as MorphOS has moved to an MUI-based ASL replacement, OS4's is now ReAction-based. Unfortunately, it comes with the expense of the requester not displaying anything until the entire directory has been loaded (older ASL would display files/drawers as they were read from the filesystem in near-real time). The ability to use the RMB to quickly switch to the devices list has also changed (it only works with the third, fourth, or fifth buttons now). It doesn't seem particularly responsive. If you're in the devices list, although pressing the button again will get you back to the directory you were in, nothing changes until the directory has been read. That is, you will continue to see the devices list until your directory is ready to go. The visual feedback is very confusing. I ended up pressing the MMB 3 or 4 times because I thought the click hadn't registered. Instead, the clicks were held in the input buffer so that as soon as the directory was read, it would take me there for a fraction of a second, then back to the devices list, where it would attempt to read the directory in again. Not fun. I may just turn off the feature altogether and use the Volumes button like in OS3.1.
There is a new clickable button in ASL to select All, None, or all files with the same extension as the currently-selected one. That's kind of neat. The devices list also shows multi-assigns in bold (usually entries like FONTS:, HELP:, etc).
*No more WBStartup!
This bothers me most of all. While I understand that the intent was to integrate something like WBStartup+ (http://aminet.net/package/util/boot/WBStartup+), the implementation is, frankly, bad. WBStartup+ works by moving everything in your WBStartup drawer into Enabled and Disabled subdirectories. WBStartup+ then becomes the only program in WBStartup and executes everything in Enabled when run.
OS4 has removed the WBStartup drawer entirely. Instead, a new Prefs tool controls a list of programs that will be executed (I guess by LoadWB). Now instead of dragging stuff into a drawer, I have to open up a prefs tool and drag stuff in there (or navigate another ASL requester). It's far less parsimonious. I use T.H.E. to enhance keyboard and menu options in Workbench, but it seems this new WBStartup implementation can't execute scripts. It also seems that manually creating a WBStartup directory doesn't do anything. This is the biggest annoyance I've found so far, so my first priority will be to find a workaround.
That's all for now. Can't wait to have my MorphOS machine back, to be honest.
How is everyone else getting on with the new update?
-
I hope you are wearing your flame suit today!
:flame:
-
I'm ready :)
Another observation:
*Yet another redundant API!
The history of the Amiga is filled with pointless battles: MUI vs. ReAction, PowerUp vs. WarpOS, CGX vs. P96. Now we've got another one: OpenURL vs. URLOpen.
Maybe someone can correct me, but URLOpen seems to do the exact same thing as OpenURL. What was the point of creating it? Okay, it does come with a handler implementation in L:, but so did older versions of OpenURL. Wouldn't it have made more sense to just bring that up to date?
I can't imagine developers are too pleased about this, especially those who compile for all Amiga variants...
-
I downloaded the ISO yesterday and intended to install it today. However, reading through the early responses over at aw.net since then I've been a bit put off.
On top of the issues mentioned here, it seems a few other things don't work as expected. Some inbuilt shell commands don't behave as they should. For example
Set foo ""'
This assigns the empty string to local var $foo in earlier versions, but fails on 4.1U1
If ?
This displays the template for the 'If' keyword when entered in a shell in earlier versions, then fails (as it's only valid within a script), but apparently fails immediately in the update.
TBH, I really don't see what the WBStartup thing was about. One of the best things about the existing system was it's sheer simplicity. I can understand that perhaps people don't want to drag stuff there and forget where it came from if they ever wanted to put it back or disable it, but there are surely other ways to deal with that (tooltypes to mark as disabled and where a tool was dragged from might have sufficed, for example).
As for not running scripts, that's not good for me. I use a few ARexx scripts to extend my Workbench with various shortcuts that I've been using since OS3.5 and still use in 4.1.
-
Hi Matt_H,
I must agree with some (if not all) of your observations.
* No PNG icon support out of the box
There's really no excuse for this. A PNG icon module exists, why is it not bundled? Better yet, why doesn't icon.library support PNGs directly?
Yep, this should have been included already... fortunately it's just matter if installing alib and the png module fom OS4depot and you're ready to go. No big issue here.
*Another new icon set
These new icons have been appearing in releases of OWB and other programs for months/years already, and now they're system-wide. Personally, I don't care for them. They're absolutely gigantic, too.
Well, I must say that while I really appreciate all the work put on this new icon set, I don't like them and they are very big! I can easily feel my 1920x1200 workbench doesn't have enough space. yes, you can scale them down now but that means I will also have to change the icons for all my previously installed appications in work: otherwise those will look ridiculously small. i wish there was an option to use the old iconset at the install process.
*Inconsistent icon scaling
Fortunately, Workbench prefs now includes an option to set limits on the sizes of icons. It's adjustable to the exact pixel and there are separate scales for the Workbench itself and within drawer windows. Unfortunately, AmiDock is unaffected by the settings. I've had to remove programs from my dock in order to not have it look like a screen real estate monstrosity.
I had to do exactly the same thing here, amidock just takes so much space with these new icons that almost goes from one side to the other of my 1920 pixel wide Wbench... not good! And to make it even better, now it turns out that a bug has been introduced in amidock, there is no way I can make the docky icon from WET Forecaster to show up in amidock if wet is started before amidock... (i.e. both started at boot as configured in the new wbstartup prefs).
*Still no Preview/Test option in GUI prefs
GUI prefs is an absolute mess. There are too many options and it's not clear what they all do. There was a "Preview" button in early releases of 4.0 which said something along the lines of "Not working yet" when pressed. It was cleverly removed in later releases, but the problem of not being able to quickly test what each option does remains.
Well, to be honest there are just too many things you can configure that I usually don't mess with it. It's a problem having to click the "use" button to test a change you will probably won't notice. Only the gadgets option actually has a "test configuration" button.
*No more WBStartup!
This bothers me most of all. While I understand that the intent was to integrate something like WBStartup+ (http://aminet.net/package/util/boot/WBStartup+), the implementation is, frankly, bad. WBStartup+ works by moving everything in your WBStartup drawer into Enabled and Disabled subdirectories. WBStartup+ then becomes the only program in WBStartup and executes everything in Enabled when run.
This is the one I personally find most annoying. Apparently there is no option to revert to the 'old way'. Besides the fact that it doesn't support the execution of scripts, the startup prefs tool won't allow to set any order or execution priotiry, etc. Fortunately it appears that someone has posted a possible solution to go back to wbstartup directory way of doing it, see here (http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=30536&forum=14#534610) . I haven't tested the suggestion yet myself , but I will do it asap.
OS4 has removed the WBStartup drawer entirely. Instead, a new Prefs tool controls a list of programs that will be executed (I guess by LoadWB). Now instead of dragging stuff into a drawer, I have to open up a prefs tool and drag stuff in there (or navigate another ASL requester). It's far less parsimonious. I use T.H.E. to enhance keyboard and menu options in Workbench, but it seems this new WBStartup implementation can't execute scripts. It also seems that manually creating a WBStartup directory doesn't do anything. This is the biggest annoyance I've found so far, so my first priority will be to find a workaround.
Yep, I don't like it either. read above for a possible workaround.
Cheers,
Dragster
-
@ Karlos
TBH, I really don't see what the WBStartup thing was about. One of the best things about the existing system was it's sheer simplicity. I can understand that perhaps people don't want to drag stuff there and forget where it came from if they ever wanted to put it back or disable it, but there are surely other ways to deal with that (tooltypes to mark as disabled and where a tool was dragged from might have sufficed, for example).
That's what's good about the way WBStartup+ does it. You can still drag stuff in if you want to (and if an installer copies things to WBStartup everything will continue to work fine). It gives you flexibility. The new OS4 implementation doesn't.
As for not running scripts, that's not good for me. I use a few ARexx scripts to extend my Workbench with various shortcuts that I've been using since OS3.5 and still use in 4.1.
I've now got my scripts working by running T.H.E.'s setKEYandMENU from the startup-sequence (after LoadWB). Far less elegant than dragging into WBStartup, but at least it works.
-
I'm glad to read some actual feedback on the update... Its seems like everyone on the OS4 centric sites are too busy giving dancing bananas & high fives to actually use the product and point out needed stuff & fixes....
-
@ Dragster
Thanks for the reference - I'm experimenting now.
EDIT: Okay, I can now confirm that renaming/deleting ENVARC:Sys/wbstartup.prefs and creating SYS:WBStartup will restore the WBStartup functionality we know and love - ARexx script support and all. This solution is marginally cleaner than the one Simon Archer suggested (deleting wbstartup.library), as all that's needed to go back to 4.1.1 default behavior is to hit "Save" in WBStartup prefs.
@ thread
Observations continue:
*What is Ringhio for?
It's the new notification server, apparently. Do any programs use it yet? I'd like to see what it does. And what it looks like.
-
Today, I had quite an ordeal installing OS 4.1 Update 1 on my MicroA1-C. Apparently, I was not the only one who kept getting Grim Reapers, or booting into a white Workbench screen with no icons, or booting into a black screen, or booting into a system that was unstable.
Eventually a temporary fix was found .... disable the rear USB ports.
My system has been stable since and no further bootup problems.
I agree with Matt_H about the icons. My prefernce would be smaller icons, but the larger icons have been present in OWB for some time now.
Since it took so long to sort out the stability issues, I have not played much with anything other than OWB.
---
redfox
-
The more I read on OS4 and play with MorphOS, the more certain I am that being stuck with m68k AmigaOS3.9 on various machines and UAE is the only sensible thing to do for me. I really, really wish the OS4 and MorphOS camp could concentrate on "stuff that matters" instead of constantly screwing around and breaking the user experience which defines what is Amiga. But whatever, there's really not much one can do to prevent the developers from shooting themselves in their feet.
-
OS 4.1 - Now with more dancing bananas!
(http://www.singalongwithme.com/banana/bann.gif)
-
@ redfox
I glanced over some posts about boot problems. What did you use to download the ISO? My download was corrupted by the combination of IBrowse and Hyperion's site, but OWB/Firefox were fine.
-
@ Dragster
EDIT: Okay, I can now confirm that renaming/deleting ENVARC:Sys/wbstartup.prefs and creating SYS:WBStartup will restore the WBStartup functionality we know and love - ARexx script support and all. This solution is marginally cleaner than the one Simon Archer suggested (deleting wbstartup.library), as all that's needed to go back to 4.1.1 default behavior is to hit "Save" in WBStartup prefs.
Yep, fortunately the old wbstartup functionality is still there.
I've solved my problem with the WET dock app docky icon.
I've reverted to WBStartup functionality by deleting wbstartup.prefs and creating the wbstartup directory, then I copied all the needed applications, just like usual prior to this version, tweaked the start priority on both amidock and wet icons so that wet is forced to start after amidock and voilá, problem solved... this is impossible with the wbstartup prefs editor since there's no way to set execution priorities, execution order, etc.
Welcome back good old WBStartup directory!
Cheers,
Dragster
-
I'm glad to read some actual feedback on the update... Its seems like everyone on the OS4 centric sites are too busy giving dancing bananas & high fives to actually use the product and point out needed stuff & fixes....
i don't think so (at least with this update). I've read a lot of blaming yesterday on the front page of the most OS4 centric sites ... well, apart some usual fanatic.
The main problem (IMHO) is the lack of official betatersters (they are not paid at all and the OS4 betatester coordinator is kicking out some as well "pretending" a full job-like time dedication) plus the new join venture about the new mobo.
Face it ... the true and deep betatesting is done by us, the users :-)
Anyway, enjoy it .... Amiga is always been so!
-
OK, nevermind...I see the bi#$%ing now! My bad! :)
i don't think so (at least with this update). I've read a lot of blaming yesterday on the front page of the most OS4 centric sites ... well, apart some usual fanatic.
The main problem (IMHO) is the lack of official betatersters (they are not paid at all and the OS4 betatester coordinator is kicking out some as well "pretending" a full job-like time dedication) plus the new join venture about the new mobo.
Face it ... the true and deep betatesting is done by us, the users :-)
Anyway, enjoy it .... Amiga is always been so!
-
Welcome back good old WBStartup directory!
I'm reminded of the old saying, "If it ain't broke, don't fix it" (the way WBStartup has worked for 20 years, that is) :)
-
@Matt_H
I used IBrowse the first time and got the corrupted file. Then I downloaded again using OWB 3.22 and that file was fine. I used AmiDVD to burn the ISO to a CD-R disc.
The booting issue seems to be isolated to MicroA1-C so far. Disabling the rear USB ports allows us to boot cleanly with the CD or hard drive. However, some of us experienced the nightmare first before the temporary fix was discovered. For whatever reason, the sytem becomes very unstable if all the USB ports are enabled. We did not have this problem with the previous version of OS4.1.
We don't know if the issue is related to a particular CPU or the MicroA1-C in general. My CPU is an IBM PowerPC 750 GX.
( I personally have experienced a similar unstable system before. Shortly after I installed the original version of OS4.1, I unwittingly used the UBOOT Prefs program included with OS4.1 to change some settings to change the hard drive from PIO to U-DMA 5 mode. My system became extremely unstable and would not boot properly from the hard drive. It took me 2 days to solve the issue. I had to reset UBOOT to factory defaults and disable the USB ports and carefully rebuild my UBOOT settings. Eventually I was able to restore my USB ports. I ran my system in PIO mode for months after that. )
---
redfox
-
@ redfox
Apart from the IBrowse corruption, my installation/bootup was very smooth on an XE-G4. Sounds like a bug in the reworked USB drivers.
@ Framiga
the OS4 betatester coordinator is kicking out some as well "pretending" a full job-like time dedication
That is unfortunate. A smaller/less representative sample of users in the beta pool will inevitably lead to more bugs discovered upon public release. Although maybe it will cut the testing phase from 18 months down to 14 ;)
-
I'm glad to read some actual feedback on the update... Its seems like everyone on the OS4 centric sites are too busy giving dancing bananas & high fives to actually use the product and point out needed stuff & fixes....
I agree. Until I get to sit down and actually use one of these "new" amigas I'll just keep using my old amigas and windows when I have too.
-
If anybody is interested, I installed it on my A1 XE and posted my initial reaction here (http://www.amiga.org/forums/blog.php?b=142).
-
"doesn't support the execution of scripts"
No? Not here. All scripts are executed. No difference between old WBStartup drawer and new WBStartupPrefs. What are you doing wrong?
-
"doesn't support the execution of scripts"
No? Not here. All scripts are executed. No difference between old WBStartup drawer and new WBStartupPrefs. What are you doing wrong?
It works fine for me, provided the scripts have a proper icon with the associated default tool.
-
It works fine for me, provided the scripts have a proper icon with the associated default tool.
What default tool did you use? I thought I couldn't get anything going with RX, but it's been a few weeks since I tried and I may not be remembering correctly (and I've since gone back to the "classic" WBStartup methodology, so it's not a big deal).
-
This will no doubt confuse the hell out of new users. Why haven't these tools been updated?
I guess it's because no one had time for that. So the question is more: why hasn't it been removed until something new and useful has been written ? Since it's right now useless and may confuse users
I guess this is because the team needs someone like you ;)
-
What default tool did you use? I thought I couldn't get anything going with RX, but it's been a few weeks since I tried and I may not be remembering correctly (and I've since gone back to the "classic" WBStartup methodology, so it's not a big deal).
For AmigaDOS scripts, C:IconX. For ARexx scripts, C:Rx
It used to be the case that the Rx command was in SYS:Rexxc, which doesn't appear to exist any more. Check your path to the executable, mine was still pointing at SYS:Rexxc/Rx at first.
-
For AmigaDOS scripts, C:IconX. For ARexx scripts, C:Rx
Hm, no. Just use "rx"
It used to be the case that the Rx command was in SYS:Rexxc, which doesn't appear to exist any more. Check your path to the executable, mine was still pointing at SYS:Rexxc/Rx at first.
All the commands in old SYS:Rexxc are reentrant and marked pure, so they can be resident, either manually or by setting the h-flag, why people insist on accessing disk all the time is beyond me.
But then again, this being OS4 ... who knows... :crazy:
-
Well, that should also work.
All the commands in old SYS:Rexxc are reentrant and marked pure, so they can be resident, either manually or by setting the h-flag, why people insist on accessing disk all the time is beyond me.
If you call the same command twice the chances are that the command will be in disk-cache memory anyway so it makes little sense to make it resident. Especially if it is used a couple of times during startup only.