Tiny Core Linux
Off-Topic => Archive / Obsolete => SCM EXtensions => Topic started by: SamK on March 12, 2012, 07:13:19 AM
-
Download
When downloading links2 an error is reported in the wget windowline 41: can't open /etc/sysconfig/icons: no such file
Starting
An entry is not added to the JWM menu.
which links
/apps/bin/linksUpon issuing the command links in a terminal, no error message is obtained but links does not start
Uninstal
When unistalling via Scm or ScmBrowser no error is reported.
ls /mnt/sdb1/tce/optional/links*
/mnt/sdb1/tce/optional/links2.scm
/mnt/sdb1/tce/optional/links2.scm.md5.txt
Does uninstal=complete deletion from the system?
If not, is there an automated way to purge all scm elements including any configuration it creates in the user home directory?
-
I will look into these when I get home tonight.
But basically to uninstall/unmount means to unmount the extension in /apps/extensionname, and remove their freedesktop entries in /usr/local/share/{pixmaps,applications} as well as their linked binaries in /apps/bin. Uninstalling/unmounting does not delete the extension itself, as the concept is to mount when needed and unmount when desired.
As for files that apps create in the /home directory, that is of course not removed when an extension is unmounted. If it is desired to find out what files are created by an app that you later want to delete, a command like below would basically tell you.
touch /tmp/file
- now launch app, and configure and save the config -
find /home/tc -newer /tmp/file
-
As for files that apps create in the /home directory, that is of course not removed when an extension is unmounted.
OK, understood and accepted. The idea of removing the configuration files was slightly tongue-in-cheek and hugely optimistic.
Uninstalling/unmounting does not delete the extension itself, as the concept is to mount when needed and unmount when desired.
It is usual that a GUI OS includes a GUI means of removing an application. TC would benefit from such a feature for scms. Indeed TC currently offers a means of preventing loading/mounting tczs at the next boot (removal from OnBoot) and also removal from the system via AppsAudit.
Perhaps it could considered together with other potential developments at some future stage.
Edit add omitted tczs
-
Opening a terminal and typing links does start links, it just shows a black window that you either have to use the mouse with or enter key combinations. And of course, links -g opens the graphical browser.
It had no menu or icon before, but I added one in now, so all should be well.
-
And of course, links -g opens the graphical browser.
It had no menu or icon before, but I added one in now, so all should be well.
I have been launching Links from a JWM menu entry since TC3.3 but had forgotten that I had created the .desktop file to do so. Consequently, the -g switch was overlooked when testing the scm.
The addition of the menu entry to the scm is welcome and working OK.
Since TC3.3 I have been using Links together with gnome-mplayer and now have the equivalent scm version running OK. There is one minor difference between them.
In the tcz version
Links and gnome-mplayer are listed in tcz OnBoot
Links-->Setup-->Associations-->Program-->gnome-mplayer %
i.e. there is no need to specify the full path to the app
In the scm version
Links and gnome-mplayer are listed in scm OnBoot
Links-->Setup-->Associations-->Program-->/apps/gnome-mplayer/bin/gnome-mplayer %
i.e. the full path to the app is needed
Is it likely to be a general case that when an scm refers to a further scm that the full path will be needed?
-
When used with JWM, links2 does not create an icon in the panel, as shown in the attached screenshot.
-
Since I and perhaps others making for the tcz repo were not aware of JWM's need for the same binary name as icon name, I am sure there are a lot of cases like this where JWM is not showing an icon.
I will fix the scm's as I see a few that display this behavior.
-
Using ScmBrowser:
* Successfully updated app
* Verified md5
* Installed app
* App fails to load
Starting in a terminal:
links
/apps/links2/localbin/links-bin: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory
Seems to be missing xz.tcz
-
Looks like a dependency crept in, I will fix it.
-
@jwm icon
That is a fallback path for when the app doesn't specify an icon itself. For example run the latest Opera from its tarball dir, without any opera installed - it has the correct icon, since it specifies it in the app code.
When tested like that there is no opera icon under any pixmaps dir known to jwm.
-
Following a check for pending updates:
Using ScmBrowser:
* Successfully updated app
* Verified md5
* Installed app
* App fails to load
Starting in a terminal:
/apps/links2/localbin/links-bin: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory
-
I will check into it tonight.
-
I will check into it tonight.
Following a successful update the app now loads as expected.
Back on the track of the missing icon...
* The icon remains absent from the JWM panel
* The .desktop file executes links but points to links2.png
The three apps tested and reported with missing JWM icons (flburn, links, xmms) have a common pattern. In each case the .desktop entry points to a script which ultimately starts the app. The apps which correctly display the JWM icon point directly at the executable. Perhaps this is contributing to the problem.
-
Most scm's need wrapper scripts for their binaries, and that does not affect the icon thing.
But I did rename in various ways the links2 extension and it's files, to no avail.
So some apps which don't use the standard internal icon code can easily be adjusted to allow JWM to fall back to a /usr/local/share/pixmaps icon, and I have no issue accommodating that. Others not so easy, or not at all. And for those, we will just have to live with the fallback X icon. Which I remember seeing that icon in KDE a lot in Suse a while back for many apps, and they are a polished commercial distro.
-
The matter is not only seen in JWM but IceWM also.
Motivated by curiosity, JWM was replaced with IceWM-Full. The icon symptoms are the same for both of them. Throughout the thread, it has been referred to as occuring in JWM. For the benefit of future readers I thought it might be helpful to note that it is also seen in IceWM and possibly other untested WMs.
-
AFAIK you can't rely on JWM's fallback being there for other WMs such as IceWM. The only standard really is when the app itself specifies an icon.
-
Here is what I found comparing jwm, icewm, LXDE2, and fluxbox.
Icewm, fluxbox, and LXDE2 all recognize and use the app's internal icon spec for the titlebar icon. None of them fall back to a /usr/local/share/pixmaps icon, but LXDE2 does use the Icon= field in the .desktop files to make a menu icon. So in LXDE2 a menu icon is there as long as Icon= is specified and valid in the .desktop file. So you can have a generic title bar icon but a specified menu icon in LXDE2.
Jwm does not use the app's internal icon spec, and instead relies totally on a /usr/local/share/pixmaps icon that is of the same name as the executable. And it does not appear to do that reliably, since links2.scm and frozen-bubble.scm do not show a title bar icon at all no matter how the files are named, though both of those apps by default show a title bar icon in the other WM's and DE. CORRECTION: Jwm does seem to obey the icon spec in some apps when there is no pixmaps icon, but there is still some hit or miss.
So my conclusion is that the effort is not worth the result to further pursue renaming and restructuring extensions to only benefit jwm. It would be different if it was also fixing a same problem in all the freedesktop DE's. But they don't have that problem, they obey the app's standard icon spec. Also, it is not just our build as I tested Debian's jwm and saw the exact same behavior.
-
So my conclusion is...
Just trying to clarify my understanding here...
In cases where the generic "X" icon is obtained, which is the preferred route?
- No report is required. No fix will be attempted. In all cases the "X" icon is acceptable
or - Report mismatches in executable and icon names. A fix will be attempted. If I understand correctly, this might work in some cases
Edited to ask the question more clearly
-
#1
The bug is in how jwm deals or not deals with icons, so it would be much better if jwm was fixed rather than to have to adjust every app to attempt to make an icon show for jwm. And since it is not specific to our build of jwm, the jwm project would be the place to file a bug.
But I did notice that a menu icon can be shown if the lines in /usr/local/tce.jwm went from:
<Program label="links">exec /usr/local/bin/links -g</Program>
to this:
<Program icon="links.png" label="links">exec /usr/local/bin/links -g</Program>
If the icon is specified but no icon is there, it works but simply does not display an icon. I am not big on icons, so I am good with the current jwm menu setup. But we just have to live with the title bar having or not having an icon, it is not worth the investment in time nor the imposing of rules in extension naming to try to accommodate jwm's behavior in the title bar icon handling.
-
One last thought, for the apps that do not display a title bar icon in the other window managers or desktop environments, then that should be reported to the upstream authors of the app itself. That is, after their mailing list history has been searched to make sure that having no icon was not a conscious decision on the part of the project, especially the smaller apps that may rather not have the extra code and size.
Sam, I appreciate the time you are spending in testing the scm apps, and I hope it continues, though I feel this particular title bar icon issue is out of our hands.