So, by installing Apache Open Office 4.1.1.1 (a follow up to the 4.1.1 GA) the missing DLLs should be in place?
Probably not. There is more to it than what is in the AOO4111 installer stuff. If you used AOO-4111-GA-rpm.wpi, and let it install those DLLs to the AOO4 program directory, those DLLs are in the wrong place, and will only be found by AOO, and only if AOO happens to be the first program to use them. All of those files need to be in either eCS\DLL, or OS2\DLL (depending on what you are using), so all programs can find them.
Thanks to all doing good work making this possible. Still, I must admit I much prefer Warpin over rpm yum (which to me looks very archaic).
I am working on a WPI installer, for FF 24.8.1 b4, but the new requirements are being problematic. Since it appears that none of the stuff managed by YUM has any BLDLEVEL information, it is impossible to tell what version of the required DLLs that a user has installed (dates don't mean much). That means that it will be necessary to install all new, whether they are already there, or not (just to be sure). That causes two problems. One is that a user may have installed some, or all, of that stuff somewhere else (that is just asking for trouble), and some older WarpIn installers may have been used, so I need to figure out how to correct the WarpIn database, when I install things that have previously been packaged by others. Without doing that, a user is going to have trouble with the WarpIn database later. I also need to consider what other programs require, and there is always the possibility that updating something for Firefox, or AOO, will break something else (especially if the DLLs are duplicated, or in the wrong place). Then, there are some partial packages out there already. One, that I know about, packages the new GCC1, but only two of the many forwarder DLLs (AOO-4111-GA-rpm.wpi does the same thing). Doing that means that the user has an incomplete install of the GCC1 stuff, and that could come back to haunt the user later.
Currently, if you want that stuff managed, you need to use YUM. YUM keeps a database of what it installed. The biggest problem (other than the horrible YUM interface) is that a user can change something, and YUM may not know about that. YUM also creates a whole new place to keep stuff (the *NIX directory structure), and leaves behind whatever was already installed in other ways. That results in duplicates, and, eventually, some program will try using the wrong one. That will cause the old "sometimes it works, and sometimes it doesn't" problem. Very difficult to determine what is going on. The only ways to keep that stuff under control is to start with a newly installed system, with RPM/YUM already installed, then do not ever update anything unless you use YUM (that becomes a problem, because not everything is packaged for YUM). OR, you can manually clean out everything that YUM didn't install. That means that you need to know exactly which files YUM controls, and leave behind all others (which are probably program specific). Then, you need to do that again, every time YUM adds something new. It is a logistical nightmare for OS/2 users, whether you use YUM, or not.
Fn+Fx working
That is probably part of ACPI. I am pretty sure that the ACPI function exists, but we have no program to use it.
I will also note, that I have been refused access to more than one web site, recently, with a notice that I need to update my browser. FF in windows is now at v 36.0.1. This is probably just stupid web design (driven by paranoia), but it does mean that I need to use windows to get to that stuff. Fortunately, the current FF for OS/2 works for most things, for now.
I will also note, that the new FF seems to get along better with other bloated ported programs (AOO4) than the older versions did. It is said that the FF DLLs (including XUL.DLL) can now be loaded high, but it is not clear if that is already done, or if a user needs to do something to get that to happen. Anybody know?