I started out today to take a look at the Fusion theme and noticed references to the skinr module. After looking at the skinr module section and the reference to Skinr2 dev version I downloaded it and had some fun making a few skins. Quickly I realized there were some things that were part of Fusion theme which were quite cool and would be useful if they were part of Skinr and if they worked better. So I both fixed the issues and bolted them into my copy of Skinr2. From doing some quick reading it appeared to me that the rollover preview code in Fusion was written before the jquery pop-up dialog was added to Skinr when it became Skinr2 and so those previews were being obstructed by the dialog box. Once I got that working properly I decided to port the updated version directly into my copy of Skinr2. The next thing I noticed was stability issues with paths to images and css files. After running stability tests I found where the most stable location would be and then created the appropriate resource folder for my preview images and css stylesheets. Despite the claims of making references to files from the .info file in its named skin folder in the skins folder I used my tested location on a quick scratch theme I cobbled together which worked properly every time. I then added the necessary code so I would be able to include a more robust control group to the appropriately tagged Skinr icons and menu which gives more choices to the user than just one "Edit skin" menu choice. I also changed their locations to work better with the skinr menu. I then tested everything on a copy of Garland to make sure it all worked properly. Anyway it was a most interesting day which orginally began as a quick peek at the Fusion theme and branched into some fun discoveries with the Skinr module and finally making a revised Skinr environment for myself. Skinr looks like its got a lot of promise and when I get a chance there are a number of other things I will see about incorporating into my test copy.
Comments
Patches
Skinr can always use some patches, if you're willing to help out.
Also have a look at Skinr for D7, which is largely rewritten.
Also, I don't believe that we
Also, I don't believe that we plan to have skins included or shipping directly with the Skinr module. This is planned to be done as additional modules that provide skins. As moonray mentions, I would recommend looking at the D7 version of Skinr and creating a separate module for those skins.
--
Gravitek Labs
Skin2 dev on D6 vs. D7
Well I had some time this morning to download the D7 version of Skinr to take a look at its implementation and compare it to the D6 V2 dev version. I figured I'd start out by making a module for a skin and see how it compared with one of the skin modules I made in D6. So I went to the advanced help section to reference information for making a D7 module based skin. I was surprised to see someone had just pasted in the D6 information verbatim. Knowing a teeny bit about D7 that didn't seem valid and I confirmed this when taking a D6 skin built as a module and installing it for D7 which as I speculated didn't register the skin. So I decided to compare the API documentation. I ran both API docs through doxygen to create both html references and latex versions which I immediately compiled directly into PDFs. Sure enough, the api call was just different enough to make using the old D6 information in advanced help for defining a skin as a module, incompatible.
Its a fairly minor thing as I was planning on doing an under the hood peek at things anyway. The one thing I was already thinking about myself and nice to see implemented in the D7 version was use of contextual links. I had already played a bit with the concept on my poke into the D6 version but had only roughed a specific example around block references and added a couple of conditionals into the jquery with a few modified class references so the trigger wouldn't reference the dialog when link paths did a block configuration or menu edit call but would still behave normally and open the dialog Edit modal window when Edit skin was chosen. Taking advantage of the built in architecture for contextual links in D7 was nice to see. While there are a number things available "out of the box" from D7 there isn't really much in the way of information about what the overall architectural plans surrounding the project are and it seems like the D6 version is kind of hanging in the wind.
I instanced two netbeans projects for both D6 and D7 versions so I can run them in parallel while making process flow notes about each. Since my initial interest from earlier in the week, I've taken a large step back and examined a number of issues surrounding CSS engineering which others have naturally recognized from their own daily perspectives and germinated implementations like skinr. Anyway, my coffee is getting low and I think I'll take a break now for lunch...
Take a look at http://skinr.org
Take a look at http://skinr.org (the whole site is a work in progress).
The API is documented there and examples are provided for upgrading from 6.x to 7.x, which might be useful to you. If you would like to help us with the documentation, please create an account on skinr.org and open an issue in the Skinr issue queue and we'll get you access.
While we welcome testing, we do not by any means recommending 7.x for any live site right now. The API changes are rather stable but there is still a lot to be done with the module. We need help to get there, with code, patch reviews, patch testing and documentation, so anyone that wants to see the Drupal 7 version released should help if possible.
Took a Look...
... at the skinr.org site. The information pretty much parallels what I extracted more formally from the two API documents. Thanks Jacine for the pointer! I don't get much spare time, thus the days between postings.
The first thing that happened when I opened the D7 Skinr module in Netbeans was I got a sea of Warnings. Nothing of any consequence, but the IDE was flagging all of the assignments taking place inside of conditionals. A lot of IDE's generally will throw up if they detect someone doing this and its not a great idea to have to be sorting between whats just bad coding style from actual issues. The Obfuscated C contest was an example of having fun by taking poor coding style to ultimate extremes as an exercise in illustrating a point.
At the moment both the D6 and D7 versions of Skinr are NRPT, plus I have a raft of ideas I wish to evaluate. Also I didn't come across a project charter, architectural maps, or white papers covering specifics, direction etc. I'll likely, first spend my time just cataloging everything as it exists at the moment before really rolling up my sleeves and getting into what I'm going to be implementing and testing with my own copies. At this point, I don't want to come barging in on someone else's turf as I've got a major project I'm gearing up for and there are several things I'll be developing, along with building the corresponding training materials for in conjunction with the project. The work around Skinr for me is just going to be one small part.
Thanks again!