I agree with Adrian, the style element alone already gives more that enough control to theme designers.
Every web developer has (or should have) at least a basic understanding of css and every time we step away from such a standard (like with additional attributes in the widgets) we make OFBiz a little harder to use and maintain, it's plenty hard enough already. Not every idea is a good idea and not every good idea is really needed. Regards Scott HotWax Media http://www.hotwaxmedia.com On 26/04/2011, at 8:37 AM, Adrian Crum wrote: > Main style sheet: > > .button-bar ul a.create,.button-bar a.create { > padding:6px 10px 6px 10px; > } > > Optional icons style sheet: > > .button-bar ul a.create,.button-bar a.create { > background: url(../images/button_sprite.png) no-repeat 0px 0px; > padding:6px 10px 6px 30px; > } > > No changes to markup needed. It is the same thing we do to switch rendering > from LTR to RTL. > > -Adrian > > On 4/25/2011 1:19 PM, Nicolas Malin wrote: >> Your are against me ? My popularity increases :) >> >> At this time : >> Screen definition : >> ------------------------ >> <link target="EditExampleLayer" ... style="buttontext create"/> >> >> >> Output html render : >> --------------------------- >> <a class="buttontext create" id="FindExample_LF_1_link" >> href="javascript:void(0);">Nouvel exemple</a> >> >> Style theme definition : >> ------------------------------ >> style.css : >> .button-bar ul a.create,.button-bar a.create { >> background: url(../images/button_sprite.png) no-repeat 0px 0px; >> padding:6px 10px 6px 30px; >> } >> >> >> My proposition, after your first remark : >> Screen definition : >> ------------------------ >> <link target="EditExampleLayer" ... style="buttontext"> >> <icons name="add"> >> </link> >> >> Or >> <link target="EditExampleLayer" ... style="buttontext" icons="add"> >> >> Or >> <link target="EditExampleLayer" ... style="buttontext" purpose="add"> >> >> >> Output html render : >> --------------------------- >> <a class="buttontext add" ... >Nouvel exemple</a> >> >> Style theme definition : >> ------------------------------ >> icons.css : >> .button-bar ul a.add,.button-bar a.add { >> background: url(../images/button_sprite.png) no-repeat 0px 0px; >> padding:6px 10px 6px 30px; >> } >> >> What's changes ? What is broken? Your are against widgets controlling >> styling but at this time all icons define by style attribute on elements to >> be used by theme. I propose more fexibility to explain the element's purpose >> that will be work by screen renderer and after by theme designer. >> >> To continue update icons improvement : >> <set field="iconsModeViewEnumId >> from-field="userPreferences.VT_ICONS_MODE_VIEW"/> <!--If User whant to view >> icons--> >> <set field="iconsStyleLocation" from-field="userPreferences.VT_ICONS_" >> global="true"/><!--If User have preference on icons to use--> >> <service service-name="getIconsVisualThemeResources"><!--return the css file >> to use that contains icons definition--> >> <field-map field-name="visualThemeId"/> >> <field-map field-name="iconsModeViewEnumId"/> >> </service> >> >> Nicolas >> >> Le 25/04/2011 14:25, Adrian Crum a écrit : >>> I'm against the idea of widgets controlling styling. Period. I am against >>> Nicolas or any other developer deciding which icons get used and where - >>> that is a decision that should be reserved for theme designers. >>> >>> To summarize my view: >>> >>> 1. Icon display and the choice of icons should be left to the theme >>> designer. Therefore, icon references should be kept in stylesheets. >>> 2. If a theme designer wants to give the user an option to use icons or >>> not, then the theme's templates can conditionally load a cascading >>> stylesheet that includes icons. >>> >>> -Adrian >>> >>> On 4/25/2011 5:14 AM, Jacques Le Roux wrote: >>>> On a second thought, we may use another technology than CSS and still have >>>> styles, see for instance in POS: posstyles.xml. So yes, >>>> styles add flexibility and independence. >>>> >>>> At 1st glance, Adrian's proposition sounds better from flexibility POV. >>>> But, if I have well understood, is still limited to icons or >>>> not in the whole OFBiz (like Google bar) when Nicolas's allows to set it >>>> by screens (why not even by form fields or menu entries?) >>>> >>>> I think this is really an important point in UI and should be discussed by >>>> the whole developers community, any other opinions, >>>> suggestions? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> From: "Adrian Crum" <[email protected]> >>>>> You can control icon display through user preferences without embedding >>>>> the icons in markup. A user setting can conditionally load >>>>> a stylesheet that references the icons. >>>>> >>>>> I'm not against having new icons in the project. An expanded selection of >>>>> icons is a great tool for theme designers to use. But >>>>> their use should be determined by the theme designers - not by screen >>>>> widgets. The OFBiz community has worked hard over the past 4 >>>>> years trying to get styling out of markup and into stylesheets. I will >>>>> push hard against any effort to reverse that. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> On 4/25/2011 1:32 AM, Nicolas Malin wrote: >>>>>> Adrian I understand your remark but I'm not completely in agreement with >>>>>> that. >>>>>> >>>>>> Icons is at once of the most visual but also a help user. We could >>>>>> associated directly to a themes but the reality is more >>>>>> complex. If I take the GTK project, every user can define if he wants >>>>>> icons, icons and text or only text independently of the >>>>>> themes. >>>>>> >>>>>> On issue OFBIZ-4259 I do an error to use icons through img because >>>>>> although they are images, they are a more complex management. >>>>>> >>>>>> I'm not for their exploitation only through css or style because >>>>>> although they results from it. We limit their display rendering >>>>>> on one technology et style don't allow user preference managment. >>>>>> >>>>>> I propose to continue icons integration, add a new element in screen >>>>>> renderer that indicates what icons use on menu and form >>>>>> field. Thence following the user preference and then the themes we >>>>>> display icons or not. Whether rendering css by then or >>>>>> treatment with an image, it will be template renderer are made their >>>>>> work. >>>>>> >>>>>> Nicolas >>>>>> >>>>>> >>>>>> Le 25/04/2011 05:21, Ryan Foster a écrit : >>>>>>> I thought the original idea that Nicolas proposed, was for this to be >>>>>>> configurable by theme (adding a >>>>>>> layoutSettings.VT_ICONS_LOC to data config). I think that you should >>>>>>> be able to turn icons on and off as well as change the >>>>>>> icon library location. >>>>>>> >>>>>>> Ryan L. Foster >>>>>>> 801.671.0769 >>>>>>> [email protected] >>>>>>> ryanlfoster.com >>>>>>> >>>>>>> On Apr 24, 2011, at 6:29 AM, Adrian Crum wrote: >>>>>>> >>>>>>>> The main problem I have with this is the idea that theme design has >>>>>>>> been taken away from the theme designer. In other words, >>>>>>>> icons should be added by the theme designer - they should not appear >>>>>>>> in all themes by default. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 4/24/2011 5:26 AM, Jacques Le Roux wrote: >>>>>>>>> It's actually related to >>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-4259 and r1095984 >>>>>>>>> >>>>>>>>> I did not see any issues in Flat Grey, could you post a screenshot? >>>>>>>>> >>>>>>>>> If it's really blocking (I doubt we can't fix any related issues), it >>>>>>>>> should be easy to configure with a property in >>>>>>>>> widget.properties to bypass image rendering in menus >>>>>>>>> (HtmlMenuRenderer.java around line 500) and buttons >>>>>>>>> (MacroFormRenderer.java look for >>>>>>>>> submitField.getImageLocation(context) or maybe rather >>>>>>>>> ModelFormField.java but this one >>>>>>>>> existed before, see >>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=1095984 for files >>>>>>>>> changed) >>>>>>>>> >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> From: "Adrian Crum"<[email protected]> >>>>>>>>>> I see that icons were added to menu items - maybe in rev 1088549. Is >>>>>>>>>> there a chance we can revert that? Or at least make it >>>>>>>>>> configurable on a per-theme basis? The new icons break the layout in >>>>>>>>>> the Flat Gray theme. It would be helpful if a theme can >>>>>>>>>> choose to use the icons or not use them. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
