New Icons

[Adrian Crum <ad...@sandglass-software.com>]

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

Re: New Icons

[Jacques Le Roux <ja...@les7arts.com>]

This is all good, but what do we do for the existing image-location which has been introduced earlier, with the Themes I guess?
I believe Nicolas saw that and followed the way...

It seems we 1st need a serious theme refactoring...

Jacques

From: "David E Jones" <de...@me.com>
>
> Thanks Scott, I agree. We need to use flexible and generic tools like CSS more, and stop creating so many nightmares of
> parameterization. It seems like over the last few years every new general feature has been handled not by design and considering
> the best generic solution, or by looking at where the framework can be extended or changed to handle something better (while
> keeping things like visual elements separated from business and technical elements, ie the form widget ideally shouldn't have ANY
> styling in it and even layout is separated from the base field definitions). It seems like all of the new features are handled by
> parameterizing the heck out of default templates and creating decorator screens and all sorts of inconsistent "conventions".
>
> This maybe goes back to the the discussion in the "hiding functionality in ofbiz." thread. It's pretty clear that a big problem is
> near zero collaboration on design. I know that's difficult with a larger group, and that when the active group of developers in
> OFBiz was smaller we were _constantly_ discussing new feature ideas and making dramatic changes to initial ideas through those
> discussions. That started with the early days when Andrew and I spent hours on the phone discussing things, so much so that we
> changed cell phone carriers so we could use the unlimited mobile to mobile minutes on the same carrier. That continued with the
> various people who got involved early on too, sometimes with phone calls and often with long discussions on the mailing lists.
>
> It's definitely the case that not every little thing was discussed, and many things were discussed after a commit (which was often
> used to facilitate communication and solicit feedback since the contributor and user communities were both much smaller). These
> days there seems to be almost no discussion, and even very few requests for feedback... and understandably so as many of the
> requests for feedback result in very non-productive mudslinging.
>
> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of
> the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of
> redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including
> various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of
> parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages
> innovation and improvement in the project.
>
> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the
> ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained
> by a different group of people than maintains the more business-oriented functionality of OFBiz.
>
> -David
>
>
>
> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>
>> 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" <ad...@sandglass-software.com>
>>>>>>> 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
>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>
>

Re: New Icons

[Nicolas Malin <ma...@librenberry.net>]

Excuse me adrian for this late answer,
Your table explanation is clear and I agree with that.

On tables managing a designer and then a precise visual improvement is 
interresting and remains simple. We are in a well-defined element.

Good point that we agree!

Now on icons, the problem is wider than table since we have different 
domains:
  * icons on submit button can be associate only to a style
  * icons on menu, a little harder than button, maybe given the 
possibility to use menu name as class style
  * icons on field (diplay or text) for user eye pleasure
  * icons on hyperlink for user charm and reduce screen in carrying 
management information (ex : mail icons with title-image that contains 
email address).

For each case I wish :
  * Having generic system that simplify / limit developer possibility
  * Manage style icons by the theme
  * Keep the concept of condensing information through icons, which is a 
real user need when using lists

I suggest, if you agree to bring your vision for its proper integration 
issues, to create some jira that explain for each case :
  * improvements expected
  * Solution used at this time on internal projects
  * How I see the solution

 From that we can work with own different visions
Nicolas

Le 29/04/2011 14:53, Adrian Crum a écrit :
> To understand our differences a little better, it might help to set 
> aside the subject of icons for a moment and consider another visual 
> element - the HTML <table> element. I believe the way HTML tables are 
> handled in OFBiz represents a good balance between developers and 
> theme designers. If we can agree on how tables are handled, then maybe 
> we can apply the same concept to icons and agree on those too. If we 
> can't agree on how tables are handled, then... well... we will just 
> have to agree to disagree. ;-)
>
> OFbiz provides a CSS class for basic <table> element layout - called 
> basic-table. That class provides simple positioning and spacing. The 
> basic-table class is intended to be "decorated" with other classes to 
> add other visual embellishments. A developer can add light-grid or 
> dark-grid CSS classes to basic-table to give it a grid. A developer 
> can add a hover bar to a table by adding the hover-bar CSS class to 
> basic-table. This CSS class decorator pattern has been in use for a 
> while now, and it seems to be a good approach because it gets used a lot.
>
> The developer is free to choose which classes make the most sense for 
> the screen they are developing. What the developer CAN'T do is specify 
> what those classes look like - that is left up to the theme designer. 
> The CSS classes are a way for the developer to give the theme designer 
> hints about what a particular HTML element should look like without 
> being specific about its visual appearance.
>
> The theme designer controls the positioning and spacing in 
> basic-table. The theme designer controls the color and line thickness 
> of light-grid and dark-grid. The theme designer controls the 
> appearance of hover-bar. Different themes might style those classes 
> differently, but what remains consistent across themes is that they 
> are all used in the same way. An HTML <table> element styled with 
> "basic-table light-grid" will always have a light grid - regardless of 
> the theme. Now, here is something interesting to think about - a theme 
> designer could choose not to style the grids, and eliminate table 
> grids altogether. There is no "law" saying that all CSS classes must 
> be styled. A theme that eliminates grids may or may not get used - it 
> depends on the user. Some users might prefer to have grids turned off 
> - so they would select the "gridless" theme. ***This is where the 
> balance between developer and theme designer comes in*** - the 
> developer provides a hint that a table should have grids, but the 
> developer doesn't force grids on the theme designer or the user.
>
> Now let's apply the icon conversation to the HTML <table> element 
> example. What has been suggested is that all themes be made consistent 
> by hard-coding table grids in the markup. When I objected to that, it 
> was suggested that table grids can be enabled/disabled by a user 
> setting. For the sake of compromise I agreed to that, but I believe it 
> is unnecessary because a user could simply choose a theme that has 
> grids enabled or disabled.
>
> To summarize: What I am advocating is that we treat icons the same way 
> as we do all other visual elements - let the theme designer have 
> control of their use. I see no valid reason why icons should be 
> treated differently. Users who want icons will choose a theme that 
> uses them. Users who don't want icons will choose a theme that doesn't 
> use them. The system we use now is flexible and it works - it doesn't 
> need to be changed.


-- 
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: New Icons

[Ryan Foster <co...@ryanlfoster.com>]

I agree with Adrian on this one.  We have discussed this topic at length with not only tables, but buttons, links, list, etc.  It is hard to argue against the separation of presentation and logic... ever really.  The very nature (and the name itself) of CSS makes styling flexible and we need to take advantage of that, not disregard it.  There is nothing wrong with chaining, cascading, or completely ignoring class names on an element.  Having <table class="basic-table light-grid hover-bar unicorn elephant"> doesn't mean that, as a designer, I need to make this table look basic, light, or unicorn-like.  I could simply decide to make all tables look exactly the same by just targeting:

table { whatever attributes I feel like putting in here...}

By the same token, just because an element says <button class="btn add-btn"> doesn't mean, as a designer, that I necessarily want this button to have an "plus" icon next to it.  Maybe I do, maybe I don't, but I have the choice to simply ignore it in my stylesheet, and I don't have to worry about touching the code.

Ryan L. Foster
801.671.0769
contact@ryanlfoster.com
ryanlfoster.com

On Apr 29, 2011, at 6:53 AM, Adrian Crum wrote:

> To understand our differences a little better, it might help to set aside the subject of icons for a moment and consider another visual element - the HTML <table> element. I believe the way HTML tables are handled in OFBiz represents a good balance between developers and theme designers. If we can agree on how tables are handled, then maybe we can apply the same concept to icons and agree on those too. If we can't agree on how tables are handled, then... well... we will just have to agree to disagree. ;-)
> 
> OFbiz provides a CSS class for basic <table> element layout - called basic-table. That class provides simple positioning and spacing. The basic-table class is intended to be "decorated" with other classes to add other visual embellishments. A developer can add light-grid or dark-grid CSS classes to basic-table to give it a grid. A developer can add a hover bar to a table by adding the hover-bar CSS class to basic-table. This CSS class decorator pattern has been in use for a while now, and it seems to be a good approach because it gets used a lot.
> 
> The developer is free to choose which classes make the most sense for the screen they are developing. What the developer CAN'T do is specify what those classes look like - that is left up to the theme designer. The CSS classes are a way for the developer to give the theme designer hints about what a particular HTML element should look like without being specific about its visual appearance.
> 
> The theme designer controls the positioning and spacing in basic-table. The theme designer controls the color and line thickness of light-grid and dark-grid. The theme designer controls the appearance of hover-bar. Different themes might style those classes differently, but what remains consistent across themes is that they are all used in the same way. An HTML <table> element styled with "basic-table light-grid" will always have a light grid - regardless of the theme. Now, here is something interesting to think about - a theme designer could choose not to style the grids, and eliminate table grids altogether. There is no "law" saying that all CSS classes must be styled. A theme that eliminates grids may or may not get used - it depends on the user. Some users might prefer to have grids turned off - so they would select the "gridless" theme. ***This is where the balance between developer and theme designer comes in*** - the developer provides a hint that a table should have grids, but the developer doesn't force grids on the theme designer or the user.
> 
> Now let's apply the icon conversation to the HTML <table> element example. What has been suggested is that all themes be made consistent by hard-coding table grids in the markup. When I objected to that, it was suggested that table grids can be enabled/disabled by a user setting. For the sake of compromise I agreed to that, but I believe it is unnecessary because a user could simply choose a theme that has grids enabled or disabled.
> 
> To summarize: What I am advocating is that we treat icons the same way as we do all other visual elements - let the theme designer have control of their use. I see no valid reason why icons should be treated differently. Users who want icons will choose a theme that uses them. Users who don't want icons will choose a theme that doesn't use them. The system we use now is flexible and it works - it doesn't need to be changed.
> 
> -Adrian
> 
> 
> On 4/29/2011 2:20 AM, Nicolas Malin wrote:
>> Thanks all for you comments.
>> 
>> The last patch I did was mostly on icons, but was more an attempt to increase the "user experience" by mixing actual icons management and dynamic selection coming the visual theme.
>> Now I understand what is meant, and the directions everyone wants to go to, which are quality and simplicity, and then lead to innovation. I think we should then continue this way.
>> Adrian, you are insisting that theme designers should handle its icons, but I'm more saying that we should normalize icon usages so the developer or the theme designer are the more directed possible and so the layouts are normalized.
>> 
>> I'm not sure that only using style attributes is the best way, as this is chaining classes when you want to apply more than one visual style, and this is also widely used in jQuery. This is working when the developer is well advanced in his interface.
>> So I'm telling this would be better to add an objective or goal to a field, and then:
>> * restrain usages by enumeration in the xsd
>> * restrain goals number linked to a field type (button, link, text, ...)
>> * help theme designer by fixing clear goals and style names
>> 
>> It would also be possible to add new values if exceptions are coming, but only in this case...
>> 
>> On the design side, each theme would have a purpose.css file which will only keep classes in direct relaation with the previous definitions. The designer will then have a clear vision on field usage and what to do for rendering.
>> I can work on a POC, which would come in the images folder, or create a generic theme and then use it as a basis
>> 
>> Nicolas
>> 
>> Le 26/04/2011 21:31, Adrian Crum a écrit :
>>> I agree. One of the things I've tried to do to help that along is by writing the Best Practices on the Wiki site. But a more design-oriented approach would help too. From my perspective, the Best Practices basically say "you should do it this way", and in the design-oriented pages you can learn more about WHY you should do it that way.
>>> 
>>> I like the idea of working with the current community to get a consensus on these things and then loosely enforcing them. I keep holding out hope that the desire to produce a quality product will increase.
>>> 
>>> I understand your viewpoint of just starting over with new code and new community members. At first glance that seems attractive. But it seems to me that's like curing cancer by executing the patient.
>>> 
>>> -Adrian
>>> 
>>> On 4/26/2011 12:16 PM, David E Jones wrote:
>>>> Yes, that's true. That goes back to one of the big difficulties with something like OFBiz managed in the "Apache way". OFBiz isn't a project driven by specifications, and so many decisions are made in a more ad-hoc manner.
>>>> 
>>>> If we were to step back and make OFBiz spec-driven by actually writing up requirements and then creating designs (specs) based on the requirements, and then implementing to those, and testing against them.
>>>> 
>>>> That sort of effort could happen right now by collaborating on documents that represent requirements, and then on documents that represent designs. Those would be separate from the project for (probably) quite a while, so wouldn't interfere with current happenings.
>>>> 
>>>> -David
>>>> 
>>>> 
>>>> On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
>>>> 
>>>>> I agree with you on the unnecessary complication of common or shared artifacts. I have been ranting for years about the Global Decorator being filled with a lot of things that don't belong there, but nothing changes - people keep dumping more stuff in there. So the problem is caused by more than a lack of discussion in the design phase, it's also caused by a lack of care after the design.
>>>>> 
>>>>> -Adrian
>>>>> 
>>>>> On 4/26/2011 9:52 AM, David E Jones wrote:
>>>>>> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project.
>>>>>> 
>>>>>> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.
>>>>>> 
>>>>>> -David
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>>>>>> 
>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>> 
>> 

Re: New Icons

[Jacques Le Roux <ja...@les7arts.com>]

As I said before this is all good, but for instance in Firefox no need to choose a theme to be able to remove/put icons buttons in
the buttons bar. Firefox is only an example, we know there are much more uses of this design.
Don't get me wrong, I'm not against themes at all. But I wonder if we really need to build specific themes to be able to choose to
have some buttons or not. Again look like the theme argument is for all icons or none (the possible combinaisons are obviously an
overkill). It seems to me that we still miss a mechanism to remove/add icons on buttons/menus. In the "hiding functionality in
ofbiz" discussion in user ML some would prefer to set this with roles. It makes sense but is still not very flexbile: each person
should be able also to remove/add icons on buttons or menu. For instance I like icons menu addons in Firefox, not only because I
like images (certainly a rest from my education while young, where you were given good points when you succeded ;o) but also because
it allows me to quicker pick a menu entry than having to search for it (no brainner). But I can understand that some other would
prefer to have their own icons (sets?) or not have icons at all on some menu/buttons, etc.

To summarize my POV:

* Themes are great to set things in a whole (also developers can chose to apply or not styles to set icons or not in
custom/customized applications...)
* Roles are great to set things at the enterprise level
* A mechanism to allow individuals users to choose their own icons (or sets of icons?) or to not have icons everywhere would be a
good complement

With current OFBiz state, CSS styles (themes) are the easiest way to achieve the goal, roles still need more work (notably to
collect the features and group them by roles, then to have those roles set and used in code), while a mechanism. Of course to follow
Adrian idea this could apply not only to icons. But it's the thing which comes instantly in mind. Images are shorcut for words.
After all, Chinese use them as words. I mean they don't encode their words in letters, a proof that the power of alphabet is not the
only way.

I was a long time user of APL while also working with traditionnal languages (C, Pascal). APL is a symbolic language (was first a
macro assembler), for instance you have a sole symbol to represent/solve a system of linear equations and you are not encouraged to
use loops. I think you could compare APL vs C/Pascal to Chinese vs Alphabetized languages...Ho sorry almost out of subjet, I'm a
holidays dreamer :o)

Jacques

From: "Adrian Crum" <ad...@sandglass-software.com>
> To understand our differences a little better, it might help to set aside the subject of icons for a moment and consider another
> visual element - the HTML <table> element. I believe the way HTML tables are handled in OFBiz represents a good balance between
> developers and theme designers. If we can agree on how tables are handled, then maybe we can apply the same concept to icons and
> agree on those too. If we can't agree on how tables are handled, then... well... we will just have to agree to disagree. ;-)
>
> OFbiz provides a CSS class for basic <table> element layout - called basic-table. That class provides simple positioning and
> spacing. The basic-table class is intended to be "decorated" with other classes to add other visual embellishments. A developer
> can add light-grid or dark-grid CSS classes to basic-table to give it a grid. A developer can add a hover bar to a table by adding
> the hover-bar CSS class to basic-table. This CSS class decorator pattern has been in use for a while now, and it seems to be a
> good approach because it gets used a lot.
>
> The developer is free to choose which classes make the most sense for the screen they are developing. What the developer CAN'T do
> is specify what those classes look like - that is left up to the theme designer. The CSS classes are a way for the developer to
> give the theme designer hints about what a particular HTML element should look like without being specific about its visual
> appearance.
>
> The theme designer controls the positioning and spacing in basic-table. The theme designer controls the color and line thickness
> of light-grid and dark-grid. The theme designer controls the appearance of hover-bar. Different themes might style those classes
> differently, but what remains consistent across themes is that they are all used in the same way. An HTML <table> element styled
> with "basic-table light-grid" will always have a light grid - regardless of the theme. Now, here is something interesting to think
> about - a theme designer could choose not to style the grids, and eliminate table grids altogether. There is no "law" saying that
> all CSS classes must be styled. A theme that eliminates grids may or may not get used - it depends on the user. Some users might
> prefer to have grids turned off - so they would select the "gridless" theme. ***This is where the balance between developer and
> theme designer comes in*** - the developer provides a hint that a table should have grids, but the developer doesn't force grids
> on the theme designer or the user.
>
> Now let's apply the icon conversation to the HTML <table> element example. What has been suggested is that all themes be made
> consistent by hard-coding table grids in the markup. When I objected to that, it was suggested that table grids can be
> enabled/disabled by a user setting. For the sake of compromise I agreed to that, but I believe it is unnecessary because a user
> could simply choose a theme that has grids enabled or disabled.
>
> To summarize: What I am advocating is that we treat icons the same way as we do all other visual elements - let the theme designer
> have control of their use. I see no valid reason why icons should be treated differently. Users who want icons will choose a theme
> that uses them. Users who don't want icons will choose a theme that doesn't use them. The system we use now is flexible and it
> works - it doesn't need to be changed.
>
> -Adrian
>
>
> On 4/29/2011 2:20 AM, Nicolas Malin wrote:
>> Thanks all for you comments.
>>
>> The last patch I did was mostly on icons, but was more an attempt to increase the "user experience" by mixing actual icons
>> management and dynamic selection coming the visual theme.
>> Now I understand what is meant, and the directions everyone wants to go to, which are quality and simplicity, and then lead to
>> innovation. I think we should then continue this way.
>> Adrian, you are insisting that theme designers should handle its icons, but I'm more saying that we should normalize icon usages
>> so the developer or the theme designer are the more directed possible and so the layouts are normalized.
>>
>> I'm not sure that only using style attributes is the best way, as this is chaining classes when you want to apply more than one
>> visual style, and this is also widely used in jQuery. This is working when the developer is well advanced in his interface.
>> So I'm telling this would be better to add an objective or goal to a field, and then:
>> * restrain usages by enumeration in the xsd
>> * restrain goals number linked to a field type (button, link, text, ...)
>> * help theme designer by fixing clear goals and style names
>>
>> It would also be possible to add new values if exceptions are coming, but only in this case...
>>
>> On the design side, each theme would have a purpose.css file which will only keep classes in direct relaation with the previous
>> definitions. The designer will then have a clear vision on field usage and what to do for rendering.
>> I can work on a POC, which would come in the images folder, or create a generic theme and then use it as a basis
>>
>> Nicolas
>>
>> Le 26/04/2011 21:31, Adrian Crum a écrit :
>>> I agree. One of the things I've tried to do to help that along is by writing the Best Practices on the Wiki site. But a more
>>> design-oriented approach would help too. From my perspective, the Best Practices basically say "you should do it this way", and
>>> in the design-oriented pages you can learn more about WHY you should do it that way.
>>>
>>> I like the idea of working with the current community to get a consensus on these things and then loosely enforcing them. I keep
>>> holding out hope that the desire to produce a quality product will increase.
>>>
>>> I understand your viewpoint of just starting over with new code and new community members. At first glance that seems
>>> attractive. But it seems to me that's like curing cancer by executing the patient.
>>>
>>> -Adrian
>>>
>>> On 4/26/2011 12:16 PM, David E Jones wrote:
>>>> Yes, that's true. That goes back to one of the big difficulties with something like OFBiz managed in the "Apache way". OFBiz
>>>> isn't a project driven by specifications, and so many decisions are made in a more ad-hoc manner.
>>>>
>>>> If we were to step back and make OFBiz spec-driven by actually writing up requirements and then creating designs (specs) based
>>>> on the requirements, and then implementing to those, and testing against them.
>>>>
>>>> That sort of effort could happen right now by collaborating on documents that represent requirements, and then on documents
>>>> that represent designs. Those would be separate from the project for (probably) quite a while, so wouldn't interfere with
>>>> current happenings.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
>>>>
>>>>> I agree with you on the unnecessary complication of common or shared artifacts. I have been ranting for years about the Global
>>>>> Decorator being filled with a lot of things that don't belong there, but nothing changes - people keep dumping more stuff in
>>>>> there. So the problem is caused by more than a lack of discussion in the design phase, it's also caused by a lack of care
>>>>> after the design.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 4/26/2011 9:52 AM, David E Jones wrote:
>>>>>> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead
>>>>>> of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible
>>>>>> amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of
>>>>>> also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with
>>>>>> the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult
>>>>>> and discourages innovation and improvement in the project.
>>>>>>
>>>>>> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that
>>>>>> the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project
>>>>>> maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>>>>>>
>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>
>>

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

To understand our differences a little better, it might help to set 
aside the subject of icons for a moment and consider another visual 
element - the HTML <table> element. I believe the way HTML tables are 
handled in OFBiz represents a good balance between developers and theme 
designers. If we can agree on how tables are handled, then maybe we can 
apply the same concept to icons and agree on those too. If we can't 
agree on how tables are handled, then... well... we will just have to 
agree to disagree. ;-)

OFbiz provides a CSS class for basic <table> element layout - called 
basic-table. That class provides simple positioning and spacing. The 
basic-table class is intended to be "decorated" with other classes to 
add other visual embellishments. A developer can add light-grid or 
dark-grid CSS classes to basic-table to give it a grid. A developer can 
add a hover bar to a table by adding the hover-bar CSS class to 
basic-table. This CSS class decorator pattern has been in use for a 
while now, and it seems to be a good approach because it gets used a lot.

The developer is free to choose which classes make the most sense for 
the screen they are developing. What the developer CAN'T do is specify 
what those classes look like - that is left up to the theme designer. 
The CSS classes are a way for the developer to give the theme designer 
hints about what a particular HTML element should look like without 
being specific about its visual appearance.

The theme designer controls the positioning and spacing in basic-table. 
The theme designer controls the color and line thickness of light-grid 
and dark-grid. The theme designer controls the appearance of hover-bar. 
Different themes might style those classes differently, but what remains 
consistent across themes is that they are all used in the same way. An 
HTML <table> element styled with "basic-table light-grid" will always 
have a light grid - regardless of the theme. Now, here is something 
interesting to think about - a theme designer could choose not to style 
the grids, and eliminate table grids altogether. There is no "law" 
saying that all CSS classes must be styled. A theme that eliminates 
grids may or may not get used - it depends on the user. Some users might 
prefer to have grids turned off - so they would select the "gridless" 
theme. ***This is where the balance between developer and theme designer 
comes in*** - the developer provides a hint that a table should have 
grids, but the developer doesn't force grids on the theme designer or 
the user.

Now let's apply the icon conversation to the HTML <table> element 
example. What has been suggested is that all themes be made consistent 
by hard-coding table grids in the markup. When I objected to that, it 
was suggested that table grids can be enabled/disabled by a user 
setting. For the sake of compromise I agreed to that, but I believe it 
is unnecessary because a user could simply choose a theme that has grids 
enabled or disabled.

To summarize: What I am advocating is that we treat icons the same way 
as we do all other visual elements - let the theme designer have control 
of their use. I see no valid reason why icons should be treated 
differently. Users who want icons will choose a theme that uses them. 
Users who don't want icons will choose a theme that doesn't use them. 
The system we use now is flexible and it works - it doesn't need to be 
changed.

-Adrian


On 4/29/2011 2:20 AM, Nicolas Malin wrote:
> Thanks all for you comments.
>
> The last patch I did was mostly on icons, but was more an attempt to 
> increase the "user experience" by mixing actual icons management and 
> dynamic selection coming the visual theme.
> Now I understand what is meant, and the directions everyone wants to 
> go to, which are quality and simplicity, and then lead to innovation. 
> I think we should then continue this way.
> Adrian, you are insisting that theme designers should handle its 
> icons, but I'm more saying that we should normalize icon usages so the 
> developer or the theme designer are the more directed possible and so 
> the layouts are normalized.
>
> I'm not sure that only using style attributes is the best way, as this 
> is chaining classes when you want to apply more than one visual style, 
> and this is also widely used in jQuery. This is working when the 
> developer is well advanced in his interface.
> So I'm telling this would be better to add an objective or goal to a 
> field, and then:
> * restrain usages by enumeration in the xsd
> * restrain goals number linked to a field type (button, link, text, ...)
> * help theme designer by fixing clear goals and style names
>
> It would also be possible to add new values if exceptions are coming, 
> but only in this case...
>
> On the design side, each theme would have a purpose.css file which 
> will only keep classes in direct relaation with the previous 
> definitions. The designer will then have a clear vision on field usage 
> and what to do for rendering.
> I can work on a POC, which would come in the images folder, or create 
> a generic theme and then use it as a basis
>
> Nicolas
>
> Le 26/04/2011 21:31, Adrian Crum a écrit :
>> I agree. One of the things I've tried to do to help that along is by 
>> writing the Best Practices on the Wiki site. But a more 
>> design-oriented approach would help too. From my perspective, the 
>> Best Practices basically say "you should do it this way", and in the 
>> design-oriented pages you can learn more about WHY you should do it 
>> that way.
>>
>> I like the idea of working with the current community to get a 
>> consensus on these things and then loosely enforcing them. I keep 
>> holding out hope that the desire to produce a quality product will 
>> increase.
>>
>> I understand your viewpoint of just starting over with new code and 
>> new community members. At first glance that seems attractive. But it 
>> seems to me that's like curing cancer by executing the patient.
>>
>> -Adrian
>>
>> On 4/26/2011 12:16 PM, David E Jones wrote:
>>> Yes, that's true. That goes back to one of the big difficulties with 
>>> something like OFBiz managed in the "Apache way". OFBiz isn't a 
>>> project driven by specifications, and so many decisions are made in 
>>> a more ad-hoc manner.
>>>
>>> If we were to step back and make OFBiz spec-driven by actually 
>>> writing up requirements and then creating designs (specs) based on 
>>> the requirements, and then implementing to those, and testing 
>>> against them.
>>>
>>> That sort of effort could happen right now by collaborating on 
>>> documents that represent requirements, and then on documents that 
>>> represent designs. Those would be separate from the project for 
>>> (probably) quite a while, so wouldn't interfere with current 
>>> happenings.
>>>
>>> -David
>>>
>>>
>>> On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
>>>
>>>> I agree with you on the unnecessary complication of common or 
>>>> shared artifacts. I have been ranting for years about the Global 
>>>> Decorator being filled with a lot of things that don't belong 
>>>> there, but nothing changes - people keep dumping more stuff in 
>>>> there. So the problem is caused by more than a lack of discussion 
>>>> in the design phase, it's also caused by a lack of care after the 
>>>> design.
>>>>
>>>> -Adrian
>>>>
>>>> On 4/26/2011 9:52 AM, David E Jones wrote:
>>>>> And yes, not every idea is a good one and many things really don't 
>>>>> belong in the framework. Putting things in themes instead of the 
>>>>> framework is a good idea for many things. And on the topic of 
>>>>> themes, it would be nice (and reduce the incredible amount of 
>>>>> redundancy in themes) if the themes were limited to visual 
>>>>> artifacts such as images and style sheets, instead of also 
>>>>> including various templates. Take these hugely redundant theme 
>>>>> templates (especially for header) and combine that with the 
>>>>> practice of parameterizing every little thing... and you have an 
>>>>> error-prone tangle that makes customization difficult and 
>>>>> discourages innovation and improvement in the project.
>>>>>
>>>>> Sorry for the rant, but this kind of thing has been going on for a 
>>>>> long time and is another reason why I still maintain that the ONLY 
>>>>> way OFBiz will ever have a clean framework separation, and even a 
>>>>> clean framework, is if it is a separate project maintained by a 
>>>>> different group of people than maintains the more 
>>>>> business-oriented functionality of OFBiz.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>>>>>
>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>> 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
>>>>>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>
>

Re: New Icons

[Nicolas Malin <ma...@librenberry.net>]

Thanks all for you comments.

The last patch I did was mostly on icons, but was more an attempt to 
increase the "user experience" by mixing actual icons management and 
dynamic selection coming the visual theme.
Now I understand what is meant, and the directions everyone wants to go 
to, which are quality and simplicity, and then lead to innovation. I 
think we should then continue this way.
Adrian, you are insisting that theme designers should handle its icons, 
but I'm more saying that we should normalize icon usages so the 
developer or the theme designer are the more directed possible and so 
the layouts are normalized.

I'm not sure that only using style attributes is the best way, as this 
is chaining classes when you want to apply more than one visual style, 
and this is also widely used in jQuery. This is working when the 
developer is well advanced in his interface.
So I'm telling this would be better to add an objective or goal to a 
field, and then:
* restrain usages by enumeration in the xsd
* restrain goals number linked to a field type (button, link, text, ...)
* help theme designer by fixing clear goals and style names

It would also be possible to add new values if exceptions are coming, 
but only in this case...

On the design side, each theme would have a purpose.css file which will 
only keep classes in direct relaation with the previous definitions. The 
designer will then have a clear vision on field usage and what to do for 
rendering.
I can work on a POC, which would come in the images folder, or create a 
generic theme and then use it as a basis

Nicolas

Le 26/04/2011 21:31, Adrian Crum a écrit :
> I agree. One of the things I've tried to do to help that along is by 
> writing the Best Practices on the Wiki site. But a more 
> design-oriented approach would help too. From my perspective, the Best 
> Practices basically say "you should do it this way", and in the 
> design-oriented pages you can learn more about WHY you should do it 
> that way.
>
> I like the idea of working with the current community to get a 
> consensus on these things and then loosely enforcing them. I keep 
> holding out hope that the desire to produce a quality product will 
> increase.
>
> I understand your viewpoint of just starting over with new code and 
> new community members. At first glance that seems attractive. But it 
> seems to me that's like curing cancer by executing the patient.
>
> -Adrian
>
> On 4/26/2011 12:16 PM, David E Jones wrote:
>> Yes, that's true. That goes back to one of the big difficulties with 
>> something like OFBiz managed in the "Apache way". OFBiz isn't a 
>> project driven by specifications, and so many decisions are made in a 
>> more ad-hoc manner.
>>
>> If we were to step back and make OFBiz spec-driven by actually 
>> writing up requirements and then creating designs (specs) based on 
>> the requirements, and then implementing to those, and testing against 
>> them.
>>
>> That sort of effort could happen right now by collaborating on 
>> documents that represent requirements, and then on documents that 
>> represent designs. Those would be separate from the project for 
>> (probably) quite a while, so wouldn't interfere with current happenings.
>>
>> -David
>>
>>
>> On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
>>
>>> I agree with you on the unnecessary complication of common or shared 
>>> artifacts. I have been ranting for years about the Global Decorator 
>>> being filled with a lot of things that don't belong there, but 
>>> nothing changes - people keep dumping more stuff in there. So the 
>>> problem is caused by more than a lack of discussion in the design 
>>> phase, it's also caused by a lack of care after the design.
>>>
>>> -Adrian
>>>
>>> On 4/26/2011 9:52 AM, David E Jones wrote:
>>>> And yes, not every idea is a good one and many things really don't 
>>>> belong in the framework. Putting things in themes instead of the 
>>>> framework is a good idea for many things. And on the topic of 
>>>> themes, it would be nice (and reduce the incredible amount of 
>>>> redundancy in themes) if the themes were limited to visual 
>>>> artifacts such as images and style sheets, instead of also 
>>>> including various templates. Take these hugely redundant theme 
>>>> templates (especially for header) and combine that with the 
>>>> practice of parameterizing every little thing... and you have an 
>>>> error-prone tangle that makes customization difficult and 
>>>> discourages innovation and improvement in the project.
>>>>
>>>> Sorry for the rant, but this kind of thing has been going on for a 
>>>> long time and is another reason why I still maintain that the ONLY 
>>>> way OFBiz will ever have a clean framework separation, and even a 
>>>> clean framework, is if it is a separate project maintained by a 
>>>> different group of people than maintains the more business-oriented 
>>>> functionality of OFBiz.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>>>>
>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>> 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
>>>>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>


-- 
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: Free Market versus Central Planning (was Re: New Icons)

[Adrian Crum <ad...@sandglass-software.com>]

Thank you for the clarification, and I apologize for my misrepresentation.

-Adrian

On 4/29/2011 10:00 AM, David E Jones wrote:
> On Apr 26, 2011, at 12:31 PM, Adrian Crum wrote:
>
>> I like the idea of working with the current community to get a consensus on these things and then loosely enforcing them. I keep holding out hope that the desire to produce a quality product will increase.
>>
>> I understand your viewpoint of just starting over with new code and new community members. At first glance that seems attractive. But it seems to me that's like curing cancer by executing the patient.
> No, I don't think you do understand it. The last time you represented "my" viewpoint this way I responded with how what you described was different. I'll do it again here.
>
> My goal is not to get rid of the community, my goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>
> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>
> -David
>

Re: Free Market versus Central Planning (was Re: New Icons)

[David E Jones <de...@me.com>]

It's interesting that you wrote this Ruth. I heard the same thing from a client recently, ie that they hadn't heard my name until after using OFBiz in their company for a couple of years.

After that comment (a couple of weeks ago) I thought about it a bit and in a way I'd like to think this is success on my part in trying to build the community by not emphasizing my role, which was a priority for me for a while... now I guess I don't care so much and I don't know that weakening my role really ever did anything to help grow the community. I always thought it would give others more opportunities to take on major roles in the project, but who knows...

More realistically, I think this is a factor of how the ASF works combined with the long history of OFBiz. The ASF doesn't really allow (and definitely doesn't encourage) prominently recognizing individuals, especially individuals with commercial concerns (I suppose it is more virtuous to use money from students or from grants (ie money taken non-voluntarily from unfortunate "citizens") than the try to operate a commercial concern based on open source or free software). Because of ASF policy you have to look pretty hard to even figure out who the committers and PMC members are, and people who just watch the mailing list or use the software rarely know who is in these groups.

The long history of OFBiz also makes this tricky. Many of those who contributed a lot early on in the build-out of the project (especially over the first 7-8 years, and even more in the first 5-6 years) are not as active on the mailing lists and in commits right now (and over the last couple of years). That's just the nature of the project, and will probably become even more that way over time, especially combined with the ASF policy factor I mentioned above.

On the topic of the ASF, the policies I also find increasingly distasteful. The foundation is growing, which is good, but along with that growth the sheer volume of policies has mushroomed, to the point (IMO) of making it a less interesting means to distribute ones free/open software efforts. It's still a great foundation, but if it isn't as attractive to developers, and the more they add policies that make things difficult or unattractive to developers, how long will that last?

-David


On May 3, 2011, at 9:20 AM, Ruth Hoffman wrote:

> How true.
> But, I would suggest that in this case, the phenomena that I described has nothing to do with reality and everything to do with ignorance.
> Best Regards,
> Ruth
> 
> On 5/3/11 10:28 AM, Jacopo Cappellato wrote:
>> On May 3, 2011, at 3:39 PM, Ruth Hoffman wrote:
>> 
>>> FYI:  You wrote: "It's not as if I'm an outsider taking pot-shots..." You would be surprised, as I was, at the number of people using OFBiz who do not know who you are or about your association with the project. I've met many over the last few years. Therefore, in my experience, to many people, with OFBiz interests, you are an "outsider".
>> The fact that people ignore reality, doesn't make it less real.
>> 
>> Jacopo
>> 
>> 

Re: Free Market versus Central Planning (was Re: New Icons)

[Ruth Hoffman <rh...@aesolves.com>]

How true.
But, I would suggest that in this case, the phenomena that I described 
has nothing to do with reality and everything to do with ignorance.
Best Regards,
Ruth

On 5/3/11 10:28 AM, Jacopo Cappellato wrote:
> On May 3, 2011, at 3:39 PM, Ruth Hoffman wrote:
>
>> FYI:  You wrote: "It's not as if I'm an outsider taking pot-shots..." You would be surprised, as I was, at the number of people using OFBiz who do not know who you are or about your association with the project. I've met many over the last few years. Therefore, in my experience, to many people, with OFBiz interests, you are an "outsider".
> The fact that people ignore reality, doesn't make it less real.
>
> Jacopo
>
>

Re: Free Market versus Central Planning (was Re: New Icons)

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

On May 3, 2011, at 3:39 PM, Ruth Hoffman wrote:

> FYI:  You wrote: "It's not as if I'm an outsider taking pot-shots..." You would be surprised, as I was, at the number of people using OFBiz who do not know who you are or about your association with the project. I've met many over the last few years. Therefore, in my experience, to many people, with OFBiz interests, you are an "outsider".

The fact that people ignore reality, doesn't make it less real.

Jacopo

Re: Free Market versus Central Planning (was Re: New Icons)

[Ruth Hoffman <rh...@aesolves.com>]

David:
This is the first time I think I've seen you write something positive 
about OFBiz: "I also think OFBiz is great". A step in the right 
direction! Thank you for stating that.

I understand completely your motivation and I'm empathetic to your 
position. I'm only asking that you don't bash OFBiz at the expense of 
any other project. If your latest endeavor is the answer to all your 
ills (and OFBiz's), then by all means pursue it with all the passion and 
commitment that you have.

FYI:  You wrote: "It's not as if I'm an outsider taking pot-shots..." 
You would be surprised, as I was, at the number of people using OFBiz 
who do not know who you are or about your association with the project. 
I've met many over the last few years. Therefore, in my experience, to 
many people, with OFBiz interests, you are an "outsider".

Best Regards,
Ruth

On 5/3/11 9:05 AM, Tim Ruppert wrote:
> Well said David.  I think that the investment you made to OFBiz pre-Moqui was astounding, but what you've created in Moqui has the chance to save the project and keep it going for the _next_ 10 years.  Thank you for being proactive enough and caring enough to get out in front of the community even when at times it's not able to see that a change is needed.
>
> My two cents.
>
> Cheers,
> Ruppert
>
> On May 2, 2011, at 10:22 PM, David E Jones wrote:
>
>> Ruth,
>>
>> It's not as if I'm an outsider taking pot-shots at something from a distance. I also think OFBiz is great, but after working with it for a decade I'm confident I can do better, and I can confidently say the same about many in the OFBiz community. We can do better, and what's more: we want to.
>>
>> Maybe you're not familiar with the pattern of my comments, it is the pattern of retrospection and introspection and open communication about a creation and a long-term effort. It's what happens when someone has so thoroughly explored and experienced and tried to improve something that clear patterns of success and failure have emerged.
>>
>> Consider my efforts on Moqui and related projects to be my attempt at atonement for the many sins laid at my feet over my years with OFBiz that now fetter my soul and make further progress difficult.
>>
>> If you've never experienced anything of the sort, I challenge you to stretch yourself and work to create something great. Take on something that is so beyond you that you can't see the other side, and keep pushing for it after having to give up and start over a time or two. Then you'll understand.
>>
>> -David
>>
>>
>> On May 2, 2011, at 7:26 PM, Ruth Hoffman wrote:
>>
>>> On 5/2/11 9:23 PM, Scott Gray wrote:
>>>> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>>>>
>>>>> List:
>>>>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
>>>> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>>>>
>>> IMO, it is one thing to talk about replacing the framework. It is quite another to continually harp on what is wrong with OFBiz.
>>>>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
>>>> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
>>> Really? What, in your esteemed opinion is wrong? With OFBiz that is. And not me. (I already know that latter.)
>>>>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>>>>
>>>>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
>>>> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>>>>
>>> Well, if your aim is to destroy OFBiz in favor of Moqui or any other "the grass is always greener" solution, then by all means bash away and encourage David and everyone to join the fray.
>>>>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>>>>
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>> On 5/2/11 7:46 PM, David E Jones wrote:
>>>>>> In fact, we have a garden now... it's just looking for gardeners.
>>>>>>
>>>>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>>>>
>>>>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>>>>
>>>>>> If you create something great, let me know and I'll list it here:
>>>>>>
>>>>>> http://www.moqui.org/crust.html
>>>>>>
>>>>>> Maybe even Apache OFBiz will be there at some point.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>>>>
>>>>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>>>>
>>>>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>>>>
>>>>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>>>>
>>>>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>

Re: Free Market versus Central Planning (was Re: New Icons)

[Tim Ruppert <ti...@hotwaxmedia.com>]

Well said David.  I think that the investment you made to OFBiz pre-Moqui was astounding, but what you've created in Moqui has the chance to save the project and keep it going for the _next_ 10 years.  Thank you for being proactive enough and caring enough to get out in front of the community even when at times it's not able to see that a change is needed.

My two cents.

Cheers,
Ruppert

On May 2, 2011, at 10:22 PM, David E Jones wrote:

> 
> Ruth,
> 
> It's not as if I'm an outsider taking pot-shots at something from a distance. I also think OFBiz is great, but after working with it for a decade I'm confident I can do better, and I can confidently say the same about many in the OFBiz community. We can do better, and what's more: we want to.
> 
> Maybe you're not familiar with the pattern of my comments, it is the pattern of retrospection and introspection and open communication about a creation and a long-term effort. It's what happens when someone has so thoroughly explored and experienced and tried to improve something that clear patterns of success and failure have emerged.
> 
> Consider my efforts on Moqui and related projects to be my attempt at atonement for the many sins laid at my feet over my years with OFBiz that now fetter my soul and make further progress difficult.
> 
> If you've never experienced anything of the sort, I challenge you to stretch yourself and work to create something great. Take on something that is so beyond you that you can't see the other side, and keep pushing for it after having to give up and start over a time or two. Then you'll understand.
> 
> -David
> 
> 
> On May 2, 2011, at 7:26 PM, Ruth Hoffman wrote:
> 
>> 
>> On 5/2/11 9:23 PM, Scott Gray wrote:
>>> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>>> 
>>>> List:
>>>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
>>> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>>> 
>> IMO, it is one thing to talk about replacing the framework. It is quite another to continually harp on what is wrong with OFBiz.
>>>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
>>> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
>> Really? What, in your esteemed opinion is wrong? With OFBiz that is. And not me. (I already know that latter.)
>>>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>>> 
>>>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
>>> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>>> 
>> Well, if your aim is to destroy OFBiz in favor of Moqui or any other "the grass is always greener" solution, then by all means bash away and encourage David and everyone to join the fray.
>>>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>>> 
>>>> Regards,
>>>> Ruth
>>>> 
>>>> On 5/2/11 7:46 PM, David E Jones wrote:
>>>>> In fact, we have a garden now... it's just looking for gardeners.
>>>>> 
>>>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>>> 
>>>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>>> 
>>>>> If you create something great, let me know and I'll list it here:
>>>>> 
>>>>> http://www.moqui.org/crust.html
>>>>> 
>>>>> Maybe even Apache OFBiz will be there at some point.
>>>>> 
>>>>> -David
>>>>> 
>>>>> 
>>>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>>> 
>>>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>>> 
>>>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>>> 
>>>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>>> 
>>>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>>> 
>>>>>>> -David
>>>>>>> 
> 

Re: Free Market versus Central Planning (was Re: New Icons)

[David E Jones <de...@me.com>]

Ruth,

It's not as if I'm an outsider taking pot-shots at something from a distance. I also think OFBiz is great, but after working with it for a decade I'm confident I can do better, and I can confidently say the same about many in the OFBiz community. We can do better, and what's more: we want to.

Maybe you're not familiar with the pattern of my comments, it is the pattern of retrospection and introspection and open communication about a creation and a long-term effort. It's what happens when someone has so thoroughly explored and experienced and tried to improve something that clear patterns of success and failure have emerged.

Consider my efforts on Moqui and related projects to be my attempt at atonement for the many sins laid at my feet over my years with OFBiz that now fetter my soul and make further progress difficult.

If you've never experienced anything of the sort, I challenge you to stretch yourself and work to create something great. Take on something that is so beyond you that you can't see the other side, and keep pushing for it after having to give up and start over a time or two. Then you'll understand.

-David


On May 2, 2011, at 7:26 PM, Ruth Hoffman wrote:

> 
> On 5/2/11 9:23 PM, Scott Gray wrote:
>> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>> 
>>> List:
>>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
>> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>> 
> IMO, it is one thing to talk about replacing the framework. It is quite another to continually harp on what is wrong with OFBiz.
>>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
>> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
> Really? What, in your esteemed opinion is wrong? With OFBiz that is. And not me. (I already know that latter.)
>>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>> 
>>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
>> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>> 
> Well, if your aim is to destroy OFBiz in favor of Moqui or any other "the grass is always greener" solution, then by all means bash away and encourage David and everyone to join the fray.
>>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>> 
>>> Regards,
>>> Ruth
>>> 
>>> On 5/2/11 7:46 PM, David E Jones wrote:
>>>> In fact, we have a garden now... it's just looking for gardeners.
>>>> 
>>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>> 
>>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>> 
>>>> If you create something great, let me know and I'll list it here:
>>>> 
>>>> http://www.moqui.org/crust.html
>>>> 
>>>> Maybe even Apache OFBiz will be there at some point.
>>>> 
>>>> -David
>>>> 
>>>> 
>>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>> 
>>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>> 
>>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>> 
>>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>> 
>>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>> 
>>>>>> -David
>>>>>> 

Re: Free Market versus Central Planning (was Re: New Icons)

[Scott Gray <sc...@hotwaxmedia.com>]

On 3/05/2011, at 2:26 PM, Ruth Hoffman wrote:

> On 5/2/11 9:23 PM, Scott Gray wrote:
>> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>> 
>>> List:
>>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
>> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>> 
> IMO, it is one thing to talk about replacing the framework. It is quite another to continually harp on what is wrong with OFBiz.
>>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
>> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
> 
> Really? What, in your esteemed opinion is wrong? With OFBiz that is. And not me. (I already know that latter.)

Providing an answer to that would require more time than I willing to give you and I've already spent enough time articulating my concerns over the past year so I'm not going to do that again now. You've obviously read plenty of criticism or you wouldn't have written this message so just know that I share most if not all of David's concerns.

>>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>> 
>>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
>> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>> 
> Well, if your aim is to destroy OFBiz in favor of Moqui or any other "the grass is always greener" solution, then by all means bash away and encourage David and everyone to join the fray.

This is what I mean by your tendency to spread FUD, no one is trying to destroy OFBiz and the reality is quite the opposite.

>>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>> 
>>> Regards,
>>> Ruth
>>> 
>>> On 5/2/11 7:46 PM, David E Jones wrote:
>>>> In fact, we have a garden now... it's just looking for gardeners.
>>>> 
>>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>> 
>>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>> 
>>>> If you create something great, let me know and I'll list it here:
>>>> 
>>>> http://www.moqui.org/crust.html
>>>> 
>>>> Maybe even Apache OFBiz will be there at some point.
>>>> 
>>>> -David
>>>> 
>>>> 
>>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>> 
>>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>> 
>>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>> 
>>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>> 
>>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>> 
>>>>>> -David
>>>>>> 

Re: Free Market versus Central Planning (was Re: New Icons)

[Ruth Hoffman <rh...@aesolves.com>]

On 5/2/11 9:23 PM, Scott Gray wrote:
> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>
>> List:
>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>
IMO, it is one thing to talk about replacing the framework. It is quite 
another to continually harp on what is wrong with OFBiz.
>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
Really? What, in your esteemed opinion is wrong? With OFBiz that is. And 
not me. (I already know that latter.)
>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>
>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>
Well, if your aim is to destroy OFBiz in favor of Moqui or any other 
"the grass is always greener" solution, then by all means bash away and 
encourage David and everyone to join the fray.
>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>
>> Regards,
>> Ruth
>>
>> On 5/2/11 7:46 PM, David E Jones wrote:
>>> In fact, we have a garden now... it's just looking for gardeners.
>>>
>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>
>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>
>>> If you create something great, let me know and I'll list it here:
>>>
>>> http://www.moqui.org/crust.html
>>>
>>> Maybe even Apache OFBiz will be there at some point.
>>>
>>> -David
>>>
>>>
>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>
>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>
>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>
>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>
>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>
>>>>> -David
>>>>>

Re: Free Market versus Central Planning (was Re: New Icons)

[Scott Gray <sc...@hotwaxmedia.com>]

On 3/05/2011, at 1:48 PM, Adrian Crum wrote:

> I agree with Scott, but at the same time I agree with Ruth a little.

> David started off promoting Moqui by bashing on the OFBiz developer community and the product.

But to be fair, he was doing that before he got Moqui under way as well and that discontent is possibly (probably?) what drove him to create Moqui rather than being criticism for marketing purposes.

> But he's toned that down now, so I think a discussion about using it in the OFBiz project is appropriate.
> 
> -Adrian
> 
> On 5/2/2011 6:23 PM, Scott Gray wrote:
>> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>> 
>>> List:
>>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
>> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>> 
>>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
>> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
>> 
>>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>> 
>>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
>> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>> 
>>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>> 
>>> Regards,
>>> Ruth
>>> 
>>> On 5/2/11 7:46 PM, David E Jones wrote:
>>>> In fact, we have a garden now... it's just looking for gardeners.
>>>> 
>>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>> 
>>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>> 
>>>> If you create something great, let me know and I'll list it here:
>>>> 
>>>> http://www.moqui.org/crust.html
>>>> 
>>>> Maybe even Apache OFBiz will be there at some point.
>>>> 
>>>> -David
>>>> 
>>>> 
>>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>> 
>>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>> 
>>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>> 
>>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>> 
>>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>> 
>>>>>> -David
>>>>>> 

Re: Free Market versus Central Planning (was Re: New Icons)

[Adrian Crum <ad...@sandglass-software.com>]

I agree with Scott, but at the same time I agree with Ruth a little. 
David started off promoting Moqui by bashing on the OFBiz developer 
community and the product. But he's toned that down now, so I think a 
discussion about using it in the OFBiz project is appropriate.

-Adrian

On 5/2/2011 6:23 PM, Scott Gray wrote:
> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>
>> List:
>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>
>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
>
>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>
>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>
>> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
>>
>> Regards,
>> Ruth
>>
>> On 5/2/11 7:46 PM, David E Jones wrote:
>>> In fact, we have a garden now... it's just looking for gardeners.
>>>
>>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>>>
>>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>>>
>>> If you create something great, let me know and I'll list it here:
>>>
>>> http://www.moqui.org/crust.html
>>>
>>> Maybe even Apache OFBiz will be there at some point.
>>>
>>> -David
>>>
>>>
>>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>>>
>>>> That's great, David. Glad to know we'll have a garden soon.
>>>>
>>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>>>
>>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>>>
>>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>>>
>>>>> -David
>>>>>

Re: Free Market versus Central Planning (was Re: New Icons)

[Scott Gray <sc...@hotwaxmedia.com>]

On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:

> List:
> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?

The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.

> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.

That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.

> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
> 
> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.

Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.

> BTW, anyone wanting to help me make MyOFBiz.com a better resource for the OFBiz community, please feel free to contact me at ruth.hoffman@myofbiz.com
> 
> Regards,
> Ruth
> 
> On 5/2/11 7:46 PM, David E Jones wrote:
>> In fact, we have a garden now... it's just looking for gardeners.
>> 
>> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>> 
>> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>> 
>> If you create something great, let me know and I'll list it here:
>> 
>> http://www.moqui.org/crust.html
>> 
>> Maybe even Apache OFBiz will be there at some point.
>> 
>> -David
>> 
>> 
>> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>> 
>>> That's great, David. Glad to know we'll have a garden soon.
>>> 
>>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>> 
>>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>> 
>>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>> 
>>>> -David
>>>> 
>>> 
>> 

Re: Free Market versus Central Planning (was Re: New Icons)

[Ruth Hoffman <rh...@aesolves.com>]

List:
Why is it that David is allowed to advertise continuously about his 
latest pet project - that has nothing to do with OFBiz - on this mailing 
list and others, such as myself can't even mention a resource dedicated 
entirely to OFBiz, that many have found useful, (MyOFBiz.com 
http://www.myofbiz.com) without risk of severe rebuke?

Of course that was a rhetorical question. I know the answer. But I will 
say this: As an outsider, what I see going on here is seriously 
wrong...The constant innuendo that there is something amiss with OFBiz 
undermines the public's faith in the quality and value proposition of 
this project. Despite all the differences of all the OFBiz community 
members, OFBiz still remains the best open source - possibly any source 
- ERP around. Lets not forget that.

Although I have no authority to request this I'm asking that David 
please stop using this list as his "dumping" ground. David, if you do 
not have positive OFBiz commentary, please don't post.

BTW, anyone wanting to help me make MyOFBiz.com a better resource for 
the OFBiz community, please feel free to contact me at 
ruth.hoffman@myofbiz.com

Regards,
Ruth

On 5/2/11 7:46 PM, David E Jones wrote:
> In fact, we have a garden now... it's just looking for gardeners.
>
> Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).
>
> In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.
>
> If you create something great, let me know and I'll list it here:
>
> http://www.moqui.org/crust.html
>
> Maybe even Apache OFBiz will be there at some point.
>
> -David
>
>
> On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:
>
>> That's great, David. Glad to know we'll have a garden soon.
>>
>> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
>>
>>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>>>
>>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>>>
>>> -David
>>>
>>
>

Re: Free Market versus Central Planning (was Re: New Icons)

[David E Jones <de...@me.com>]

In fact, we have a garden now... it's just looking for gardeners.

Moqui Framework 1.0 is feature-complete and in beta. The Mantle data model (UDM) is in an initially complete state (except for seed data which I'm still working on), and is at a point where feedback is the most important next step (with various improvements to it already planned as well).

In any case, framework add-ons and applications are welcome, and I've even solicited creation of such things in order to help test the framework and give people opportunities to experience the framework and give feedback.

If you create something great, let me know and I'll list it here:

http://www.moqui.org/crust.html

Maybe even Apache OFBiz will be there at some point.

-David


On May 2, 2011, at 9:34 AM, Shi Jinghai wrote:

> That's great, David. Glad to know we'll have a garden soon.
> 
> On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:
> 
>> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
>> 
>> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
>> 
>> -David
>> 
> 
> 

Re: Free Market versus Central Planning (was Re: New Icons)

[Shi Jinghai <sh...@langhua.org>]

That's great, David. Glad to know we'll have a garden soon.

On Fri, 2011-04-29 at 10:00 -0700, David E Jones wrote:

> My goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.
> 
> A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.
> 
> -David
> 

Free Market versus Central Planning (was Re: New Icons)

[David E Jones <de...@me.com>]

On Apr 26, 2011, at 12:31 PM, Adrian Crum wrote:

> I like the idea of working with the current community to get a consensus on these things and then loosely enforcing them. I keep holding out hope that the desire to produce a quality product will increase.
> 
> I understand your viewpoint of just starting over with new code and new community members. At first glance that seems attractive. But it seems to me that's like curing cancer by executing the patient.

No, I don't think you do understand it. The last time you represented "my" viewpoint this way I responded with how what you described was different. I'll do it again here.

My goal is not to get rid of the community, my goal is to split the community to various sub-communities involved in different projects which make up an ecosystem of projects based on the same framework and data model, as opposed to a single project for everything. This will reduce conflict and encourage people to try different ideas with end-users in the position to choose between them based on what works best for them.

A distributed community, as opposed to a centralized community, would allow many more people to get involved with much less conflict than our current rather small community. The point is not to exclude people or get rid of a community, the point is to enable more people to get involved and move it more towards a "free market" structure as opposed to the current "central planning" type of structure that OFBiz operates under.

-David

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

I agree. One of the things I've tried to do to help that along is by 
writing the Best Practices on the Wiki site. But a more design-oriented 
approach would help too. From my perspective, the Best Practices 
basically say "you should do it this way", and in the design-oriented 
pages you can learn more about WHY you should do it that way.

I like the idea of working with the current community to get a consensus 
on these things and then loosely enforcing them. I keep holding out hope 
that the desire to produce a quality product will increase.

I understand your viewpoint of just starting over with new code and new 
community members. At first glance that seems attractive. But it seems 
to me that's like curing cancer by executing the patient.

-Adrian

On 4/26/2011 12:16 PM, David E Jones wrote:
> Yes, that's true. That goes back to one of the big difficulties with something like OFBiz managed in the "Apache way". OFBiz isn't a project driven by specifications, and so many decisions are made in a more ad-hoc manner.
>
> If we were to step back and make OFBiz spec-driven by actually writing up requirements and then creating designs (specs) based on the requirements, and then implementing to those, and testing against them.
>
> That sort of effort could happen right now by collaborating on documents that represent requirements, and then on documents that represent designs. Those would be separate from the project for (probably) quite a while, so wouldn't interfere with current happenings.
>
> -David
>
>
> On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
>
>> I agree with you on the unnecessary complication of common or shared artifacts. I have been ranting for years about the Global Decorator being filled with a lot of things that don't belong there, but nothing changes - people keep dumping more stuff in there. So the problem is caused by more than a lack of discussion in the design phase, it's also caused by a lack of care after the design.
>>
>> -Adrian
>>
>> On 4/26/2011 9:52 AM, David E Jones wrote:
>>> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project.
>>>
>>> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.
>>>
>>> -David
>>>
>>>
>>>
>>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>>>
>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>> 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
>>>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

Re: New Icons

[David E Jones <de...@me.com>]

Yes, that's true. That goes back to one of the big difficulties with something like OFBiz managed in the "Apache way". OFBiz isn't a project driven by specifications, and so many decisions are made in a more ad-hoc manner.

If we were to step back and make OFBiz spec-driven by actually writing up requirements and then creating designs (specs) based on the requirements, and then implementing to those, and testing against them.

That sort of effort could happen right now by collaborating on documents that represent requirements, and then on documents that represent designs. Those would be separate from the project for (probably) quite a while, so wouldn't interfere with current happenings.

-David


On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:

> I agree with you on the unnecessary complication of common or shared artifacts. I have been ranting for years about the Global Decorator being filled with a lot of things that don't belong there, but nothing changes - people keep dumping more stuff in there. So the problem is caused by more than a lack of discussion in the design phase, it's also caused by a lack of care after the design.
> 
> -Adrian
> 
> On 4/26/2011 9:52 AM, David E Jones wrote:
>> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project.
>> 
>> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.
>> 
>> -David
>> 
>> 
>> 
>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>> 
>>> 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"<ad...@sandglass-software.com>
>>>>>>>> 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
>>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

I agree with you on the unnecessary complication of common or shared 
artifacts. I have been ranting for years about the Global Decorator 
being filled with a lot of things that don't belong there, but nothing 
changes - people keep dumping more stuff in there. So the problem is 
caused by more than a lack of discussion in the design phase, it's also 
caused by a lack of care after the design.

-Adrian

On 4/26/2011 9:52 AM, David E Jones wrote:
> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project.
>
> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.
>
> -David
>
>
>
> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>
>> 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"<ad...@sandglass-software.com>
>>>>>>> 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
>>>>>>>>> contact@ryanlfoster.com
>>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>

Re: New Icons

[David E Jones <de...@me.com>]

Thanks Scott, I agree. We need to use flexible and generic tools like CSS more, and stop creating so many nightmares of parameterization. It seems like over the last few years every new general feature has been handled not by design and considering the best generic solution, or by looking at where the framework can be extended or changed to handle something better (while keeping things like visual elements separated from business and technical elements, ie the form widget ideally shouldn't have ANY styling in it and even layout is separated from the base field definitions). It seems like all of the new features are handled by parameterizing the heck out of default templates and creating decorator screens and all sorts of inconsistent "conventions".

This maybe goes back to the the discussion in the "hiding functionality in ofbiz." thread. It's pretty clear that a big problem is near zero collaboration on design. I know that's difficult with a larger group, and that when the active group of developers in OFBiz was smaller we were _constantly_ discussing new feature ideas and making dramatic changes to initial ideas through those discussions. That started with the early days when Andrew and I spent hours on the phone discussing things, so much so that we changed cell phone carriers so we could use the unlimited mobile to mobile minutes on the same carrier. That continued with the various people who got involved early on too, sometimes with phone calls and often with long discussions on the mailing lists.

It's definitely the case that not every little thing was discussed, and many things were discussed after a commit (which was often used to facilitate communication and solicit feedback since the contributor and user communities were both much smaller). These days there seems to be almost no discussion, and even very few requests for feedback... and understandably so as many of the requests for feedback result in very non-productive mudslinging.

And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project.

Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.

-David



On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:

> 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" <ad...@sandglass-software.com>
>>>>>> 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
>>>>>>>> contact@ryanlfoster.com
>>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>>> 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
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 

Re: New Icons

[Scott Gray <sc...@hotwaxmedia.com>]

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" <ad...@sandglass-software.com>
>>>>> 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
>>>>>>> contact@ryanlfoster.com
>>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

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" <ad...@sandglass-software.com>
>>>> 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
>>>>>> contact@ryanlfoster.com
>>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: New Icons

[Nicolas Malin <ma...@librenberry.net>]

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" <ad...@sandglass-software.com>
>>> 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
>>>>> contact@ryanlfoster.com
>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>>


-- 
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: New Icons

[Jacques Le Roux <ja...@les7arts.com>]

Still limited to "all icons or none". I feel that we could do a flexible way (allow icons or not in buttons and menus of choice) 
also with CSS rules but it would be far less easier than having it controlled by field/entry.
Also note we had already image-location attribute for submit button element, Nicolas just enhanced it.

Jacques

From: "Adrian Crum" <ad...@sandglass-software.com>
> 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" <ad...@sandglass-software.com>
>>> 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
>>>>> contact@ryanlfoster.com
>>>>> 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"<ad...@sandglass-software.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>> 

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

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" <ad...@sandglass-software.com>
>> 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
>>>> contact@ryanlfoster.com
>>>> 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"<ad...@sandglass-software.com>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>
>

Re: New Icons

[Jacques Le Roux <ja...@les7arts.com>]

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" <ad...@sandglass-software.com>
> 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
>>> contact@ryanlfoster.com
>>> 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"<ad...@sandglass-software.com>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

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
>> contact@ryanlfoster.com
>> 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"<ad...@sandglass-software.com>
>>>>> 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
>>>>>
>>>>>
>>>>
>>
>
>

Re: New Icons

[Jacques Le Roux <ja...@les7arts.com>]

I like the idea +1
1st step committed at r1096457
FYI: related to https://issues.apache.org/jira/browse/OFBIZ-4259

Jacques

From: "Nicolas Malin" <ma...@librenberry.net>
> 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
>> contact@ryanlfoster.com
>> 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"<ad...@sandglass-software.com>
>>>>> 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
>>>>>
>>>>>
>>>>
>>
>
>
> -- 
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>

Re: New Icons

[Nicolas Malin <ma...@librenberry.net>]

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
> contact@ryanlfoster.com
> 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"<ad...@sandglass-software.com>
>>>> 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
>>>>
>>>>
>>>
>


-- 
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/

Re: New Icons

[Ryan Foster <co...@ryanlfoster.com>]

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
contact@ryanlfoster.com
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" <ad...@sandglass-software.com>
>>> 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
>>> 
>>> 
>> 
>> 

Re: New Icons

[Adrian Crum <ad...@sandglass-software.com>]

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" <ad...@sandglass-software.com>
>> 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
>>
>>
>
>

Re: New Icons

[Jacques Le Roux <ja...@les7arts.com>]

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" <ad...@sandglass-software.com>
>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
>
>