Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: mcewanw on March 15, 2017, 11:19:22 PM
There is a fair amount of interest on murga puppy forum in Core and dCore, with a project thread started there planning to use Core or dCore to build a puppy-lookalike. I have recently posted a 20 step HowTo there, which shows how to install dCore-xenial onto a usb-stick (or harddrive) booted via grub4dos (which is what most Puppy users are used to) and in a file directory structure more familiar to Puppy and DebianDog/XenialDog users. You can find the howto here:
Searched forum but can't find answer to the following, sorry.
Having a slight issue with getting icons to automatically appear onto wbar following sce-import and sce-load. I note that the .desktop file should contain a line of the form X-FullPathIcon=<full path to desired icon> but that only seems to work if the apps desktop file is stored in /usr/local/share/applications and not (like most Ubuntu apps) if stored in /usr/share/applications. Should the mechanism not search through various possible locations for the apps desktop file?
Also, I find that an icon for firefox (currently ver 52.0) does appear in wbar even though I can't see any reference to X-FullPathIcon in its desktop file. How does that work?
Many thanks in advance for enlightenment on these issues.
I have not used wbar in a while, was working last time i did. I will revisit it. Either /usr/share/applications or /usr/local/share/applications should work in dCore for. desktop files. And the X-FullPathIcon= should not be needed.
I just had a look in /tmp/tcloop/wbar/usr/local/bin/wbar_update.sh since that looked like a likely script to auto-put the icons on wbar. I note that there is code for both /usr/share/applications/ and /usr/local/share/applications.
At a glance the code does check for X-FullPathIcon but only for the /usr/local/share/applications case.
For /usr/share/appliations case it seems to check "Icon=" and expects the name given there to be in /usr/share/pixmaps as a png or an xpm. I'm guessing that's why it maybe doesn't always find the icon (since might be stored elsewhere). I guess X-FullPathIcon isn't checked for /usr/share/applications desktop file case because special tinycore-made extensions are always designed for /usr/local/share/applications so only these are likely to be manually modified to include X-FullPathIcon line? Makes sense.
If above correct, nothing to worry about. Easy enough to add the icon to wbar manually or via wbar-config.
My understanding of how wbar gets populated dynamically seems to be correct. I can add app icons onto it simply by copying their desktop file to /usr/share/applications and making sure that /usr/share/pixmaps contains a correctly named icon per the Icon= description in the desktop file.
I note, however, that there is a tinycore utility called tc-wbarconf, which should allow exclusion of any unwanted app icon (via a list contained at /etc/sysconfig/tcedir/xwbar.lst).
Unfortunately, tc-wbarconf messes up xwbar.lst (doesn't correctly remove the selected i, t, c entries for the app selected; removes some of the i,t,c entries from other apps - results in big mess...). My observation seems to concur with that of tinycore forum member emninger in the forum post here, though most seemed to suggest tc-wbarconf was fine, which I'm pretty sure isn't the case:
I've had a quick look at source code for tc-wbarconf but unfortunately, though I am familiar with C programming, I am not familiar with fltk fluid programming so cannot determine the cause of the problem within the source. For the moment, I workaround the issue by simply modifying xwbar.lst manually.
If you can give me a few examples of items that work with tc-wbarconf and some that don't I will check it out tonight.
I've found what is causing the problem for me Jason, but I don't know of a fix (aside from avoiding use of tc-wbarconf on my system).
The problem turns out to be that tc-wbarconf messes up the xwbar.lst file if the underlying system shell (/bin/sh) being used is bash rather than /bb/ash.
In Debian you can switch default /bin/sh from dash to bash using command 'dpkg-reconfigure dash' but I don't know if there is a specific command to change ash to bash in tinycore (and doubt that would make any difference to the tc-wbarconf issue with bash - though why it would have issue with bash I don't know).
The reason I need /bin/sh to point to /bin/bash is that I am running some gtkdialog-bash scripts (previously used in DebianDog and also Puppy Linux), which rely on bash for some of their functionality (they are complex so couldn't easily re-write them for ash anyway). In particular I am using weX, which is a gtkdialog-bash script to record either or all of the following streams: audio, X11 screencast video, embedded and webcam video. A bit like Simple Screen Recorder but not need qt libs. I've also made an experimental dCore sce for it as provided attached at the end of the following murga-linux forum here. It works very well on my dCore system as long as /bin/sh points to /bin/bash:
weX itself is described here: http://murga-linux.com/puppy/viewtopic.php?t=107905 (http://murga-linux.com/puppy/viewtopic.php?t=107905)
It depends on underlying ffmpeg for functionality.
It isn't enough, by the way, to start weX from an interactive bash shell (or with SHELL=/bin/bash) just like it isn't proving to be enough to start tc-wbarconf from an interactive /bb/ash shell (or with SHELL=/bb/ash tc-wbarconf). I believe that is because the gtkdialog C program system call uses the non-interactive /bin/sh no matter how you start things interactively (same with system call in tc-wbarconf).
Not knowing any special command in tinycore to make bash the default /bin/sh, I did the following:
1. Editied /etc/shells to include /bin/bash.
2. Used command: sudo chsh tc -s /bin/bash (which modifies /etc/passwd accordingly).
3. Using sudo uxterm:
mv sh shOLDAs I say, that all worked fine, except that using tc-wbarconf to say remove an icon results in a messed up /etc/sysconfig/tcedir/xwbar.lst.
ln -s /bin/bash /bin/sh
As an example, I used this simple sceboot.lst and empty xwbar.lst, with no mydata.gz persistence file as follows:
I then made my /bin/sh point to /bin/bash etc as outlined above and then started tc-wbarconf and tried removing the icon for RunProgram (or any program actually). Simply now examine the contents of xwbar.lst and you will see it is messed up (and thus wbar messed up). No such problem if /bin/sh is the default /bb/ash, but there should be a way for users to use bash as default non-interactive shell if they want to (or need, in my case).
Has anyone found a solution to this bash as system shell before? (And no, I do not want to use ash since no use as I've said for my purpose).
Hope you (or anyone) can help find a solution (or if its something simple needing changed in tc-wbarconf code).
I have updated the wbar extension with some code to help it populate better, as well as I have changed the shebang in the wbar supporting scripts to the below:
I have done this with other dCore scripts as I saw an issue without it a while back. Update the wbar prebuilt package and try again. Thanks for reporting and letting me know what was making an issue.
May not be correct method, but I did:
hoping that would update everything appropriately.
Unfortunately, the result seems to be that I have lost my wbar altogether.
When I enter wbar & in a console, I got some error message about /etc/wbar.d/wbar.cfg. Unfortunately, I forgot to note them down before erasing my mydata.tgz and on reboot with empty mydata.gz and empty xwbar.lst I now get error after entering wbar & as follows:
/cotc@box:~$ Problem load font file. /usr/share/fonts/truetype/liberation/LiberationMono-Regular/12
/usr/share/icons/nuoveXT2/128x128/devices/media-cdrom-audio.png Couldn't load icon image.
g7Pere/icons/nuoveXT2/128x128/apps/text-editor.png Couldn't load icon image.
g7cre/icons/nuoveXT2/128x128/apps/kfm.png Couldn't load icon image.
g7cre/icons/nuoveXT2/128x128/apps/terminal.png Couldn't load icon image.de
i.e. weird stuff. However, I'll now rebuild my system and report back later once I've done that.
The rebuilt went find. I haven't tried an "sce-update -nar" again because I don't want to break anything, but I'd appreciate if you could let me know if that should have worked. I will try it again later once I've backed everything up.
Also, I note that wbar now automatically finds debian-xterm and debian-uxterm. Previously, I had to copy the relevant /usr/share/pixmaps 32x32 (or 48x48) icon and rename the copy xterm-color.xpm. I take it you added the following code to wbar_update.sh? I don't remember it being there before, but it explains the new auto-detection of debian-uxterm and debian-xterm:
elif [ -f "$ICONCHECK"*32*.xpm ]; then (and similarly for *32*.png)
And I see you also added bash (and rbash) as valid login shells into /etc/shells.
I've just now also quickly tried tc-wbarconf (with bash as my non-interactive system shell) and that seems to be working fine now too, thanks.
I rebooted after an "sce-update -an" and all works as expected.
Yes, I added the icon detecting code, but I did not adjust /etc/shells. Thanks for testing and I hope all is good now.