New Icons

[Ryan Foster-3]

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

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

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

Ryan L. Foster
801.671.0769
[hidden email]
ryanlfoster.com

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

> To understand our differences a little better, it might help to set aside the subject of icons for a moment and consider another visual element - the HTML <table> element. I believe the way HTML tables are handled in OFBiz represents a good balance between developers and theme designers. If we can agree on how tables are handled, then maybe we can apply the same concept to icons and agree on those too. If we can't agree on how tables are handled, then... well... we will just have to agree to disagree. ;-)
>
> OFbiz provides a CSS class for basic <table> element layout - called basic-table. That class provides simple positioning and spacing. The basic-table class is intended to be "decorated" with other classes to add other visual embellishments. A developer can add light-grid or dark-grid CSS classes to basic-table to give it a grid. A developer can add a hover bar to a table by adding the hover-bar CSS class to basic-table. This CSS class decorator pattern has been in use for a while now, and it seems to be a good approach because it gets used a lot.
>
> The developer is free to choose which classes make the most sense for the screen they are developing. What the developer CAN'T do is specify what those classes look like - that is left up to the theme designer. The CSS classes are a way for the developer to give the theme designer hints about what a particular HTML element should look like without being specific about its visual appearance.
>
> The theme designer controls the positioning and spacing in basic-table. The theme designer controls the color and line thickness of light-grid and dark-grid. The theme designer controls the appearance of hover-bar. Different themes might style those classes differently, but what remains consistent across themes is that they are all used in the same way. An HTML <table> element styled with "basic-table light-grid" will always have a light grid - regardless of the theme. Now, here is something interesting to think about - a theme designer could choose not to style the grids, and eliminate table grids altogether. There is no "law" saying that all CSS classes must be styled. A theme that eliminates grids may or may not get used - it depends on the user. Some users might prefer to have grids turned off - so they would select the "gridless" theme. ***This is where the balance between developer and theme designer comes in*** - the developer provides a hint that a table should have grids, but the developer doesn't force grids on the theme designer or the user.
>
> Now let's apply the icon conversation to the HTML <table> element example. What has been suggested is that all themes be made consistent by hard-coding table grids in the markup. When I objected to that, it was suggested that table grids can be enabled/disabled by a user setting. For the sake of compromise I agreed to that, but I believe it is unnecessary because a user could simply choose a theme that has grids enabled or disabled.
>
> To summarize: What I am advocating is that we treat icons the same way as we do all other visual elements - let the theme designer have control of their use. I see no valid reason why icons should be treated differently. Users who want icons will choose a theme that uses them. Users who don't want icons will choose a theme that doesn't use them. The system we use now is flexible and it works - it doesn't need to be changed.
>
> -Adrian
>
>
> On 4/29/2011 2:20 AM, Nicolas Malin wrote:
>> Thanks all for you comments.
>>
>> The last patch I did was mostly on icons, but was more an attempt to increase the "user experience" by mixing actual icons management and dynamic selection coming the visual theme.
>> Now I understand what is meant, and the directions everyone wants to go to, which are quality and simplicity, and then lead to innovation. I think we should then continue this way.
>> Adrian, you are insisting that theme designers should handle its icons, but I'm more saying that we should normalize icon usages so the developer or the theme designer are the more directed possible and so the layouts are normalized.
>>
>> I'm not sure that only using style attributes is the best way, as this is chaining classes when you want to apply more than one visual style, and this is also widely used in jQuery. This is working when the developer is well advanced in his interface.
>> So I'm telling this would be better to add an objective or goal to a field, and then:
>> * restrain usages by enumeration in the xsd
>> * restrain goals number linked to a field type (button, link, text, ...)
>> * help theme designer by fixing clear goals and style names
>>
>> It would also be possible to add new values if exceptions are coming, but only in this case...
>>
>> On the design side, each theme would have a purpose.css file which will only keep classes in direct relaation with the previous definitions. The designer will then have a clear vision on field usage and what to do for rendering.
>> I can work on a POC, which would come in the images folder, or create a generic theme and then use it as a basis
>>
>> Nicolas
>>
>> Le 26/04/2011 21:31, Adrian Crum a écrit :
>>> I agree. One of the things I've tried to do to help that along is by writing the Best Practices on the Wiki site. But a more design-oriented approach would help too. From my perspective, the Best Practices basically say "you should do it this way", and in the design-oriented pages you can learn more about WHY you should do it that way.
>>>
>>> I like the idea of working with the current community to get a consensus on these things and then loosely enforcing them. I keep holding out hope that the desire to produce a quality product will increase.
>>>
>>> I understand your viewpoint of just starting over with new code and new community members. At first glance that seems attractive. But it seems to me that's like curing cancer by executing the patient.
>>>
>>> -Adrian
>>>
>>> On 4/26/2011 12:16 PM, David E Jones wrote:
>>>> Yes, that's true. That goes back to one of the big difficulties with something like OFBiz managed in the "Apache way". OFBiz isn't a project driven by specifications, and so many decisions are made in a more ad-hoc manner.
>>>>
>>>> If we were to step back and make OFBiz spec-driven by actually writing up requirements and then creating designs (specs) based on the requirements, and then implementing to those, and testing against them.
>>>>
>>>> That sort of effort could happen right now by collaborating on documents that represent requirements, and then on documents that represent designs. Those would be separate from the project for (probably) quite a while, so wouldn't interfere with current happenings.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
>>>>
>>>>> I agree with you on the unnecessary complication of common or shared artifacts. I have been ranting for years about the Global Decorator being filled with a lot of things that don't belong there, but nothing changes - people keep dumping more stuff in there. So the problem is caused by more than a lack of discussion in the design phase, it's also caused by a lack of care after the design.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> On 4/26/2011 9:52 AM, David E Jones wrote:
>>>>>> And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project.
>>>>>>
>>>>>> Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
>>>>>>
>>>>>>> I agree with Adrian, the style element alone already gives more that enough control to theme designers.
>>>>>>>
>>>>>>> Every web developer has (or should have) at least a basic understanding of css and every time we step away from such a standard (like with additional attributes in the widgets) we make OFBiz a little harder to use and maintain, it's plenty hard enough already.  Not every idea is a good idea and not every good idea is really needed.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> HotWax Media
>>>>>>> http://www.hotwaxmedia.com
>>>>>>>
>>>>>>> On 26/04/2011, at 8:37 AM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> Main style sheet:
>>>>>>>>
>>>>>>>> .button-bar ul a.create,.button-bar a.create {
>>>>>>>> padding:6px 10px 6px 10px;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Optional icons style sheet:
>>>>>>>>
>>>>>>>> .button-bar ul a.create,.button-bar a.create {
>>>>>>>> background: url(../images/button_sprite.png) no-repeat 0px 0px;
>>>>>>>> padding:6px 10px 6px 30px;
>>>>>>>> }
>>>>>>>>
>>>>>>>> No changes to markup needed. It is the same thing we do to switch rendering from LTR to RTL.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> On 4/25/2011 1:19 PM, Nicolas Malin wrote:
>>>>>>>>> Your are against me ? My popularity increases :)
>>>>>>>>>
>>>>>>>>> At this time :
>>>>>>>>> Screen definition :
>>>>>>>>> ------------------------
>>>>>>>>> <link target="EditExampleLayer" ...  style="buttontext create"/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Output html render :
>>>>>>>>> ---------------------------
>>>>>>>>> <a class="buttontext create" id="FindExample_LF_1_link" href="javascript:void(0);">Nouvel exemple</a>
>>>>>>>>>
>>>>>>>>> Style theme definition :
>>>>>>>>> ------------------------------
>>>>>>>>> style.css :
>>>>>>>>> .button-bar ul a.create,.button-bar a.create {
>>>>>>>>> background: url(../images/button_sprite.png) no-repeat 0px 0px;
>>>>>>>>> padding:6px 10px 6px 30px;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My proposition, after your first remark :
>>>>>>>>> Screen definition :
>>>>>>>>> ------------------------
>>>>>>>>> <link target="EditExampleLayer" ...  style="buttontext">
>>>>>>>>> <icons name="add">
>>>>>>>>> </link>
>>>>>>>>>
>>>>>>>>> Or
>>>>>>>>> <link target="EditExampleLayer" ...  style="buttontext" icons="add">
>>>>>>>>>
>>>>>>>>> Or
>>>>>>>>> <link target="EditExampleLayer" ...  style="buttontext" purpose="add">
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Output html render :
>>>>>>>>> ---------------------------
>>>>>>>>> <a class="buttontext add" ...>Nouvel exemple</a>
>>>>>>>>>
>>>>>>>>> Style theme definition :
>>>>>>>>> ------------------------------
>>>>>>>>> icons.css :
>>>>>>>>> .button-bar ul a.add,.button-bar a.add {
>>>>>>>>> background: url(../images/button_sprite.png) no-repeat 0px 0px;
>>>>>>>>> padding:6px 10px 6px 30px;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> What's changes ? What is broken? Your are against widgets controlling styling but at this time all icons define by style attribute on elements to be used by theme. I propose more fexibility to explain the element's purpose that will be work by screen renderer and after by theme designer.
>>>>>>>>>
>>>>>>>>> To continue update icons improvement :
>>>>>>>>> <set field="iconsModeViewEnumId from-field="userPreferences.VT_ICONS_MODE_VIEW"/> <!--If User whant to view icons-->
>>>>>>>>> <set field="iconsStyleLocation" from-field="userPreferences.VT_ICONS_" global="true"/><!--If User have preference on icons to use-->
>>>>>>>>> <service service-name="getIconsVisualThemeResources"><!--return the css file to use that contains icons definition-->
>>>>>>>>> <field-map field-name="visualThemeId"/>
>>>>>>>>> <field-map field-name="iconsModeViewEnumId"/>
>>>>>>>>> </service>
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>> Le 25/04/2011 14:25, Adrian Crum a écrit :
>>>>>>>>>> I'm against the idea of widgets controlling styling. Period. I am against Nicolas or any other developer deciding which icons get used and where - that is a decision that should be reserved for theme designers.
>>>>>>>>>>
>>>>>>>>>> To summarize my view:
>>>>>>>>>>
>>>>>>>>>> 1. Icon display and the choice of icons should be left to the theme designer. Therefore, icon references should be kept in stylesheets.
>>>>>>>>>> 2. If a theme designer wants to give the user an option to use icons or not, then the theme's templates can conditionally load a cascading stylesheet that includes icons.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> On 4/25/2011 5:14 AM, Jacques Le Roux wrote:
>>>>>>>>>>> On a second thought, we may use another technology than CSS and still have styles, see for instance in POS: posstyles.xml. So yes,
>>>>>>>>>>> styles add flexibility and independence.
>>>>>>>>>>>
>>>>>>>>>>> At 1st glance, Adrian's proposition sounds better from flexibility POV. But, if I have well understood, is still limited to icons or
>>>>>>>>>>> not in the whole OFBiz (like Google bar) when Nicolas's allows to set it by screens (why not even by form fields or menu entries?)
>>>>>>>>>>>
>>>>>>>>>>> I think this is really an important point in UI and should be discussed by the whole developers community, any other opinions,
>>>>>>>>>>> suggestions?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>> From: "Adrian Crum"<[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]

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

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

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

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

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

-David

[Adrian Crum-3]

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

-Adrian

On 4/29/2011 10:00 AM, David E Jones wrote:

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

[Jacques Le Roux]

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

To summarize my POV:

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

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

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

Jacques

From: "Adrian Crum" <[hidden email]>

> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>
>>

[Jacques Le Roux]

To make my POV more clear on menus (I already spoke about icons buttons)
Pre-existing sets of icons for menus https://addons.mozilla.org/en-us/firefox/addon/cutemenus-crystal-svg/
Choose your own icons https://addons.mozilla.org/fr/firefox/addon/menu-icons-plus/

Also my Windows basic window is literraly clutered of icons (icons buttons bars everywhere I can), I can't put more of them but I
like to have them all handy, just one push can't be faster, we all do that everyday, isn'it? Why not in an ERP?

Jacques

From: "Jacques Le Roux" <[hidden email]>

> As I said before this is all good, but for instance in Firefox no need to choose a theme to be able to remove/put icons buttons in
> the buttons bar. Firefox is only an example, we know there are much more uses of this design.
> Don't get me wrong, I'm not against themes at all. But I wonder if we really need to build specific themes to be able to choose to
> have some buttons or not. Again look like the theme argument is for all icons or none (the possible combinaisons are obviously an
> overkill). It seems to me that we still miss a mechanism to remove/add icons on buttons/menus. In the "hiding functionality in
> ofbiz" discussion in user ML some would prefer to set this with roles. It makes sense but is still not very flexbile: each person
> should be able also to remove/add icons on buttons or menu. For instance I like icons menu addons in Firefox, not only because I
> like images (certainly a rest from my education while young, where you were given good points when you succeded ;o) but also
> because
> it allows me to quicker pick a menu entry than having to search for it (no brainner). But I can understand that some other would
> prefer to have their own icons (sets?) or not have icons at all on some menu/buttons, etc.
>
> To summarize my POV:
>
> * Themes are great to set things in a whole (also developers can chose to apply or not styles to set icons or not in
> custom/customized applications...)
> * Roles are great to set things at the enterprise level
> * A mechanism to allow individuals users to choose their own icons (or sets of icons?) or to not have icons everywhere would be a
> good complement
>
> With current OFBiz state, CSS styles (themes) are the easiest way to achieve the goal, roles still need more work (notably to
> collect the features and group them by roles, then to have those roles set and used in code), while a mechanism. Of course to
> follow
> Adrian idea this could apply not only to icons. But it's the thing which comes instantly in mind. Images are shorcut for words.
> After all, Chinese use them as words. I mean they don't encode their words in letters, a proof that the power of alphabet is not
> the
> only way.
>
> I was a long time user of APL while also working with traditionnal languages (C, Pascal). APL is a symbolic language (was first a
> macro assembler), for instance you have a sole symbol to represent/solve a system of linear equations and you are not encouraged
> to
> use loops. I think you could compare APL vs C/Pascal to Chinese vs Alphabetized languages...Ho sorry almost out of subjet, I'm a
> holidays dreamer :o)
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>
>>>
>

[Shi Jinghai-2]

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

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

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

[David E. Jones-2]

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

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

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

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

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

Maybe even Apache OFBiz will be there at some point.

-David


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

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

[Ruth Hoffman-2]

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

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

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

BTW, anyone wanting to help me make MyOFBiz.com a better resource for
the OFBiz community, please feel free to contact me at
[hidden email]

Regards,
Ruth

On 5/2/11 7:46 PM, David E Jones wrote:

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

[Scott Gray-2]

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

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

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

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

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

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

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

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

[Adrian Crum-3]

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

-Adrian

On 5/2/2011 6:23 PM, Scott Gray wrote:

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

[Scott Gray-2]

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

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

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

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

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

[Ruth Hoffman-2]

On 5/2/11 9:23 PM, Scott Gray wrote:
> On 3/05/2011, at 12:51 PM, Ruth Hoffman wrote:
>
>> List:
>> Why is it that David is allowed to advertise continuously about his latest pet project - that has nothing to do with OFBiz - on this mailing list and others, such as myself can't even mention a resource dedicated entirely to OFBiz, that many have found useful, (MyOFBiz.com http://www.myofbiz.com) without risk of severe rebuke?
> The only time I think I've rebuked you is when you did nothing to engage the conversation and instead just wrote something along the lines of "you'll find the answer to that question at my website!".  I don't think anyone has an issue with the promotion of relevant websites, companies, projects, etc. but I don't personally think it should ever be the primary purpose of sending a message to these lists.  Moqui isn't just a random pet project anyway, it is a potential replacement for the OFBiz framework created by one of the founders of OFBiz, if that's not worthy of discussion I don't know what would be.
>
IMO, it is one thing to talk about replacing the framework. It is quite
another to continually harp on what is wrong with OFBiz.
>> Of course that was a rhetorical question. I know the answer. But I will say this: As an outsider, what I see going on here is seriously wrong...The constant innuendo that there is something amiss with OFBiz undermines the public's faith in the quality and value proposition of this project.
> That seems pretty hypocritical considering you've spent a fair amount of time in the past criticizing the most active members of the community and spreading FUD about the way this project is managed.  But at the end of the day there is something wrong and ignoring that will achieve nothing, this is the dev list and is the most appropriate place to discuss these development related issues.
Really? What, in your esteemed opinion is wrong? With OFBiz that is. And
not me. (I already know that latter.)
>> Despite all the differences of all the OFBiz community members, OFBiz still remains the best open source - possibly any source - ERP around. Lets not forget that.
>>
>> Although I have no authority to request this I'm asking that David please stop using this list as his "dumping" ground. David, if you do not have positive OFBiz commentary, please don't post.
> Nobody has any authority here other than the respect one gains through what the ASF calls a "meritorcracy" (government by merit), and there really can't be any doubt that David has well and truly earned the right to say whatever he damn well pleases (in my opinion).  David's spent more time interacting with this community than anyone else and if he's learnt something from that then I for one want to hear it.
>
Well, if your aim is to destroy OFBiz in favor of Moqui or any other
"the grass is always greener" solution, then by all means bash away and
encourage David and everyone to join the fray.

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

[Scott Gray-2]

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

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

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

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

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

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

[David E. Jones-2]

Ruth,

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

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

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

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

-David


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

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

[Tim Ruppert]

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

My two cents.

Cheers,
Ruppert

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

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

[Ruth Hoffman-2]

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

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

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

Best Regards,
Ruth

On 5/3/11 9:05 AM, Tim Ruppert wrote:

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

[Jacopo Cappellato-4]

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

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

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

Jacopo

[Ruth Hoffman-2]

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

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

[David E. Jones-2]

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

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

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

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

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

-David


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

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

[Malin Nicolas]

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

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

Good point that we agree!

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

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

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

 From that we can work with own different visions
Nicolas

Le 29/04/2011 14:53, Adrian Crum a écrit :

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

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