Links2 scm Bugs Feedback

[SamK]

Download
When downloading links2 an error is reported in the wget window

Code: [Select]

line 41: can't open /etc/sysconfig/icons: no such file

Starting
An entry is not added to the JWM menu.

Code: [Select]

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.

Code: [Select]

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?
   

[Jason W]

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

[SamK]

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

[Jason W]

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.

[SamK]

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?
   

[SamK]

When used with JWM, links2 does not create an icon in the panel, as shown in the attached screenshot.

[Jason W]

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.

[SamK]

Using ScmBrowser:
* Successfully updated app
* Verified md5
* Installed app
* App fails to load

Starting in a terminal:

Code: [Select]

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

[Jason W]

Looks like a dependency crept in, I will fix it.

[curaga]

@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.

[SamK]

Following a check for pending updates:

Using ScmBrowser:
* Successfully updated app
* Verified md5
* Installed app
* App fails to load

Starting in a terminal:

Code: [Select]

/apps/links2/localbin/links-bin: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory   

[Jason W]

I will check into it tonight.

[SamK]

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.

[Jason W]

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.

[SamK]

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.