Hi Adrian, finally I followed your hint about the pre-body section. I found that several screens had the TabBar in the pre-body section so I think we should change all other to follow the same pattern.
In Revision: 883020 I have moved several TabBar menus from the body to the pre-body and now the rendering is much better in both single and mul-colums layouts. If this is OK (may be a little adjustment is necessary on the TabBar margins to have it exactly as it was befor in other themes) I will go further changing al other screens. Is it OK with you? -Bruno 2009/11/16 Adrian Crum <[email protected]>: > Bruno, > > Did you notice that the GlobalDecorator already has a pre-body section? > > -Adrian > > Bruno Busco wrote: >> >> Adam, >> I will definitively put back the "new feature" in a different way that >> does not hurt. >> >> The "new feature" basically is the application tab bar at an higher >> level in the HTML so that it is rendered in the Dropping crumbs theme >> (I think I should find a better name for this theme) just below the >> breadcrumb. >> >> It will take some time and probably some discussion because I will ask >> details. >> I look forward to the community collabotation. >> >> -Bruno >> >> 2009/11/16 Adam Heath <[email protected]>: >>> >>> Bilgin Ibryam wrote: >>>> >>>> Adam Heath wrote: >>>>> >>>>> Adrian Crum wrote: >>>>> >>>>>> Developers, >>>>>> >>>>>> Please be careful when changing HTML element compounds. The recent >>>>>> >>>>> changes to certain themes are breaking the layout of the Flat Grey >>>>> theme - which shouldn't have been affected. >>>>> >>>>> Um, huh? So, because *new* things were done, possibly adding more >>>>> features, but it broke something else, you want to stop the new >>>>> feature? Why not just fix the thing that broke? >>>>> >>>> I'm a little confused now, because in OFBiz Committers Roles and >>>> Responsibilities is written this: >>>> >>>> *Rule #1 for a committer is the same as for a doctor:* *first do no >>>> harm*. Nothing should be committed that breaks existing functionality >>>> without replacing it either before or in the same commit. >>> >>> Sure. But we are all human, and we are not perfect. >>> >>> Mistakes happen, in both directions. If someone breaks existing >>> functionality, then either back out their change, or fix the existing >>> code to make it work. >>> >>> In this case, I think that maybe just backing out the changes was the >>> wrong approach to take. Unless they will come back at some point, >>> with whatever problems fixed that they caused. >>> >>> ps: I haven't actually looked at the changes in question. >>> >>>> Bilgin >>> >> >
