Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: SamK on April 16, 2012, 06:15:04 AM
-
Probably most easily illustrated in the attached screen-shots:
- TC 4.1.png works OK
- TC 4.3.1.png not working
-
Now that fltk is an extension (fltk-1.10.tcz), you need to remove it from loading (/copy libfltk-xft over it, avoiding the need to change dep files).
While I could add a remove command to the -xft startup script, it wouldn't work if it was loaded before fltk-1.10.
The testing did show that the dep file needed Xorg-7.6-lib, so added that.
-
Now that fltk is an extension (fltk-1.10.tcz), you need to remove it from loading (/copy libfltk-xft over it, avoiding the need to change dep files).
In onboot.lst, fltk-1.10.tcz has been removed and replaced with libfltk-xft.tcz, producing the following:
Xlibs.tcz
Xprogs.tcz
Xvesa.tcz
libfltk-xft.tcz
kmaps.tcz
jwm.tcz
This is the entire list (no other tczs listed)
The testing did show that the dep file needed Xorg-7.6-lib, so added that.
As this is not listed in the .dep on ibiblio the tcz has been manually added to the existing .dep file.
No updates pending, no missing deps, all md5s OK.
Following a reboot the results are the same as the previously attached TC 4.3.1.png (not working)
-
fltk-1.10 is a dep of Xlibs and friends, IIRC, and gets loaded from there.
-
fltk-1.10 is a dep of Xlibs and friends, IIRC, and gets loaded from there.
Yes that is correct. Xprogs.tcz depends on fltk-1.10.tcz and Xlibs.tcz
Off Topic
AppBrowser-->Depends tab does not list those deps but the Size tab does.
onboot.lst adjusted to the following:
Xprogs.tcz
Xvesa.tcz
libfltk-xft.tcz
kmaps.tcz
jwm.tcz
Xprogs.tcz.dep manually edited to remove fltk-1.10.tcz, reads as follows:
Xlibs.tcz
Machine rebooted
Result=success
Interested readers might choose to also load a font to obtain an even greater improvement. My preferefnce is for ttf-bitstream-vera.tcz, but there are others that are even smaller.
Suggestions
- Xorg-7.6-lib.tcz might be an optional/soft dependency. Not loading it as a dep of libfltk-xft.tcz seems to produce no discernible differences
- As use of fltk-1.10.tcz and Xprogs.tcz will be widespread, it may be preferrable to avoid the requirement to manually edit a commonly used dep file. This will also simplify both installation and future upgrading. Making the adjustment in the loading of libfltk-xft.tcz in the way you previously mentioned would seem well suited in conjuction with the following suggestion
- Advice be added to the info file of libfltk-xft.tcz that indicates the manner of use for TC > 4.1.3, including guidance that it should be listed in onboot.lst after fltk-1.10.tcz/Xprogs.tcz
-
Advice be added to the info file of libfltk-xft.tcz that indicates the manner of use for TC > 4.1.3, including guidance that it should be listed in onboot.lst after fltk-1.10.tcz/Xprogs.tcz
Yes, that is a possibility, but it's still a hack (in the bad way).
As use of fltk-1.10.tcz and Xprogs.tcz will be widespread, it may be preferrable to avoid the requirement to manually edit a commonly used dep file. This will also simplify both installation and future upgrading.
That's why I suggested copying libfltk-xft over fltk-1.10. Then it's extension update and not dep update one has to mind, though.
-
Shortly after making my most recent post I stumbled on the following entirely by accident.
With both fltk-1.10.tcz and libfltk-xft.tcz listed in onboot.lst
The expected failure occurred. However, while in the failed condition opera9.tcz was loaded. This had the effect of reversing the failure into success for TC elements such as Control Panel, Editor etc.
Might it be possible to identify what happens when starting Opera9 and use the same machanism in the libfltk-xft.tcz startup and thereby allow both to be listed in onboot.lst?
-
That's why I suggested copying libfltk-xft over fltk-1.10. Then it's extension update and not dep update one has to mind, though.
This approach does not seem to work.
No change in presentation of font is produced when using only standard tczs and deps in onboot.lst, with Xprogs.tcz listed at the head and libfltk-1.10.tcz at the foot, or omitted from the list.
-
Sorry, my mistake. Forgot about the startup script.
-
Returning to this after further successful tests with TCv4.5.4. This produces such a big improvement when it is working, I am hoping to find some help.
Although the earlier post #6 quoted the use of opera9 it seems that downloading and installing any GUI tcz extension acheives a succesful outcome. This may indicate that an answer is already available within one of the existing OS scripts that handle download/install of tczs (unsuccessful using scm).
If it can be identified what is triggering this, it might be possible to use it as a standalone command, or add it to the startup process of libfltk-xft.tcz.
I have looked at:
- /usr/bin/tce-load
- /usr/bin/install
but cannot spot it. Perhaps someone with greater scripting ability might see it? Can anyone help?
-
You're right, and this is actually a clean way to work even with both extensions loaded.
The startup script is run after ldconfig; I'll add a ldconfig call to the startup script.
edit: update posted.
-
You're right, and this is actually a clean way to work even with both extensions loaded.
The startup script is run after ldconfig; I'll add a ldconfig call to the startup script.
edit: update posted.
It works well. Thanks