Enhancer Software v1.1 installation observations & suggestions

I'm installing the Enhancer Software for the first time, and noticed various smaller & bigger issues:

* I was expecting it to be difficult to tell which software would replace existing OS4 components (which I wish to avoid as an OS4 beta-tester). But actually it is actually fairly obvious, and it does tell you when it's going to replace something, giving you the option to Skip it, and the original would be backed-up otherwise.

HOWEVER, whenever I come to install an updated Enhancer Software in the future, this might be far more confusing, since it will presumably warn that I am replacing existing components (even though some of them were originally installed by Enhancer Software & did not come with OS4). So it would still be very helpful if there was an up-front hint (say a * next to each item) that the software you are (un)ticking will replace standard OS4 components.

* It assumes you want to install all documentation to Sys:Documentation . I want it installed to each program's folder (like 99% of software), but baffling there was no such option, so I had to manuall tell it where to put it every time. And worse it creates a folder with the name of the program, so you'd potentially get (say) "Work:AmiDVD/AmiDVD/" for the documentation. So I ended-up tell it to put all Enhancer Software docs into the same dummy folder, and then moved it where I'd expect afterwards. This was probably the least use-friendly part of the experience for me.

* I installed the Plus Edition, but it mistakenly said it was going to install v1 of the RadeonHD driver (even though v2 is included), and then warned that it was going to install v0.0 (or replace or something like that). EDIT: It was not installed either, so something went very wrong here.

* Some components did not look like they would give me the option where to install them. e.g. RequesterChooser, and the Ringhio replacement. Even though they would work perfectly well if installed to alternative locations. (I have my own location for third-party Shell commmands.) (And as an OS4 beta-tester I cannot replace Rinhio, but I could try running an alternative if I felt like it.)

* At one point I chose to install something (probably Format) which turned out to want to replace a System component, so I cancelled the installer, and then "Installation Utility" crashed. Thankfully this wasn't the main installer though. Rather wierd.

* I found the monolithic installer a bit clumsy. I'd have prefered that there were individual installers for each real program (like CANDI), plus another installer for the system components. However, this would loose the ability for the installer to remember whether you wanted SDK stuff, where you want Catalogs installed, etc, so it's probably better for it to stay as a (mostly?) monolothic installer.

* It's not clear to my why I should want to install the "Diskcache Library" replacement, so I didn't.

* It was quite a hassle having to choose non-default locations for the various programs, so I'm *hoping* that it will remember those locations the next time I install an updated version of Enhancer Software. (My pessemism says this won't be the case, in which case consider this an enhancement request!)

* Some of the program's folder icons already had a snapshotted position (which would obviously be in a bad location), so I had to unsnapshot them. e.g. Exchanger, ClipViewer.

* Many of the program's folders were set to show non-icon files, so (for example) I'd see ghostly Catalog folders.

* I installed CANDI to location of my choosing, and OUTSIDE of the CANDI folder it created a Prefs folder for the CANDI prefs utility.

@ChrisH
As long as we're on the subject there are a few items I've already reported:

1. ClipViewer is less than useful if you use multiple screens because it always opens on WorkBench and doesn't bring the WorkBench screen to the front. I suggested that they add a FRONTSCREEN tooltype so that ClipViewer will open on the screen where you are currently editing. I also suggested a PUBSCREEN option and to have it bring the screen that it opens on to the front .

2. The Enhancer sound.datatype doesn't send a termination signal when it's requested by a program with SDTA_SignalTask & SDTA_SignalBitMask. In addition, mono sounds are played in only one channel instead of both stereo channels like the OS4 sound.datatype. The author did send me a sound.datatype with the signaling fixed; which I assume will be included in the next Enhancer update. He indicated that playing mono sounds in a single channel will remain.

3. Some Enhancer programs will freeze your system if you select the 'about' window. It's apparently due to not having a background set in GUI prefs. The new 'about' class shouldn't have been included until we get the OS4 fix for that issue. I'm guessing it's another case of testing with OS4 beta systems instead of the public OS4.1FE.

There is also a minor issue with the Enhancer distribution archive (lha). It's far larger than it needs to be. The enhancersoftware_plus.lha file is 128,524,348 bytes in size; which is a time consuming download for those of us with slower connections. When I extracted the archive and then recompressed it with OS4 LHA the size is only 76,926,385 bytes. Whatever means they used to create the enhancersoftware_plus.lha file, the file is actually slightly larger than the unarchived contents.

@xenic

Quote:
Unfortunately, there is no system-friendly (i.e. Intuition-supported) way to open on the frontmost screen. All programs that implement that (including Exchanger, I must confess) use a hack.

@xenic Quote:
Where is the "official" place to report stuff?

Quote:
Damn, you are right. This makes ClipViewer useless for me. Oh well, back to trusty ol' ClipHistory.

@trixie Quote:
Are you SURE about that? I thought the front-most public screen become the "default public screen", and thus the screen returned by LockPubScreen(NULL).

@xenic

Quote:

When it's started from an application via clipview.library interface it always opens on that applications screen. MultiViewer and MultiEdit both support this at the moment.


Quote:

No it;s nothing of the kind. The majority of Enhancers testers are not OS4 beta testers. This particular bug was not discovered till user with less common setups tripped over it after release. (though a similar bug in another prgram had been discovered the connection was not made, as it was not obviously a sub class of window.class).

The OS4 bugfix was made *after* release, as a consequanec of that extra set of bug reports.

Someties it works like that.

The issue can wok arround by adding a background pattern to you default setup (make it a really small one if you worry abouyt resources).

@ChrisH

Quote:

I never heard of that before, and I'm 95% it's not true, unless you are running some strange patch to make it so.

@xenic

Quote:

That does seem to be the case, never spotted that, I don't know what options Matthew is using , and whether there is specific reason for that or not.

@ChrisH
Quote:

I goes with the updated SFS2 IIUC.


Quote:

Yes, I agree the installation process is a pain, it really doersn't want you to installer anywhere but SYS: various beta tester have complained about this but we have only managed small compromises. Seperate installer sof r each app with eaxh app in own destination would be so much more flexible, for a collection like this where pople will want to pick and choose what to install.

It's good to hear at least one customer agree with what we were sceaming about :-0

@ChrisH

Quote:
Absolutely not. The fact that a public screen comes to front doesn't automatically make it the default public screen.

@xenic

Quote:
And your guess is wrong. I developed the InfoWindow Class on a plain OS4.1FE system (without any access to a beta installation), any many testers used the same standard system. The subclassing bug in the ReAction Window Class was only found thanks to InfoWindow Class revealing a problem when users run custom WB themes lacking the gadget background texture. So Enhancer couldn't have possibly waited for the OS to get fixed first; on the contrary: it was Enhancer that exposed a bug in the OS which had gone unnoticed for decades.

@broadblues

Quote:

Doesn't the old "SHANGHAI" patch do this? I'm not sure whether that's actually a patch or a tweak to some OS setting through public API (though I suspect the former).

It would probably be useful for LockPubScreen to have some sort of PUBSCREEN_FRONTMOST option (might need to be a new function for compatibility reasons).

@trixie
Quote:

In what official AmigaDOS documentation or includes did you read that?

I read this in the Intuition autodoc:

ULONG LockIBase( ULONG );
Grabs Intuition internal semaphore so that caller may examine IntuitionBase safely.

I read this in the intuitionbase.h include file:

/* the FirstScreen variable points to the frontmost Screen. Screens are
* then maintained in a front to back order using Screen.NextScreen
*/
struct Screen *FirstScreen; /* for linked list of all screens */

If you read the autodoc for LockScreenList() you'll see that it returns a pointer to the first screen which intuitionbase.h states is the frontmost screen.

It would probably be wise to check the front screen's flags to be sure it's a public screen before opening a window on it. Alternatively, it's possible that LockPubScreen() would fail if it's not a public screen or declared a private public screen.

Reading system structures and variables isn't always a hack.

@xenic

It's not safe to open windows on a custom screen that you didn't create yourself.

Also you need the name of the public screen for LockPubScreen(). You can't just open a window on the screen without locking it first.

What might work reasonable well though is reading the IntuitionBase->FirstScreen pointer and then comparing it to the psn_Screen pointers in the public screen list until you find the right one and from there getting the public screen name for LockPubScreen().

@salass00

LockPubScreen works with both screen pointers and names, so you don't necessarily need to know the name.

@Chris

No it doesn't you are confusing it with UnlockPubScreen()


struct Screen *screen = LockPubScreen(CONST_STRPTR name);

void UnlockPubScreen(CONST_STRPTR name, struct Screen *screen)

@salass00
Quote:
If you read my post carefully I said: "It would probably be wise to check the front screen's flags to be sure it's a public screen before opening a window on it."

Quote:

I assumed (apparently incorrectly) that a programmer would realize that you need to obtain the screen name before calling LockPubScreen(). Assuming that you found the PUBLICSCREEN flag in FirstScreen.Flags then something like GetScreenAttr(screen, SA_PubName, &data, sizeof(data)) should get you the public screen name. If it doesn't then the program would be forced to open on the default public screen (usually Workbench).

@Chris
Quote:

It's an input for SetPubScreenModes(). When used in conjunction with
SetDefaultPubScreen() it will force programs to open on a specified screen.

Quote:

Since LockPubScreen() expects a string that may not be possible. It would be convenient to have a new function such as "GetFrontScreen()".

@broadblues
Quote:

I don't think that's going to help the average user. I was going to try that for myself but don't see any autodocs for clipview.library in the Enhancer package. In fact, I can't find autodocs for a lot of the things in the Enhancer SDK directory. That seems a little incomplete to me and would request that autodocs for everything in the SDK directory be added for the next update.

@xenic

Quote:

SYS:Documentation/ClipViewer/ReadMe