SoftMaker's FreeOffice2021 + TextMaker, Planmaker & Presentations component builds in 'portable' format...

[mikewalsh]

Morning, gang.

Greengeek has slightly "beaten me to the punch" here, I have to say! FreeOffice is the only office suite I've ever packaged/published for the community, following which you may recall I published a 'standalone' version of Textmaker following some discussion around the subject with Mikeb, since most folks only ever seem to use the WP portion of any office suite.....and when I built it a couple of years ago, there was a steady trickle of complaints about Abiword misbehaving itself.....crashing & losing people's work.

The 'standalone' Textmaker worked out really rather nicely, I must say.

-----------------------------------------------------------------

I've been playing around with trying to get Textmaker to work as a self-contained portable for some time. I don't know what I did differently tonight, but for the first time ever I got a small message box come up, stating there was a 'critical error; a resource cannot be found', and instructing me to use a specific variable to locate the main FreeOffice directory. A-ha.....

Well, after that wee piece of info, it all 'fell into place', as it were.....and construction of the 'portable' version was very soon finished. Having done that, I then proceeded to build a 'portable' version of the full FreeOffice suite (since much of the construction was identical), so.....

The FreeOffice 'portable' also has a mini YAD-powered 'StartCenter' GUI.....just to make selection a bit easier. The GUI does remain open behind whatever you've selected, and needs to be manually dismissed, but this was the only way I could figure out to keep the sym-links in place while everything was running. It's the closing of the 'StartCenter' that actually 'closes' everything, and removes the sym-links again. If the GUI is set to auto-close, the launch script thinks usage is over, removes the sym-links, and re-runs the script again, in the process creating a brand new config directory. Which defeats the whole point of being 'portable'....

It may not be as 'tidy' as some of you would like, but it works for me. If anyone's got suggestions on how to let the GUI auto-close without shutting everything down, I'm all ears..! (No, I don't know it all. Far from it. I'm still very much a long-term 'noob'...)

These are all constructed around the current '982' service pack, so as up-to-date as possible.

-------------------------------------------

For anyone who may be interested in running them this way, both can be found at my MEGA.nz a/c, here:-

https://mega.nz/folder/LShHgaCC#QKEiIMMQDVlvQPdJ5IHcWw

32- AND 64-bit versions of both portables can be found here......however, where the 64-bit packages are the newest 2021 variant, the 32-bit packages are the older 2019 release, I'm sorry to say. Navigate through, and help yourselves to the one you want.

As always; d/l; unzip; place the portable directory anywhere you want.....outside the 'save', of course! Click to enter, click 'LAUNCH' to fire 'em up. There's also optional scripts to add a Menu entry, to start them from wherever they're located, if required. The 'MenuReadMe' explains how to use these.

Hope they're useful. Enjoy.

Mike.

[keniv]

@mikewalsh
Hello Mike,
Just a question on your portable version as compared with the .sfs version on @greengeek's thread. There was a discussion about what files were put into /root when the .sfs was loaded in which you took part. (See viewtopic.php?t=4212&start=10 around six or seven posts down. I will use @greengeek's version for my copy of Dpup Stretch and Quickpup as they are 32 bit but I thought I might try your portable 64 bit version for Busterdog, EasyOS 2.9 and Bionicpup assuming it works in them all. Now here comes the potentially stupid questions.
1) Will the files mentioned above that are placed in /root when the .sfs is being used be contained within the portable?
2) Will a document produced in a 64 bit version be readable in the 32 bit version and vice versa? I assume this will be the case but I just want to double check this.

Regards,

Ken.

[mikewalsh]

@keniv :-

Hiya, Ken.

Nah, don't be silly, mate; questions are welcomed. I've got no problems with answering 'em.

Accordingly:-

• 1) Yes, /root/SoftMaker- which is the only config item they now create with the current builds - IS created within the 'portable'. The 'Launch' script sym-links this into position immediately prior to firing Textmaker up; when you shut Textmaker down, the sym-link is removed again. Because it IS a sym-link, anything written to /root/SoftMaker is in fact going straight into the 'portable' directory anyway. This is one of the 'corner-stone' concepts behind the creation of these portables, and was right from the first one I built.

• 2) Very definitely. A lot of the files in both builds are identical, and are "arch-agnostic"; you can swap them between versions, and they still function perfectly. I've never yet found a document that can't be read from/written to by either arch version of any office utility.

Softmaker are, of course, one of the few projects that still regularly build 32-bit packages. Long may they continue.....but I'm NOT gonna be holding my breath for too long..!

Hope that sets your mind at ease. Oh, one other wee item; if, as & when you DO get one of these product keys - a totally issue-free procedure, BTW - do what I've done.....keep the darn thing in a safe place, just in case you need it again. AFAIK, they have no 'expiry' date on them, so can be re-used over and over again.....up to a point, anyway (somewhere between 25 & 50 attempts, I believe). More than most of us will ever want.

If you do need to obtain another one, the process is now a lot simpler. The key used to only come along with a download of FreeOffice, but you've been able to obtain it on its own for some time now.

I know you Scots are a cautious bunch, but ya CAN take it too far, y'know..!

Mike.

[keniv]

Hi Mike,
Thanks for answering my questions and all the other information. I think I'll give it a try. I'll manually remove anything to do with my previous attempts at installation before installing your portable. I'll report back on how it goes.

I know you Scots are a cautious bunch, but ya CAN take it too far, y'know..!

Yes you're right. As far as anything to do with this stuff is concerned I'm a typical cautious Scott but it's not all bad. My dad was English as is my wife and my daughter married an Englishman and I have two very English granddaughters.

Regards,

Ken.

[MochiMoppel]

@mikewalsh I've downloaded your Textmaker package, not the big FreeOffice one, so I can't say anything about your GUI because your Textmaker doesn't appear to have one.

Your LAUNCH script does a lot of symlink acrobatics:

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"
SMPATH="$HERE/usr/share/freeoffice2018"
mkdir "$HERE/config" 2> /dev/null
mkdir "$HERE/config/SoftMaker" 2> /dev/null
if [ -d "/root/SoftMaker" ]
then 
	rm -rf /root/SoftMaker
	ln -s $HERE/config/SoftMaker /root/SoftMaker
else
	ln -s $HERE/config/SoftMaker /root/SoftMaker
fi
"$SMPATH/textmaker" "$@"
rm -rf /root/SoftMaker

If you want to avoid the creation of /root/SoftMaker you could use something like this:

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"
SMPATH="$HERE/usr/share/freeoffice2018"
> "$SMPATH/portable.txt"
exec "$SMPATH/textmaker"

Placing an (empty) file called portable.txt into the same directory as the textmaker binary will cause textmaker to create the SoftMaker config directory in the directory of the binary. No need for symlinks.

[mikewalsh]

@MochiMoppel :-

Ah, thanks for that, Mochi. Very useful information. I've tried this out with a 'test' copy of Textmaker-portable, and yes, you're right.....it keeps everything "in-house".

Was this something you experimented with to see if it would work, or is this info that SoftMaker provide somewhere in their documentation?

I've come across a few other applications that do something similar to this. The torrent downloader, Tixati, for example, has a file in the 'portable' version called tixati_portable_mode.txt. It's not 'empty', but merely contains a few lines of text explaining why it's there:-

PLEASE DO NOT DELETE THIS FILE

This file will cause Tixati to run in portable mode. It will
keep its settings and other configuration files in this folder.

If you remove this file, Tixati will not run in portable mode
and will store its settings in the user appdata folder.

For more information about Tixati, please visit www.tixati.com

I would guess the binaries are coded to look for this file because you can separate out the 'tixati' directory from the 'standard' install, add this same file, and, once again, it will act like a 'portable'. (AFAICT, all versions of Tixati contain binaries for both 'arches' in the same directory.)

Cheers, Mochi. That is much appreciated. I'm guessing the same trick should work for the full FreeOffice suite, too.....I'll experiment with this, and report back.

(Incidentally - in case you may be wondering - the reason why my 'portable' is so much bigger than greengeek's package is simple; like this, the 'portable is in the 'unpacked' condition.....plus, mine contains ALL the 'localization' stuff, whereas Ian has stripped most of that out and just left the English files.)

Thanks, mate!

Mike.

[mikewalsh]

Now; just as an 'update', following Mochi's information above about the portable.txt file:-

It all works nicely for the full FreeOffice suite, too. No need of the 'sym-link acrobatics' as Mochi referred to them; the main config directory is now created inside the 'freeoffice-2018' directory, so there's henceforth no need of a separate 'config' directory at the top level.

It's possible this same trick (or something like it) would work for some of the other 'portables' which retain a full file structure within the directory. It won't, however, work for the majority of my 'portables' that are built around AppImages; by their very nature, these only ever unpack themselves temporarily into /tmp for the duration of a session. There's nowhere a config directory could reside permanently.....except in the 'regular' locations.

----------------------------

I've re-uploaded the re-built versions of these to the same location as before, so the link in post #1 is still the place to find them.

Mike.

[fredx181]

It's possible this same trick (or something like it) would work for some of the other 'portables' which retain a full file structure within the directory. It won't, however, work for the majority of my 'portables' that are built around AppImages; by their very nature, these only ever unpack themselves temporarily into /tmp for the duration of a session. There's nowhere a config directory could reside permanently.....except in the 'regular' locations.

If I understand well what you're saying, note that there are options by nature for appimages to create config (--appimage-portable-config) and/or home (--appimage-portable-home) , at the same level of the appimage, see when running with --appimage-help :

Code: Select all

./myappimage --appimage-help
AppImage options:

  --appimage-extract [<pattern>]  Extract content from embedded filesystem image
                                  If pattern is passed, only extract matching files
  --appimage-help                 Print this help
  --appimage-mount                Mount embedded filesystem image and print
                                  mount point and wait for kill with Ctrl-C
  --appimage-offset               Print byte offset to start of embedded
                                  filesystem image
  --appimage-portable-home        Create a portable home folder to use as $HOME
  --appimage-portable-config      Create a portable config folder to use as
                                  $XDG_CONFIG_HOME
  --appimage-signature            Print digital signature embedded in AppImage
  --appimage-updateinfo[rmation]  Print update info embedded in AppImage
  --appimage-version              Print version of AppImageKit

Portable home:

  If you would like the application contained inside this AppImage to store its
  data alongside this AppImage rather than in your home directory, then you can
  place a directory named

  /mnt/sda3/myappimage.home

  Or you can invoke this AppImage with the --appimage-portable-home option,
  which will create this directory for you. As long as the directory exists
  and is neither moved nor renamed, the application contained inside this
  AppImage to store its data in this directory rather than in your home
  directory

From my experience the myappimage.home works best (I just create the directory manually before running the appimage, then it's NOT required to run it with --appimage-portable-home)
EDIT: This all goes for the newest type of appimages (based on squashfs), not for appimages from many years ago (when just started), those are different.

[mikewalsh]

@fredx181:-

Oh, I agree with everything you've just said, Fred. My point being with an AppImage, you cannot physically locate the config files within the AppImage itself.....and you and I both know why this is so. If I were to create an AppImage of TextMaker, I couldn't use Mochi's tip to physically locate that config directory within the body of the AppImage; at least, from MY understanding I don't believe that's possible.

(This is all the more the case with SoftMaker, since examination of one of the .ini files within the 'Settings' sub-directory shows that it will always attempt to re-create the config files at whatever the physical location was at the exact moment when the config directory was first created. I found this out just a couple of hours ago. If you re-locate it, it then creates an 'orphan' directory at the place you've just moved it from..!)

I suppose it might be possible to use the 'tee' command to re-write the current location, but how could this work from within a 'packed' AppImage? Or could such be created within the /tmp directory where it's been unpacked at runtime?

If I'm wrong, mate, feel free to correct me; I'm always willing to learn!

Mike.

[fredx181]

@mikewalsh

Yes, I see what you mean now, it is set to absolute path for settings dir.

And thanks for sharing this.

[mikewalsh]

Now then, guys'n'gals.

Further discussion over on the other thread:-

viewtopic.php?p=39291#p39291

.....reveals that Mochi apparently runs what he calls a 'nanobarebones' version of TextMaker, using just three files. I've experimented with this, and, while it DOES work, there's a few things about it I'm not too happy with......and a few things I believe should be left in. However, he uses Japanese fonts, and I have no idea how those render. I know that Western Latin text, running in 'barebones' format like this, renders as a very washed-out, pale grey Basic Roman text.....meaning that the app's own fonts - Menu bar/ribbon,other stuff - are (for me at least) extremely hard to read!

(Personally, I run TextMaker in 'dark' mode, but even in the other two, it's still a very pale grey text.....which is far from ideal.)

So; I've done some experimenting, and have put together a stripped-back, English-only, 'micro' TextMaker-portable. I'll demonstrate below what's in there, and why I think it should be left in.....

(Vid recorded entirely with Will McEwan's "WeX-portable"; neat, huh? 'Specially that webcam feed.... )

In my opinion, you can't really go much more 'bare-bones' than that, and still retain proper appearance and full functionality. Yeah, I know; this rig is NOT really a Puppy box at all any longer, and many of my recent Puppy-portable 'offerings' HAVE been somewhat on the large side. I am still very much aware that plenty of you are using far older, less-powerful hardware.....and, moreover, that some of you do actually like to keep everything as tiny as you possibly can.

The tarball for this is around 22 MB; unpacked, around 36 MB. Not exactly 'tiny', no.....but still a decently small size, I feel.

If anybody's interested, you'll find them here:-

https://mega.nz/folder/DCxUVT5R#Uksv_F8qBGYn5mtEKeQOyw

Both arches are available. I haven't bothered with the MenuAdd scripts this time, and the 'config' directory for the usual sym-linking trick isn't required on this occasion. Just a basic , self-contained 'portable'; click to open, then fire it up from there.

Hope some of you may find it useful, and appreciate it.

Mike.

[fredx181]

Nice work Mike !

(Vid recorded entirely with Will McEwan's "WeX-portable"; neat, huh? 'Specially that webcam feed.... )

And good to see you "in person"

[mikewalsh]

@fredx181 :-

Nice work Mike !

(Vid recorded entirely with Will McEwan's "WeX-portable"; neat, huh? 'Specially that webcam feed.... )

And good to see you "in person"

Ha! Yeah, you finally get to see what an ugly bastard I really am, eh..?

Mike.

[fredx181]

@fredx181 :-

Nice work Mike !

(Vid recorded entirely with Will McEwan's "WeX-portable"; neat, huh? 'Specially that webcam feed.... )

And good to see you "in person"

Ha! Yeah, you finally get to see what an ugly bastard I really am, eh..?

Mike.

Oh.. no, not at all !! You look like a really nice person, but one thing; look in the camera next time ! and btw, where can we find your "donate" button ?

[mikewalsh]

@fredx181 :-

'Donate' button, huh? Eeh......that'll be the day!

Nah, joking aside, I'm hoping this might prove to a worthwhile replacement for the recalcitrant, misbehaving Abiword......at least in the short-to-medium term. We'll see.

Rome wasn't built in a day, mate....

Mike.

[mikewalsh]

Now, then.

Since I don't wish to be accused of alienating those Puppians for whom English is not their native language, I've extracted the rest of the 'langpack' files from the 'full' TextMaker-portable, and have bundled them up in a tarball.

Since the idea of this 'micro-portable' is to keep it as small as we can, we only want the one language file to be present within the portable directory. Accordingly, download the 'langpacks' tarball (you'll find it alongside the 'micro-portables'):-

https://mega.nz/folder/DCxUVT5R#Uksv_F8qBGYn5mtEKeQOyw

Then, unzip the tarball; delete the 'default'

Code: Select all

textmaker_us.dwr

....file, and replace it with the one for your preferred locale. I assume y'all should know by now which locale suffix is the one you'll need.

This will hopefully keep it relevant for the entire community.

Mike.

[MochiMoppel]

viewtopic.php?p=39291#p39291
.....reveals that Mochi apparently runs what he calls a 'nanobarebones' version of TextMaker, using just three files. I've experimented with this, and, while it DOES work, there's a few things about it I'm not too happy with......

Such as?

and a few things I believe should be left in. However, he uses Japanese fonts

He does not - at least not when testing.

I know that Western Latin text, running in 'barebones' format like this, renders as a very washed-out, pale grey Basic Roman text.....meaning that the app's own fonts - Menu bar/ribbon,other stuff - are (for me at least) extremely hard to read!

I don't know what "extremely hard to read" means to you. Using only Puppy's default fonts and none of the app's own fonts (barebone = no fonts directory !) it looks acceptable to me (see screenshot). What is disturbing though is that Textmaker opens the document with a default font "Basic Roman", which of course is bogus as this font is not installed, just like the other SoftMaker fonts in the dropdown list like "Calibri" and "Cambria". Pretty embarrassing behavior of a word processor. In my case what masquerades as "Basic Roman" is in fact "Nimbus Sans L".

One more thing: To make it really "portable" you might also have to take care of the /etc/SoftMaker directory which is created even when a portable.txt file is present.

[mikewalsh]

SoftMaker FreeOffice 2021 released.....

Afternoon, gang.

Well, the FreeOffice 2021 release has finally landed, I'm pleased to say:-

https://www.omgubuntu.co.uk/2021/10/sof ... 1-released

Unfortunately they, too, are treading the well-worn path followed by every other software developer in recent years, and are now producing it as 64-bit ONLY. So those of you who run 32-bit Pups will have to be content with FreeOffice2019, I'm afraid.

--------------------------------

I've re-built it into the 'portable' format I finally figured out for the last release.....including MochiMoppel's tip about creating the empty 'portable.txt' file in the main directory, which causes FreeOffice to create its config directory in the same location. So no need for any sym-links with this one.

I've also re-built the 'TextMaker' standalone 'portable' to use the 2021 Textmaker modules.

Both can be found at the link in post #1. Hope they're useful.

Mike.

[mikewalsh]

@MochiMoppel :-

I know that Western Latin text, running in 'barebones' format like this, renders as a very washed-out, pale grey Basic Roman text.....meaning that the app's own fonts - Menu bar/ribbon,other stuff - are (for me at least) extremely hard to read!

I don't know what "extremely hard to read" means to you. Using only Puppy's default fonts and none of the app's own fonts (barebone = no fonts directory !) it looks acceptable to me (see screenshot).

I think the reason for this behaviour - for me - is because I'm not using a standard Puppy theme (most of which are variations of black text on a white background.) When I set my Pups to use the default theme, everything shows fine, as you say. However, after years working with highly-abrasive powders in the minerals-processing industry, I have crap eyesight which cannot bear bright light.

I couldn't find a Puppy-specific dark theme that I actually liked, so I tracked one down - named "Shades of gray" - over on the Gnome website. Mostly this runs fine in Puppy (it has a GTK2 component as well as a GTK3 one), but with SoftMaker doing things the way we've been discussing, the text comes up as a very dull gray on an already dark gray background. Which for me makes it pretty near invisible....and is, I believe, why I've had to include some of the default fonts. I haven't figured out which one it is, but at least one of them correctly renders white text on a dark background for this particular theme.

Mike.

[mikeslr]

Hi, I'm not sure if I'm using your current version or an earlier version of TextMaker. But, after opening it several time I received a notice of the need to register. Registration merely requires providing an email address.
As I posted several times, its publisher --Softmaker Office-- is a reputable company which doesn't abuse its knowledge of one's email address. A couple time a year it will email an offer to obtain the current, full version of Softmaker Office at a discount; or provide a free font as a way of keeping you interested in its product.

I just wondered if somehow I screwed things up so that I receive that notice rather than not.

[mikewalsh]

Portable FreeOffice 'component' builds...

Afternoon, gang. Now then:-

Having already produced the "Textmaker" component as a standalone app, and over the last few days, done the same for the "Presentations" (PowerPoint-equivalent) component, I thought I may as well go the whole hog and turn the remaining "Planmaker" (spreadsheet) component into a standalone, too.

So; the link is the same as in post #1.....but there are now directories for Textmaker, Planmaker and Presentations, too. Each of these contains a 'portable' standalone version of just that one component of the full office suite.

As before, 64-bit versions are the current, 2021 build; 32-bit versions are based around the previous 2018 build with the 2019 update. Softmaker only produce 64-bit builds now, so that's WHY.

Usual caveats apply:-

• Download

• Unzip

• Move 'em anywhere you like, but preferably OUTSIDE the 'save'

• Click to enter

• Click on 'LAUNCH' to keep 'em totally portable.....or, for greater system integration, you can use the supplied scripts to add/remove a Menu entry. The 'MenuReadMe' explains what to do with these

Hope they're useful. Enjoy.

Mike.

[jrb]

32-bit versions are based around the previous 2018 build with the 2019 update. Softmaker only produce 64-bit builds now, so that's WHY.

Sadly both FreeOffice2018 and SMOffice2018 quit working in ScPup32's some time ago. Office2021's (64bit) kept working. It's taken me awhile but I finally figured a fix. I've no idea wether this is true in other pups, only running ScPups these days.

Turns out the culprit was libcurl.so.4. I grabbed libcurl.so.4.6.0 and the libcurl.so.4 symlink from ScPup32-20.06, placed them in an "extralibs" folder in /Textmaker2019-portable32 and modified the LAUNCH script with:

Code: Select all

HERE="$(dirname "$(readlink -f "$0")")"
LD_LIBRARY_PATH=$HERE/extralibs${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}

Works a treat now.

Also works in your Textmaker standalone and I presume your other standalones.

I hope this helps others out there. Some of us still happily run 32bit machines.

Cheers, J (and Thanks)