Prioritized list of features?

Events happening in the community are now at Drupal community events on www.drupal.org.
jessebeach's picture

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

himerus's picture

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

re: Git

jessebeach's picture

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

himerus's picture

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.

  • Code features
    • Make the zones a renderable array rather than using theme('zone')
    • Make the "special" zones/regions more easily movable to a new zone/region
      • Branding Region
      • Breadcrumb Region
  • Admin interface features
    • Make grid sizing dropdowns "smarter" via jQuery
    • Generic improvements to the current base interface for theme settings
    • Create a working model of the Omega UI module
  • User facing features
    • HTML5 Rewrite of core templates OR an HTML5+RDFa Starterkit
    • Make the dropdown menus more flexible
    • Equal height blocks AND regions via jQuery
  • Documentation
    • Outline of zones concept
    • Breakdown of Static/Dynamic Zones in Omega
    • Update default 960.gs concepts & introduction
    • A LOT MORE DOCUMENTATION...

Delta 2.x Roadmap

The following features need to be implemented in the Delta module.

  • Code Features
    • Import/Export
      • Default Import/Export through Delta interface
      • Provide "default" layouts
        • Split sidebars
        • Sidebars First
        • Sidebars Last
        • Full width Content Region
        • Minimal Zones (disabling most regions)
      • Integrate with Features module
      • Replace Omega Tools module for exporting the default theme settings for Omega subthemes.

wow!

jessebeach's picture

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

jessebeach's picture

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

himerus's picture

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)

re: moving the discussion

jessebeach's picture

I'm fine with any collaboration service. It's all text just text in a box.

HTML5

himerus's picture

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

will do

jessebeach's picture

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

jessebeach's picture

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

rggoode's picture

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

himerus's picture

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.

sweet

jessebeach's picture

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

jessebeach's picture

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

himerus's picture

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)

Excellent idea Jesse!

miche's picture

Excellent idea Jesse!


Michelle Lauer
michellelauer.com

Omega Framework

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: