Make regions alterable

Well regions affect the object itself. These aren't the regions defined in your theme. So basically, you get 5 regions per object to theme.

I had the same problem understanding the word "regions" when evaluating the display suite family of modules. I get it. You're setting up five div'ed regions.

Two feature requests regarding the "why aren't my theme.info regions showing up" confusion:

1. I would love the ability to add more regions and take some away, programmatically. (Would this be too confusing or verge too close to panels? Maybe.)
2. Completely independent of #1, I would also like the ability to assign a display suite region to a theme region for output.

Thank you for this amazing module. Hopefully you will consider these requests as you works towards version 2.0

Josh

Feature 1 shouldn't be that hard to implement, we're already thinking of that.
I'm going to split those requests in 2, it shouldn't be that hard, but I need to think about it, see #710034: Add posibility to assign a ds region to a theme region

Changing the title to reflect the request.

@joshmiller you can see your second feature request (assign ds region to theme region) already working on http://demo.customsource.be/content/plugins :)

Some brainstorming thoughts about the region alter feature. Implementing a drupal_alter is probably the easiest thing, however, right now, we're not passing the build mode nor the type. This means that an alter will affect all object types and build modes. drupal_alter() seems a bit overhead too I think, unless we also add some caching which seems necessary. So a few thoughts/questions:

1. Pass the build mode & type so we can have a different number of regions per object & build mode.
2. Introduce hook_ds_regions and a hook_ds_regions_alter, this would lead to the concept of 'layouts' - not sure yet how we should handle css than since we're now splitting the default region css per module see #722852: Theming optimizations. We could introduce a 'css' key where one can add the location of the css for this 'layout' if it's not the default one. We could cache all css locations and do drupal_add_css somewhere else instead in the hook_init of all the modules.
3. Provide an interface for non programmers - is something we can't ignore right ?
4. Cache all this stuff. Simply clearing the cache or going to the interface would lead to resetting the regions/layouts cache

Those with remarks, please reply :)

Postponing this for now - 1.1 will have fieldgroup support and also classes/styles which you can select via the interface which makes it easy to nest fields into divs into regions.
It's a bit related also with #570978: Possible new features for D7 port and needs a complete overhaul of the code which will be for a 2.0 branch.