New Icons

[Adrian Crum-3]

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

[Jacques Le Roux]

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" <[hidden email]>
>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
>
>

[Adrian Crum-3]

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" <[hidden email]>
>> 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
>>
>>
>
>

[Ryan Foster-3]

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
[hidden email]
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" <[hidden email]>
>>> 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
>>>
>>>
>>
>>

[Malin Nicolas]

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
> [hidden email]
> 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"<[hidden email]>
>>>> 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 : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Jacques Le Roux]

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" <[hidden email]>

> 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
>> [hidden email]
>> 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"<[hidden email]>
>>>>> 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 : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/
>

[Adrian Crum-3]

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
>> [hidden email]
>> 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"<[hidden email]>
>>>>> 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
>>>>>
>>>>>
>>>>
>>
>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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
>>> [hidden email]
>>> 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"<[hidden email]>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>

[Adrian Crum-3]

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" <[hidden email]>
>> 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
>>>> [hidden email]
>>>> 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"<[hidden email]>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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" <[hidden email]>
>>> 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
>>>>> [hidden email]
>>>>> 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"<[hidden email]>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>>

[Malin Nicolas]

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" <[hidden email]>
>>> 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
>>>>> [hidden email]
>>>>> 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"<[hidden email]>
>>>>>>>> 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 : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

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" <[hidden email]>
>>>> 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
>>>>>> [hidden email]
>>>>>> 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"<[hidden email]>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[Scott Gray-2]

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" <[hidden email]>
>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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"<[hidden email]>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

[David E. Jones-2]

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" <[hidden email]>
>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>

[Jacques Le Roux]

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" <[hidden email]>

>
> 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" <[hidden email]>
>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>
>

[Adrian Crum-3]

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"<[hidden email]>
>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>

[David E. Jones-2]

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"<[hidden email]>
>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>

[Adrian Crum-3]

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"<[hidden email]>
>>>>>>>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

[Malin Nicolas]

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"<[hidden email]>
>>>>>>>>>> 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
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>>>>>> 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 : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Adrian Crum-3]

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"<[hidden email]>
>>>>>>>>>>> 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
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> 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"<[hidden email]>
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>
>