I've just posted a pre-release of AbiWord Portable 2.4.5 with OpenDocument support. This new release features the following changes:
Registry Changes Saved - Although AbiWord automatically reserves the abw and zabw file types and adds another entry to the registry on the local PC, the AbiWord Portable launcher automatically removes this when you close AbiWord. It will even preserve your existing registry settings if you have a local copy of AbiWord. And it has account type detection so this will work correctly with guest and limited accounts under Windows 2000 without error.
Live CD Support - AbiWord Portable now fully supports running from a CD. The registry backups are stored within the TEMP directory on the local PC while running, so the location you run from doesn't need to be writeable. Just be sure you run AbiWord Portable at least once from a writeable location before copying it to CD so it can generate a set of default settings.
In-Place Upgrades - AbiWord Portable now supports the ability to do what I'm calling an "in-place upgrade". This means that you can extract it right over an existing installation of AbiWord Portable without losing any of your existing data and it'll Just Work (tm). Obviously, this will be going forward as you'll need to manually upgrade this time due to the new directory layout.
WINE Support - The new launcher has been written and tested to work with Wine within your favorite UNIX/Linux distro. You can both install and run AbiWord Portable within Wine without issue. UPDATE: It looks like you can just do an install and configure it within WINE... the AbiWord renderer doesn't seem to work within WINE unfortunately.
AbiWord Plugin Installation Support - The directory structure of AbiWord Portable has been updated to work with the standard AbiWord plugin installers right out of the box. You can download the AbiWord Import/Export or Tools Plugins from the AbiWord download page and install them right into AbiWord Portable. When asked for the installation location, just be sure to change the default (C:\Program Files\AbiSuite2) to the location of AbiWord within AbiWord Portable (X:\AbiWordPortable\Apps\AbiSuite2).
New Splash Screen - The new splash screen will show even while the launcher is backing up your registry entries and prepping for launch, which is handy when running from a USB 1.1 device or slower CDROM drive.
Grab the self-extractor here:
AbiWord Portable 2.4.5 Pre-Release
Please give the new features a try and drop a note back with your thoughts.
UPDATE (Aug 9): There was a bug in the launcher's handling of INI files. It's been fixed in a new version of the launcher. Download the AbiWord Portable Launcher 1.2.1.3 and drop it into your AbiWordPortable directory.
Thanks,
John
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I use Abiword Portable almost every day, so it will be easy to test this. So very happy about the Open Doc support being included, too.
~Lurk~
~Lurk~
A few things I noticed while testing:
- I'm not sure if it was intended, but the OpenWriter plug-in (i.e. the filter for .sxw files) was included as part of the package.
- AbiWord's splash screen is disabled by default. I think this was intended, though, considering the new splash screen.
- Running from a read-only USB drive produced a number of "AbiWord.exe - Write Protect Error" messages when running the NSIS launcher, even after I made sure to run AbiWordPortable.exe from my local drive first. I believe this is caused by logging in AbiWord.profile.
- Wine doesn't seem to support Uniscribe very well (or maybe at all?), so text rendering doesn't work. To work around this limitation, I added DefaultGraphics="0x104" to the <Scheme name="_custom_" section of my AbiWord.profile file (in AbiWordPortable\App\DefaultData\settings\). This forces AbiWord to use the old text renderer, which is no longer maintained, but will at least let you see your text as you type. (I know this problem is beyond the scope of AbiWord Portable, but I thought I'd mention it in case someone else runs into trouble :).)
- Your local path to AbiWord is included in the <log> section of the AbiWord.profile. It won't affect portability, but it might be something you don't want included (i.e. for privacy reasons).
1. Yes, the OpenWriter is included as well. I did it for now, but may avoid it in the final release (it's 200k)
2. The splash screen is disabled by default as there is the one in the launcher.
3. I'm aware of the errors. From a CD, these will not be generated (and the Live feature is primarily intended for CD use where AbiWord is concerned). I'm debating including a RunLocally option in the INI. Unlike the other apps (FF, TB, SB, NVU), this would only be of use to folks with a read/write switch on a USB flash drive... which are few and far between and most manufacturers indicated they won't be shipping anymore.
4. Nuts, I missed that. Looks like there may be no way for this to work.
5. I know the path was in there, I don't care that anyone knows my login on my test box
Sometimes, the impossible can become possible, if you're awesome!
If I copy the example included to the folder containing AbiWordPortable.exe the following errors occur
1) the settings I modify (like interface language) are not used in the following session.
2) editing the ini file to DisableSplashScreen=True, disables the Portable splash but shows the AbiWord splash
There was an issue with the launcher and INI files. I've posted an updated launcher that should fix it.
Sometimes, the impossible can become possible, if you're awesome!
It does fix it but it requires that the ini file is a copy of the example included with just the values modified.
If you create an INI file with just the following two lines (since I only want to change one setting) it won't work...
[AbiWordPortable]
DisableSplashScreen=True
You need to include all the variables. Every one of the launchers works that way. If they didn't, it would require quite a bit of extra code to manually check every INI setting, see if it's blank, if it is try to figure out what it should be, etc. No real need for all that extra work (and supporting all that extra code going forward), especially since most people don't need the INI.
Sometimes, the impossible can become possible, if you're awesome!
Ok. I was about to say that it also happens with FFP.
Maybe you should explain that in this thread https://portableapps.com/node/2559 also
And include that explanation in the readme.txt included in each Source folder.
Thanks!
Is probably someone not moving the INI to the right place. Or trying to use an older INI with a newer release (which won't work). It explains in the INI and in the readme.txt that you can't use it from its current location, but some people don't seem to know how to read that part of the instructions.
Sometimes, the impossible can become possible, if you're awesome!
Being a non-native english speaker/writer I have to admit that the sentence is not as clear as could be: "The AbiWord Portable Launcher will look for an ini file called AbiWordPortable.ini within its directory."
How about adding "Therefore the AbiWordPortable.ini file must be placed in the same folder as the AbiWordPortable.exe file. The user can edit the values (e.g. change true to false) but can not change the number of lines or reorder the entries."
I know this is a bit too obvious but sometimes the KISS method is the best
Cheers!
Hadn't considered that it might be a language barrier for some. I'll add something like that to subsequent releases. It's too late for ClamWin (already packaged), but I'll add it to AbiWord. Thanks for the idea.
Sometimes, the impossible can become possible, if you're awesome!
Actually, you can reorder the entries. I do it all the time to keep my INIs clean.
-
< ExplosivePrincess 1.5 Atomic Bomb Edition >
warning: keep explosiveprincess away from children
Hmm. The Win32 INI functions allow you to specify a default value for all INI read operations. Makes it easier to implement default settings, and you don't even have to check for the existence of the .ini file beforehand, since if the file doesn't exist, the function will just return the default value. Same goes if the file does exist but the specified entry doesn't.
I guess NSIS doesn't have that functionality?
-
< ExplosivePrincess 1.5 Atomic Bomb Edition >
warning: keep explosiveprincess away from children
And even if I did have a default, I'd have to check for that and then do the DIR hunt routine checking possible locations for the EXE afterwards... for each value separately. That's a lot of extra unnecessary work.
Sometimes, the impossible can become possible, if you're awesome!
Programming the thing in C made it so much easier. NSIS only has goto so you're jumping all over the place, making the code difficult to follow and hard to manage. I can see why you'd be hesitant to implement such functionality.
-
< ExplosivePrincess 1.5 Atomic Bomb Edition >
warning: keep explosiveprincess away from children