Gnome-MPlayer Extension - Request for Advice

[gutmensch]

Try GConf.tcz GConf-dev.tcz ?

[Arslan S.]

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

[SamK]

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?

[Juanito]

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 

[SamK]

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?
 

[SamK]

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
   

[Arslan S.]

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,

[SamK]

My attempts to compile notification-daemon have stalled again.  The configure stage completes without errors but the make stage reports:

Code: [Select]

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?
   

[Juanito]

..looks like you need libstartup-notification, libxcb-util and libxcb-util-dev

[gutmensch]

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

[Arslan S.]

i have discovered two other notification daemons notify-osd and xfce4-notifyd, tested from base, both working ok

[SamK]

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

[Arslan S.]

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

[SamK]

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.
 

[tinypoodle]

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.