Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: SamK on November 16, 2010, 07:11:09 AM
-
I'm hoping that a regular TC packager might be able to provide some advice.
I have built an extension of gnome-mplayer which is working OK. When partnered with Mplayer-nodeps.tcz and edna.tcz it produces a music playing system at a very acceptable resource cost. It is very close to fulfilling what I want. Almost...
Presently, it displays an icon in the panel notification area. Hovering the cursor over this icon displays details of the currently playing track. What I would like to achieve is for the change of track event to generate an on-screen pop-up display of this information. This is the way it works in Lubuntu is it possible in TC3.1? Are there any suitable extensions in the repository?
-
I don't know how it's done there, but if you can set a trigger at the song change, flnotify can be used to show the message.
-
I don't know how it's done there, but if you can set a trigger at the song change, flnotify can be used to show the message.
Thanks for the tip. I found flnotify just before reading your post. It is not visually in keeping with my extension but will assist in testing - if I can find how to trigger it..
I have also found notification-daemon.tcz but have no idea how to use it and there are no instructions in the TC repository. The app web page is unclear to me, the app does not have a help reference or docs, and the menu executable (/usr/local/bin/notification-properties) generates a segmentation fault.
Perhaps there are other extensions that may also be used. I'm open to suggestions and also on the way in which to trigger the track change on-screen-display.
-
notification daemon is accessed with dbus signals and i don't know how to use it directly
but there is an easier alternative notify-send (libnotify.tcz)
notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia
please note that i didn't check if notify-send needs notification daemon running
-
...there is an easier alternative notify-send (libnotify.tcz)
notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia
please note that i didn't check if notify-send needs notification daemon running
I am unable to get this working.
In summary:
TC3.1 machine.
No missing dependencies.
notification-daemon.tcz is listed in OnBoot an the machine is rebooted.
How to tell if the daemon is running or failed?
dmesg | grep notification returns nothing.
ps -A does not indicate the daemon is running.
How is the daemon started?
/usr/local/bin/notification-properties returns:
Segmentation fault
dmesg | grep notification returns
notification-pr[4101]: segfault at 0 ip b6951b84 sp bfe8bd60 error 4 in libc-2.11.1.so b68df000+13d000]
ps -A contains
4105 tc dbus-launch --autolaunch 34aec1d9e8b09257197e553b00000028 --binary-syntax --close-stderr
4106 tc /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
Any of the following fail presumably as a result of the segmentation fault.
Machine rebooted
sudo notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia returns no errors
aoss gnome-mplayer returns
Failed to open connection to session message bus: Failed to connect to socket /tmp/dbus-JsJT1tCvnF: Connection refused
Machine rebooted
sudo /usr/local/bin/notification-properties returns
Segmentation fault
sudo notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia returns no error message
aoss gnome-mplayer returns
Failed to open connection to session message bus: Failed to connect to socket /tmp/dbus-FMb4DJtjl5: Connection refused
Machine rebooted
sudo /usr/local/etc/init.d/dbus start
sudo /usr/local/bin/notification-properties returns
Segmentation fault
sudo notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia returns no error message
aoss gnome-mplayer returns
Failed to open connection to session message bus: Failed to connect to socket /tmp/dbus-cFbvy8jYsE: Connection refused
Machine rebooted
aoss gnome-mplayer returns no errors, works OK and returns no error message.
-
Failed to open connection to session message bus: Failed to connect to socket /tmp/dbus-JsJT1tCvnF: Connection refused
This is perhaps a result of not having something like this that starts with the x session: $ cat ~/.X.d/dbus
dbus-launch --sh-syntax --exit-with-session
-
there is also notification-daemon-xfce you can use
download it and change dep list to
lib.y.tcz
libxfcegui4.tcz
libnotify.tcz
shared-mime-info.tcz
hicolor-icon-theme.tcz
also load gnome-icon-theme or any other icon theme
then execute (this is not really needed, just needed for some icons to be visible)
sudo gtk-update-icon-cache /usr/local/share/icons/hicolor
now it should work, tested from base, no need to start dbus daemon
notify-send "test" "abc" -i applications-multimedia
-
This is perhaps a result of not having something like this that starts with the x session:
Code:
$ cat ~/.X.d/dbus
dbus-launch --sh-syntax --exit-with-session
This does stop the error message.
ps -A contains
3927 tc dbus-launch --sh-syntax --exit-with-session
3928 tc /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address 7
notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia returns: no error message but also does not display a notification.
/usr/local/bin/notification-properties returns:
Segmentation fault
aoss gnome-mplayer returns: no error message and works OK.
there is also notification-daemon-xfce you can use
download it and change dep list to
lib.y.tcz
libxfcegui4.tcz
libnotify.tcz
shared-mime-info.tcz
hicolor-icon-theme.tcz
also load gnome-icon-theme or any other icon theme
then execute (this is not really needed, just needed for some icons to be visible)
sudo gtk-update-icon-cache /usr/local/share/icons/hicolor
now it should work, tested from base, no need to start dbus daemon
notify-send "test" "abc" -i applications-multimedia
notification-daemon-xfce added to OnBoot, dependency list changed as recommended. Reboot.
ps -A contains no reference to dbus or notification-daemon-xfce
notify-send "test" "abc" -i applications-multimedia works OK as it produces the required OSD.
ps -A contains:
4593 tc dbus-launch --autolaunch 95e5f6024d0358e401df0b7d00000029 --bina
4594 tc /usr/local/bin/dbus-daemon --fork --print-pid 5 --print-address
4596 tc /usr/local/libexec/notification-daemon-xfce
notify-send -u low "Now playing" "New Song" -t 5000 -i applications-multimedia
aoss gnome-mplayer returns no errors and works OK but does not produce an OSD notification at change of track.
My interpretation of the above is that there are two independent issues.
- Using notification-daemon. The daemon only partially loads (segmentation fault?), leading to the failure to display any OSD notifications.
- Using notification-daemon-xfce. The daemon successfully loads, the OSD notification work OK, but is not triggered by the change of track.
-
notification-daemon works ok under gnome-desktop session, or even xfce session, i have no idea about segmentation fault
if you compiled gnome-mplayer from source, make sure you have libnotify enabled
-
notification-daemon works ok under gnome-desktop session, or even xfce session, i have no idea about segmentation fault
I wonder if this is a dependency issue. In an earlier post you suggested that I download notification-daemon-xfce and amend the .dep file. This produced a working OSD. I was already loading everything mentioned in your amended .dep except libxfcegui4.tcz and its dependencies. Perhaps this indicates an expectation of file/files not presently installed by notification-daemon.tcz.
if you compiled gnome-mplayer from source, make sure you have libnotify enabled
I compile and build extensions so infrequently that I have no idea how to do this. A pointer would be appreciated. Is it simply a case of having notification-daemon loaded (providing libnotify as a dep) or does it require changes to the compile commands. My skill set here is limited to the information in the wiki.
-
usualy having libnotify loaded prior to executing configure command should be ok, but check configure messages for smth like "Checking for libnotify ... yes/no"
-
got it now, according to default application preferences notifications disabled, go to Edit-->Preferences-->Interface-->"Show notification popup" to enable notifications
-
got it now, according to default application preferences notifications disabled, go to Edit-->Preferences-->Interface-->"Show notification popup" to enable notifications
That's interesting... the option is not listed. This is version 1.0.0. On the same machine I have Lubuntu 10.10 which includes gnome-mplayer version 0.9.9.2 which does list it.
Might it omit it if libnotify was not found during the compilation? It wasn't installed until after the extension had been created.
-
you need to load libnotify.tcz and compile it again
-
you need to load libnotify.tcz and compile it again
Doing this has indeed produced the missing option: Edit-->Preferences-->Interface-->"Show notification popup"
When used in conjunction with notification-daemon-xfce.tcz and the modified .dep list the OSD notification works as expected on change of track.
Having now established a working (but unfinished) reference point I have gone on to investigate the problem with notification-daemon.tcz.
notification-daemon-xfce was replaced with notification-daemon but the amended .dep was retained and loaded. Again notification-daemon failed but with a reference to gconf-2.
At this point I decided to recompile notification-daemon. The configure stage stalls with the following error message:
checking for NOTIFICATION_DAEMON... configure: error: Package requirements (gtk+-2.0 >= 2.10.0, glib-2.0 >= 2.10.0, dbus-1 >= 0.36, dbus-glib-1 >= 0.36, lib.y >= 0.1.3, gconf-2.0, libwnck-1.0 ) were not met:
No package 'gconf-2.0' found
Which extension in the TC3 repository contains gconf-2.0? I simply cannot locate it.
-
Try GConf.tcz GConf-dev.tcz ? :)
-
if you are thinking of submitting gnome-mplayer extension i suggest not to add a certain notification daemon to its dep list, just mention it in the info file that you need a notification daemon for notifications
also even if you successfully compile gnome notification-daemon it does not mean that all the dependencies are satisfied for it to run properly, there may be run-time dependencies, pre install, post install commands or even configuration
notification-daemon-xfce is the port of gnome notification-daemon to xfce, i don't know other differences beside that
and trying to make it work from base is a pain for any gnome daemon so i recommend to go for notification-daemon-xfce but don't add it to dep list because a gnome desktop user or kde user already have native notification daemons running
-
Try GConf.tcz GConf-dev.tcz ? :)
I looked at those but could not find any reference to gconf-2.0. Do they=gconf-2.0?
-
I looked at those but could not find any reference to gconf-2.0. Do they=gconf-2.0?
Take a look at GConf.tcz.list ;)
-
if you are thinking of submitting gnome-mplayer extension i suggest not to add a certain notification daemon to its dep list...
Compiling sources and building extensions is not one of my mainstream activities. I do it so infrequently that I do not possess the correct skill set to maintain a publicly available package.
It occurred to me that in the future, others reading this thread might find the knowledge gained here helpful. In my view, it is not an intuitive choice to use notification-daemon-xfce in other than an XFCE environment (at least it was not obvious to me until you suggested it). It was for this reason I was exploring the use of notification-daemon.
...just mention it in the info file that you need a notification daemon for notifications
My concern is that this leaves users having to make a fairly extensive download, manually modify the .dep file and then manually delete the unneeded dependencies. While this is certainly a workable approach to take, I wonder if there is a more elegant way.
...don't add it to dep list because a gnome desktop user or kde user already have native notification daemons running
I can see the reasoning here. Due largely to your contributions, the users of Gnome, KDE and XFCE are well catered for. As notification-daemon currently is not a suitable choice for users of other environments, might it be possible to simplify the matter for them?
Would you consider offering a further package as a modification of the currently working notification-daemon-xfce? This might be named notification-daemon-xfce-MOD or notification-daemon-MOD or whatever is deemed a appropriate. The download can consist of only notification-daemon-xfce, plus the reduced set of dependencies. Its purpose and use can be clearly identified in the .info file. It would reduce the download, the amount of user work, and seems more user friendly. Overall, it will leave the Gnome, KDE and XFCE users unaffected but will offer a benefit to others.
From the perspective of a non-package maintainer it seems that a working answer is available, the files already exist and most of the work is done. A change of name in the .desktop file may be needed though. Do you think the suggestion is worthwhile?
-
I looked at those but could not find any reference to gconf-2.0. Do they=gconf-2.0?
Take a look at GConf.tcz.list ;)
OK I see it now.
Thanks Juanito, thanks gutmensch
-
no need to another version of notification-daemon-xfce, just gutmensch (current maintainer of notification-daemon-xfce) can change the dep list removing Xfce4 and replacing real dependencies as i suggested in this thread. notification-daemon-xfce is the only notification daemon i can get to work from tc base that's why i recommend it, others who run xfce gnome or kde already have native notification daemons,
-
My attempts to compile notification-daemon have stalled again. The configure stage completes without errors but the make stage reports:
gcc: /usr/local/lib/libstartup-notification-1.so: No such file or directory
gcc: /usr/local/lib/libxcb-aux.so: No such file or directory
gcc: /usr/local/lib/libxcb-event.so: No such file or directory
gcc: /usr/local/lib/libxcb-atom.so: No such file or directory
This is despite both libstartup-notification-dev and libxcb-dev being installed. I think I have reached my limit on this an will now just park it.
@gutmensch
Do you consider the analysis and general idea expressed in my post (reply #19) allied to the post by Arslan S. (reply #21) are worthwhile?
-
..looks like you need libstartup-notification, libxcb-util and libxcb-util-dev
-
@SamK: Feel free to submit an updated version of notification-daemon-xfce. The one in the repo is back from tc 2.x, I never updated it because I didn't need it anymore and there was no request for an update either. If it works without Xfce I would agree with Arslan that there's no need for it as a dep, just libnotify, xcb and the other stuff...
-
i have discovered two other notification daemons notify-osd and xfce4-notifyd, tested from base, both working ok
-
..looks like you need libstartup-notification, libxcb-util and libxcb-util-dev
I eventually got it to compile with no errors and produced an extension. It turned out to be a fruitless exercise as it failed in exactly the same manner as notificaton-daemon in the TC3 repository. This line of inquiry for me is now closed.
@SamK: Feel free to submit an updated version of notification-daemon-xfce. The one in the repo is back from tc 2.x, I never updated it because I didn't need it anymore and there was no request for an update either. If it works without Xfce I would agree with Arslan that there's no need for it as a dep, just libnotify, xcb and the other stuff...
I briefly investigated removing XFCE but could not get it to work. It seems it requires some element(s) provided by libxfcegui4.tcz. It is beyond my reach to pursue this any further and is now, for me, closed down as a line of inquiry.
Using this daemon as outlined in reply #6 works reliably and well at a reasonable resource cost. It is just a little clumsy to implement and choosing it for use in non XFCE systems is not obvious due to the name, notification-daemon-xfce. It seems to have the potential to be offered as an additional extension in the form of a non-desktop-specific OSD notification. Renaming and retitling the .desktop would be good also.
i have discovered two other notification daemons notify-osd and xfce4-notifyd, tested from base, both working ok
This is encouraging news. Do you intend to submit them to the repository? Checking Lubuntu 10.10 reveals that notify-osd is installed as the default. I for one would welcome an opportunity to use it in TC.
Correction: Lubuntu 10.10 still uses libnotify. Gnome Ubuntu 10.04 uses notify-osd.
-
i have discovered two other notification daemons notify-osd and xfce4-notifyd, tested from base, both working ok
This is encouraging news. Do you intend to submit them to the repository? Checking Lubuntu 10.10 reveals that notify-osd is installed as the default. I for one would welcome an opportunity to use it in TC.
yes i will submit them soon
-
When gnome-icon-theme.tcz is not used, two buttons are displayed without icons when version 1.0.0 gnome-mplayer is running. They are stock_repeat.png and stock_shuffle.png, from .../gnome/HxW/status/.
It seems wasteful to load gnome-icon-theme.tcz (5500+ files, 25+MB) to obtain the icons. Is there a more effective way to do this?
I have extracted the icons and tried:
- adding them to the icon section of the source before the configure stage
- adding them to the icons section of the compiled app before squashfs
neither display the missing icons.
-
For the sake of accuracy the size of gnome-icon-theme.tcz in repo is stated as 7.63 MB.
However, of course this is still more than enough to bother.
What I would try in such a case is making a customized "fat-free" extension which contains only the files really required.
I have successfully done so with extensions containing a collection of modules, e.g. keeping only the wireless and file system modules which are really useful to me.
-
For the sake of accuracy the size of gnome-icon-theme.tcz in repo is stated as 7.63 MB.
However, of course this is still more than enough to bother.
25.2MB is the size reported by emelFM2 once decompressed.
What I would try in such a case is making a customized "fat-free" extension which contains only the files really required.
My understanding is that this is synonymous with the action of my second bullet point.
-
For the sake of accuracy the size of gnome-icon-theme.tcz in repo is stated as 7.63 MB.
However, of course this is still more than enough to bother.
25.2MB is the size reported by emelFM2 once decompressed.
Makes sense...
What I would try in such a case is making a customized "fat-free" extension which contains only the files really required.
My understanding is that this is synonymous with the action of my second bullet point.
Ok, seems I hadn't exactly understood then.
The more conservative and safe approach would be to remove everything redundant from a package.
What I would try in specific case would be to copy all the files not ending in .png plus the required icons, all with their full path.
I could imagine proper use of gtk-update-icon-cache might also be indicated, after installing the icons.
-
i have discovered two other notification daemons notify-osd and xfce4-notifyd, tested from base, both working ok
This is encouraging news. Do you intend to submit them to the repository? Checking Lubuntu 10.10 reveals that notify-osd is installed as the default. I for one would welcome an opportunity to use it in TC.
yes i will submit them soon
@ Arslan S.
Just wanted to express my thanks for submitting both new extensions so quickly.
While looking into notify-osd I came across this site, https://launchpad.net/notifyconf
This application can customize the colours, fonts, and size of various elements of the Ubuntu's notification bubbles. The time they stay can also be adjusted.
It seems that this will provide the same type of configuration as is available with xfce4-notifyd. Were you aware of this one?
-
no i didn't know notifyconf but after a bit investigation i can say :
it has no stable release,
it looks to be in very early stage, latest trunk revision is 7,
and it is not available in repositories of ubuntu, debian