Two additional desklets for gDesklets which both have some quirks: -- desklet-extra-slideshow -- desklet-extra-sidecandyprintqueue
Created attachment 160446 [details] Ebuild for SlideShow-0.9
Created attachment 160448 [details] Long description of the package
Created attachment 160452 [details] ChangeLog for desklet-extra-slideshow-0.9.ebuild The installation process needs to pay attention to the quirk herein.
Created attachment 160456 [details] Ebuild for SideCandyPrintQueue-0.9
Created attachment 160457 [details] ChangeLog for desklet-extra-sidecandyprintqueue-0.9.ebuild This one also needs some intervention; see the log.
In future: One package, one bug. And don't attach ChangeLog or metadata.xml, please. Not of relevance and won't be imported anyways. - $S isn't always quoted - mv $( ) implies opening a subshell - this is damn ugly and completely unneeded - remove DOCS="LICENSE" - license is referenced via $LICENSE - DEPEND="${RDEPEND}" w/o RDEPEND defined is- um - remove it, please. - pkg_postinst() looks suspecious to me. You're aware Portage doesn't track anything you do there and on uninstall cruft remains on the system!?
(In reply to comment #6) Thanks for your informative review. Here's my answer in detail: > In future: One package, one bug. My fault. Maybe there should be dedicated repositories for ebuilds of additional plugins to packages like gimp, firefox, or gdesklets ;) > And don't attach ChangeLog or metadata.xml, > please. Not of relevance and won't be imported anyways. Clutter the ebuilds with those comments and the long description? Take them just as an indication that they're important enough to be mentioned. > - $S isn't always quoted I don't see the point? Removed anyway. > - mv $( ) implies opening a subshell - this is damn ugly and completely > unneeded Don't be that picky. It looked nice with the syntax highlighting of my vim :) > - remove DOCS="LICENSE" - license is referenced via $LICENSE Done. > - DEPEND="${RDEPEND}" w/o RDEPEND defined is- um - remove it, please. Take a look at gdesklets.eclass. > - pkg_postinst() looks suspecious to me. You're aware Portage doesn't track > anything you do there and on uninstall cruft remains on the system!? No, I wasn't. Unfortunately the ebuild(5) man page isn't concise about that point (I think a warning would be helpful): pkg_preinst pkg_postinst All modifications required on the live-filesystem before and after the package is merged should be placed here. Also commentary for the user should be listed here as it will be displayed last. Anyway, I've switched to pkg_preinst by making it work on the temporary install directory. The only issue could be that Portage checks for collisions BEFORE pkg_preinst.
Created attachment 160585 [details] Modified ebuild for SlideShow-0.9 pkg_postinst changed to pkg_postinst
Created attachment 160586 [details] Modified ebuild for SideCandyPrintQueue-0.9 pkg_postinst changed to pkg_postinst
(In reply to comment #8) (In reply to comment #9) > > pkg_postinst changed to pkg_postinst > This reads "pkg_postinst changed to pkg_preinst", of course.
Old and no homepage, so closing. Also, SideCandy is being re-worked.
(In reply to comment #11) Sad enough. SlideShow is still available on www.gdesklets.de, isn't it? It is the last and only reminiscence of Vista's sidebar that I'm missing. Knowing of many people who like it on Windows, this kind of functionality could only add to the sex appeal of any Linux distro. Anyway, it is the only one I've found to work satisfactorily.
(In reply to comment #12) > (In reply to comment #11) > > Sad enough. SlideShow is still available on www.gdesklets.de, isn't it? It is > the last and only reminiscence of Vista's sidebar that I'm missing. > > Knowing of many people who like it on Windows, this kind of functionality could > only add to the sex appeal of any Linux distro. Anyway, it is the only one I've > found to work satisfactorily. > You've made me reconsider. I'll try this out today and see if it works.
In portage as x11-plugins/desklet-SlideShow. I think for the future it's better practice to split out Controls to their own desklet like I've done with this one. Please re-emerge and let me know if there are any issues. Thanks!
Created attachment 190157 [details, diff] Patch for desklet-ImageSlideShow-0.8.ebuild (In reply to comment #14) > It's a good idea to split up the desklet's ebuild into one for the display and another for its control. Unfortunately, the latter did not work for me. These are the changes I had to make: -- DOCS: The double quotes after the dodoc command on line 198 in gdesklets.eclass are superfluous, thus that command fails to find any DOCS with more than one argument. The ebuild caused a QA warning, although it's rather a problem within the eclass; -- unpack: ImageSlideShow doesn't seem to be packaged the standard way; without the Controls subdirectory, nothing will be installed by the gdesklets eclass; -- pkg_preinst: Makes the control conform with the naming scheme in /usr/lib/gdesklets/Controls/.
Created attachment 190159 [details, diff] Patch for desklet-SlideShow-0.9.ebuild (In reply to comment #14) > As I was testing the ebuilds under a new user name, I ran into another minor annoyance: SlideShow uses a single temporary directory belonging to the first user calling it, i.e. with no rights for others to write into it. As long as there is no patch for it, the ebuild should issue some warning like this before the user gets confused.
Reopened because of desklet-ImageSlideShow-0.8.
(In reply to comment #15) > -- DOCS: The double quotes after the dodoc command on line 198 in > gdesklets.eclass are superfluous, thus that command fails to find any DOCS with > more than one argument. The ebuild caused a QA warning, although it's rather a > problem within the eclass; > Yeah, I noticed. I've fixed that in the eclass before I committed. > -- unpack: ImageSlideShow doesn't seem to be packaged the standard way; without > the Controls subdirectory, nothing will be installed by the gdesklets eclass; > > -- pkg_preinst: Makes the control conform with the naming scheme in > /usr/lib/gdesklets/Controls/. > Right, I think I saw these too and got them in the eclass. Can you try out the ebuilds in the tree? desklet-SlideShow should be all you need to emerge.
(In reply to comment #16) > Created an attachment (id=190159) [edit] > Patch for desklet-SlideShow-0.9.ebuild > > (In reply to comment #14) > > > As I was testing the ebuilds under a new user name, I ran into another minor > annoyance: SlideShow uses a single temporary directory belonging to the first > user calling it, i.e. with no rights for others to write into it. > > As long as there is no patch for it, the ebuild should issue some warning like > this before the user gets confused. > Good catch, thanks. If you would like to give a shot at a patch, I'd be open to it :) Additionally, it would be good if someone notified the upstream developer...
(In reply to comment #18) > Sorry, I didn't sync before I tried them. Now, desklet-ImageSlideShow emerges and works flawlessly with the new eclass (although I still don't like that salted name, for it isn't really needed :( ).
Created attachment 190851 [details, diff] Multi-user patch for desklet-ImageSlideShow (In reply to comment #19) > Good catch, thanks. If you would like to give a shot at a patch, I'd be open > to it :) Additionally, it would be good if someone notified the upstream > developer... > Here you go: with a local thumbnail cache, there are no such problems. I've submitted this patch to upstream too.
(In reply to comment #21) > Closing this bug while cloning it in order to single out a better patch in <URL:http://bugs.gentoo.org/show_bug.cgi?id=271777>
