Posted by jessebeach on January 24, 2011 at 5:02pm
@himerus, do you have a list of features that you're currently working on?
Also, is the git repo the primary repo or are you mirroring from CVS still?
@himerus, do you have a list of features that you're currently working on?
Also, is the git repo the primary repo or are you mirroring from CVS still?
Comments
I do have a "short-list"
I do have a short list of features for the roadmap... I can try to polish it a bit, and get it posted here soon.
My git repo is a few commits behind CVS... I'm hating the balance between the two repos.. I LOVE git... and have my "main" environment currently setup with both CVS and git, and just commit to both sequentially.
I'm also confused/wondering, when the GIT migration happens, since I already have an omega repo on github, will I simply delete that repo, and now the migrated D.O. git repo will be the main one? Need to investigate that more... :)
I'll start posting up some of that content here as soon as I can! Thanks for coming over, and for the kind words at the camp this weekend! I got a lot of great feedback, and it continues to get more and more powerful/useful!!
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
re: Git
I'm still getting used to Git, but what I believe we can do is set up multiple remotes. For instance, you've got your master branch on the origin remote that you can push to e.g.
$git push origin master
You can set up a drupal remote like this
$ git remote add drupal git://[drupal]/[contrib]/[project].git
And then fetch/merge with it in your local repo e.g.
$ git fetch drupal
$ git merge drupal/master
And then push to it when necessary
$ git push drupal master
I think in the future, we'll keep our projects in our personal repos as well as contrib.
Roadmap...
That's great (git data)... I've not used multiple remotes in Git yet, but that looks handy... keeping a "bleeding edge" branch, and pushing to contrib when features are polished... while still being able to commit early & often on the features being worked on...
RE: the roadmap/feature set... here is what I have at the moment... not really prioritized as I think it's all quite important.. :)
Omega 2.x Roadmap
The following feature list will give a basic idea of what will/should be implemented in the Omega 2.x feature set prior to an official "stable" D7 release. That being said, the 2.x version is already quite stable, but pre-beta release, API changes may require updates to the template files, or functions in your subtheme.
Delta 2.x Roadmap
The following features need to be implemented in the Delta module.
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
wow!
The more I look at what I'm doing with arbitrary output device support and what you've built with Omega, the more I want to start folding my work into this incredible base you've built.
I'm going to spend a couple days going through the code and wrapping my head around Omega and the startkit. Right off the bat I can see that I'll be able to contribute with the HTML5 update/variant (I've always imagined this as a binary theme setting) and sidebar layouts. Also I'm pretty handy with jQuery and persnickety UI pieces.
also with Git
It's much easier to keep a feature confined to a branch, then merge that branch into the master branch when it's ready, so your feature is associated with one commit and thus much easier to roll back if necessary.
Glad to accept support/help...
As I mentioned this weekend, I'm more than glad to accept the help... I've pretty much had to leave the D6 version in the dust just to focus on D7 (which is all I really care about at this point) And with all the things I'd like to see in the Omega codebase to promote adoption, it's much more than a one-coder job (unless I want to be coding it for the next year!!)
In other news, I seem to be getting bashed for starting a GDO group for a theme/module... (don't ask) Even though there are plenty of them on GDO. So it MAY be that I go back to setting up an atrium instance offsite to handle this kind of stuff...
That, plus the inability to post video content/screencasts really makes me hate the GDO option. Pondering the options and time to setup. (no longer to setup atrium really than configure a GDO group to be pretty and useful with panels)
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
re: moving the discussion
I'm fine with any collaboration service. It's all text just text in a box.
HTML5
Jesse,
I've made a lot of updates to the Github branch of Omega in the last few days.
I've changed the zones into renderable elements, and also put in a core of HTML5 templates (that likely need a LOT of massaging)
My goal was to make sure that the basis was there when I release Beta1 (very shortly, but probably after the git migration just to save my sanity)
I'd love it if you could update your fork, and play around with that latest version on github!!
https://github.com/himerus/Omega
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
will do
I'll pull and look at it this afternoon. I'm working on some theming layer overrides that just aren't behaving like I want. It'll be a nice change of focus.
updates
The HTML5 code is solid. I would have made the same changes. One thing I did notice is that you declare position:relative on the new HTML elements.
article, header, footer, nav, section {
display: block; position: relative;
}
I would set them to position:static as a reset value.
There are some architectural structures in your code that I found astounding. The preprocess includes are fantastic.
In terms of CSS, this is what I would propose, let me know what you think. The defaults in Omega (defaults.css, tables.css, menus.css, etc) should be stripped of all "presentation" styling, e.g. borders, font colors, most left/right padding and margin, and backgrounds. I like to put all of this presentation information into a stylesheet named after the theme, in this case omega.css. In this way, the theme can be stripped of all ornamentation by excluded one file, instead of overriding numerous styles across several sheets.
Check out the five.css file in this theme (https://github.com/jessebeach/five-drupal/blob/master/css/five.css) and compare it to the screen.css file (https://github.com/jessebeach/five-drupal/blob/master/css/screen.css). By excluding the five.css from the theme, the basic structural properties are not lost - the content still centers on the page on monitors and forms a single column on small-screen devices. But it has zero ornament styling. It's my opinion (and this may be wrong), but sub-themers don't really want to start from scratch structurally, they want to start from scratch presentationally.
What do you think? Mind if I take a crack at splitting the styles up along these lines?
I agree
I think this is an excellent suggestion. As a sub-themer, I often find myself looking to strip out presentation elements in a theme in order to start putting in my own styles. By consolidating all these presentation elements into one file, you'll make that process simpler, and make an already amazing theme even more flexible.
Roger
_________________
Art has gone to the dogs
GoodeGallery.com
I definitely agree...
I completely agree...
When I first did the settings for each CSS file, I thought to myself "boy, it would be cool do disable each one", but I didn't think to hard on how to break up the CSS files exactly... On some sites I build with a radically different setup/style (the omega-microsite for example) I will turn off ALL but the reset.css (960.gs can't be disabled) getting me back to my blank slate.
I like the idea of having omega.css that has ALL of the "cool" "ornamental" styling in there.
At some point, I want to go back and do a full CSS audit too and clean things up a bit, I may put some preprocess in there to turn off all core stylesheets except for a couple (some of the core css is what I think caused me to use selectors I didn't like in the past) not sure there...
but in answer to your question, that would be a great help... The CSS has been a thorn in my side for some time, and sort of the last piece that I've put on the docket to really dig back into as I know how to get around pretty much ANY CSS, so am used to dealing with a funky selector or two from time to time.
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
sweet
I have Wednesday free at Acquia to focus on Drupal projects. I'll pick this up then and send a pull request when I've got it far enough long to look at.
ended up not having Wednesday free
I ended up not having the free time yesterday that I thought I would. We're getting Views ready for a D7 release by DrupalCon and I spent the day (and most of the night and morning). Sorry! Jake, working on Omega is top of my list once work stuff is out of the way.
I understand!!!
I definitely know how that goes!!!
I've been doing a lot, and am already to Beta3 as there were some issues still cropping up in the first two beta releases.
Beta3 seems to be stable, and back to normal... I've wiped ALL my CVS data, and will not be releasing any more until the Git migration is done on D.O. However, I've already today made some awesome updates to the GitHub repo...
Now there is an HTML5 subtheme (default starterkit) and an XHTML starterkit for those that are scared of HTML5.
I've updated Omega Tools drush functionality to create both types of subthemes.
Drush usage:
Examples:
drush omega-subtheme "Subtheme Name" - Create an HTML5 Omega subtheme to the default sites/all/themes folder named subtheme_name.
drush omega-subtheme "Subtheme Name" HTML5 - Create an HTML5 Omega subtheme to the default sites/all/themes folder named subtheme_name.
drush omega-subtheme "Subtheme Name" XHTML - Create an XHTML Omega subtheme to the default sites/all/themes folder named subtheme_name.
drush omega-subtheme "Subtheme Name" --destination=example.com - Create an HTML5 Omega subtheme to sites/example.com/themes folder named subtheme_name.
Arguments:
name - The name of the subtheme to create.
type - The type of subtheme to create. XHTML or HTML5 (default)
Options:
--destination - The site specific folder name in /sites where the information should be saved. /sites/all by default.
GitHub Repos:
Omega - https://github.com/himerus/Omega
Omega Tools - https://github.com/himerus/Omega-Tools
Delta - https://github.com/himerus/Delta
Omega UI - https://github.com/himerus/Omega-UI (I started playing with some ideas here yesterday getting a basic structure setup)
Jake Strawn (@himerus)
ThemeGeeks | Development Geeks
Omega - 960.gs
Excellent idea Jesse!
Excellent idea Jesse!
Michelle Lauer
michellelauer.com