Good No more Font corruption for you ? My "fix" is not very clean but, unfortunately, I doubt that Alfkill will solve the QtWebKit font problem soon...
* [AmigaOS 4] Added "Download" download program from Tuomas Hokka. This program is used by default by DownloadVideo.rexx. Download is included in the SMTube drawer)
Thank you, Tuomas, to allow the inclusion of your program in another tools
* [AmigaOS 4] Fixed the fonts corruption at startup by simply adding and removing 1 pixel to the window (to force the font rendering refresh).
* [AmigaOS 4] Fixed the previous DownloadVideo.rexx that was broken in the previous package.
Can I make a suggestion? Rather than storing user customisations in "PlayVideo.rexx", they should be stored in a separate file, say "PlayVideo.cfg" (like GetVideo did), so that when a new version of SMTube is installed (and PlayVideo.rexx is replaced), SMTube won't stop working because they lost their customisations.
Good suggestion ChrisH. In the meantime, I rename my working PlayVideo.rexx to PlayVideo.rexx.good. Then update and delete the new PlayVideo.rexx and replace it with PlayVideo.rexx.good. (renamed to PlayVideo.rexx).
Then update and delete the new PlayVideo.rexx and replace it with PlayVideo.rexx.good. (renamed to PlayVideo.rexx).
@zzd10h Quote:
Or you can simply change the name of the REXX in SMTube player parameters.
That's not a good idea IMHO, because it means that when a new version of SMTube updates PlayVideo.rexx (to fix bugs or just so it works with new SMTube), then people will still be using the old (buggy/no-longer-working) PlayVideo.rexx code.
Quote:
PlayVideo.rexx is not replaced by AmiUpdate, but right, when i will have more time, I will look for a SMTube.cfg in ENVARC:
Can I suggest just storing it in the SMTube/Amiga folder (next to the ARexx script)? That's MUCH easier for users to edit, unless you are going to add a GUI for updating those settings.
@ChrisH "Can I suggest just storing it in the SMTube/Amiga folder (next to the ARexx script)? That's MUCH easier for users to edit, unless you are going to add a GUI for updating those settings."
If I do it, I will put it in ENVARC:, it will allow to upgrade smtube only by deleting/replacing the whole drawer.
If I do it, I will put it in ENVARC:, it will allow to upgrade smtube only by deleting/replacing the whole drawer.
Hmm, OK, I can see good as well as bad sides to using ENVARC:. Although I still disagree with using ENVARC:, why not just allow the config file to be stored in BOTH locations? Then users can choose whichever method (a) they are comfortable with, and (b) works best for them?
i.e. Just add one extra line of code. Check whether local path exists, and if not then fall-back to ENVARC:. (It makes sense that ENVARC: could be overriden by local version. And avoids the possibility of an "invisible" EnvArc: file causing the local config file to be ignored, which would confuse users.)