smooth is a new theme engine for gtk, you can find few really nice themes based on it on art.gnome.org. i'm attaching 0.5-r1 and 0.5-r2 ebuilds for both gtk 1.2 and gtk 2+, also modified gtk-engines.eclass and latest gtk-engines-cleanice-1.2.5.ebuild. have fun, artb.
Created attachment 10949 [details] gtk-engines.eclass
Created attachment 10950 [details] gtk-engines-smooth/gtk-engines-smooth-0.5-r1.ebuild (gtk 1.2)
Created attachment 10951 [details] gtk-engines-smooth/gtk-engines-smooth-0.5-r2.ebuild (gtk 2+)
Created attachment 10952 [details] gtk-engines-cleanice/gtk-engines-cleanice-1.2.5.ebuild
*** Bug 19623 has been marked as a duplicate of this bug. ***
If I may make a suggestion about the package of Smooth, the newest engine releases will be coming out of Smooth's SourceForge.net page (http://www.sourceforge.net/projects/smooth-engine). The Smooth tarball on art.gnome.org is not really a real release location. Its a tarball of the 0.5.0 release, and Smooth's been updated since then. There are really two packages that make up Smooth. There's the engine tarball itself (which contains engine code only) and there's a smooth-themes tarball, which contains all the themes. I've written up some ebuilds that behaved that way, and I think in the long run it might be easier to maintain newer Smooth releases that way. The tarballs on sf.net are designed to build in such a way that gtk and gtk2 can be build simultaneously. The ebuilds I've written up use the gtk and gtk2 USE flags, and I feel that's a more effective method of building Smooth. Its more true to the tarball distribution method too. That additional bug is the ebuilds I've submitted. I'm willing to help merge Smooth into the gtk-engines.eclass if you decide to use any of my suggestions.
we want it to use the eclass altough i think the eclass needs a good smoothing itsself, but for now we shouldn't try to go around it. consistency is important. So please add your work for review.
Okay, I don't have a working Gentoo installation to test (I will in a couple days) this on unfortunately, but I've attached the diff to the above attached gtk-engines.eclass. I change the package name and download location. And I added --enable-gtk-2=no to the SLOT=1 case, so that SLOT 1 does build only the gtk1 version. You'll need the smooth-themes ebuild in order to get some themes, unless you want to somehow work that into the gtk-engines-smooth ebuild. That seems kind of strange, but that's how Andrew does the release tarballs. Is there any reason for using SLOTS? In the diff, I've preserved the existing SLOT technique, but it seems more logical to me to look at $USE, and see if it contains gtk and/or gtk2.
Created attachment 11547 [details] gtk-engines.eclass.diff
we need SLOTS inside ebuilds anyway, so portage wouldn't unmerge 'earlier' version of the package (f.e. -r1) after installing 'newer' one. so i think it's good to leave them inside eclass. i'll try to hack on this in the evening a little, build the latest release and send here the changes (if any). foser, should we use one ebuild for the engine _and_ themes?
i think that's the best thing to do, the themes come with the engine makes sense. Otherwise we should add another package 'smooth-themes' or something. Depends a bit on how tied themes vs. the engines are, if the themes update much faster than the engine it might become a little troublesome.
The themes tarball is typically released with the engine tarball. They're versioned the same, and I've yet to see them out of sync (the themes were just recently split off into a seperate package). Combining them into one ebuld probably wouldn't be too frustrating.
that would be best then engine and themes combined.
ok, here it goes, the really-crappy-hacked gtk-engines.eclass. i know it's dirty, but i was tired ;) anyway, i've checked it and it works, though has two issues: 1. smooth-engine tarball unpacks to ${WORKDIR}/gtk-smooth-engine-0.5.2, which is quite ok, but smooth-themes tarball unpacks to ${WORKDIR}/${PN}, where PN="gtk-engines-smooth". this isn't right, since we need to make sure, that those two won't unpack to one directory some day. I don't really know portage does this and how to make smooth-themes unpack to smooth-themes dir. 2. second thing is that smooth-themes configure has no --enable-gtk[1,2] option, recognizing gtk2 is hardcoded and it always installs gtk2 themes (even if no engine is present). so we need a patch for Makefile, or temporarily we could just delete gtkrc's for gtk2 when SLOT==1. best regards, artb.
Created attachment 11609 [details] dirty gtk-engines.eclass that takes care of installing smooth-themes
Okay guys, I've got a few notes from Andrew here that he would like to be taken into consideration when packaging. Smooth is not a theme, and it never will be. Its a library that facilitates good theme design, and should be treated as such. That's why there's no gtkrc file distributed with gtk-smooth-engine. The smooth-themes package is a collection of themes that have been written both by Andrew and others, that he considers good examples of how themes can be designed using the Smooth engine. Because of this, he feels that smooth-themes shouldn't be merged into the "gtk-engines-smooth" package. Engines and themes are too often confused, and Andrew makes a big distinction between the two by packaging the engine code and the themes seperately. The smooth-themes ebuild could use the presence of gtk/gtk2 in the USE variable to install the proper gtk/gtk2 themes. This has gotten my mind thinking about possible alternate implementations for gtk-engines.eclass (it doesn't seem very abstract as far as gtk-engine building, but that's primarily due to the different build methods for engines). This is rather off the topic of this bug I think, but a re-write of gtk-engine.eclass might be a good thing. With a little more information about engines stored in the engine's ebuild itself.
i do too, but currently it is just that we do not package any theme really alone and probably never will (it's imho too much work to keep up with). To have a few standard or example themes go with an engine is a good idea to give the users at least something to start with. We basicly try to only provide the engines at the moment, not themes (yes we do have a few basic theme packs, but thats it). as far as the eclass goes, yes it probably needs a rewrite. But it isn't so easy with useflags and all, if you really want to burn your hands on rewriting it you should contact me on IRC and talk it over a bit before you plunge in. Artur : could you provide a diff for the eclass ? thats easier to spot changes
Okay guys, its been a while, but I've got a re-write of the gtk-engines.eclass. I've got some comments within the file itself. But I will mention them here to. I don't believe the eclass is neccessary at all. After removing all the engine specific code from the current eclass we're basically left with my eclass code. Which is basically the default process defined within ebuild.sh. Why then, do we need an eclass? Each engine is buildable on its own anyway. The shared code is shared by nearly every application too (./configure && make && make install). I've also attached an ebuild for gtk-engines-cleanice which uses the newer eclass (and I'm using the theme right now. One thing I can definitely see changing is maybe including some more defaults in the eclass (like default HOMEPAGE, etc). And moving the dependencies RDEPENDS and DEPENDS into the eclass. About the GTK+ 1.2.x vs. GTK+ 2.x issue: every engine except Wonderland and Smooth have different version numbers for their GTK+ 1.2.x and their GTK+ 2.x versions. I believe that using SLOTs for these is the proper way to do it. Just like any other application that can have concurrent versions installed (GIMP and Evolution come to mind), the GTK+ engines have different versions that can be concurrently installed, and the individual ebuilds should reflect this in their SLOT and RDEPENDS variables. Combining the building of GTK+ 1.2.x versions in with the GTK+ 2.x versions doesn't properly package the engines, in my opinion. They are different versions, and should be treated as such. I'm not sure what's up with the whole grabbing packages off Debian servers either. I don't think I've overlooked anything, and I feel like this is a very valid method of maintained engines.
Created attachment 12353 [details] New eclass/gtk-engines.eclass
Created attachment 12354 [details] x11-themes/gtk-engines-cleanice-1.2.5.ebuild Uses the new eclass
Link, Exactly what I had in mind. I actually have something very similar sitting in my local portage that I'm testing. The thing is we have to go through all the current installed engines and port them over to this new format. I've been sidetracked into do some other things so i don't think i'll get a chance until next week to look at this further. When I do, I'll look into incorporating some additions to your eclass. I definately agree with you view on debian sources. I think we could do better than fetching from debian :) I think the eclass is not particular necessary too. The current implementation is just a mess and totally not in the spirit of OO programming! I was also thinking of using USE flags rather than SLOTs for gtk-engines. I have an extreme dislike of the way that we have to use -r1 -r2 for engines with both gtk+1 and gtk+2.
I was talking with foser on IRC and he mentioned how using USE flags is not such a great idea. The way the gtk2 flag works is that it overrides the gtk flag. So if a program such as say gFTP (which has both gtk1 and gtk2 interfaces) gets called for an emerge, if USE contains gtk2, it builds the gtk2 version, otherwise it builds gtk. This allows for the possibility of a user having both 'gtk' and 'gtk2' in their USE variable, but not actually having the gtk 1.2.x libraries built. A very rare possibility in reality, but a situation that must be considered nonetheless. I still think SLOTs are the right way to handled different versioned engines though. They are different versions, and different codebases, so they should be treated individually. Smooth, Galaxy and Wonderland(Bluecurve) are the 3 exceptions, and they could be handled as such. I have no problem porting over the existing ebuilds. I can make the time for this. ;) One thing I'd like to get finalized though is the eclass. Whether we use it or not. And in what capacity. I suppose it does serve some usefullness, but most engines need some sort of custom building/downloading.
after much discussion and back and forth, i've committed gtk-engines2.eclass as a replacement. all the engines have been ported. those that haven't are going under the axe when testing is complete. there's further explaination in the eclass itself. but we've elected not to use SLOTs and just make one particular theme install both the GTK1 and GTK2 version, depending on whether GTK1 and/or GTK2 is installed. gtk-engines-smooth also has been added in the overhaul.
