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" <jacques.le.r...@les7arts.com>
As I said before this is all good, but for instance in Firefox no need to
choose a theme to be able to remove/put icons buttons in
the buttons bar. Firefox is only an example, we know there are much more uses
of this design.
Don't get me wrong, I'm not against themes at all. But I wonder if we really
need to build specific themes to be able to choose to
have some buttons or not. Again look like the theme argument is for all icons
or none (the possible combinaisons are obviously an
overkill). It seems to me that we still miss a mechanism to remove/add icons on
buttons/menus. In the "hiding functionality in
ofbiz" discussion in user ML some would prefer to set this with roles. It makes
sense but is still not very flexbile: each person
should be able also to remove/add icons on buttons or menu. For instance I like
icons menu addons in Firefox, not only because I
like images (certainly a rest from my education while young, where you were
given good points when you succeded ;o) but also
because
it allows me to quicker pick a menu entry than having to search for it (no
brainner). But I can understand that some other would
prefer to have their own icons (sets?) or not have icons at all on some
menu/buttons, etc.
To summarize my POV:
* Themes are great to set things in a whole (also developers can chose to apply
or not styles to set icons or not in
custom/customized applications...)
* Roles are great to set things at the enterprise level
* A mechanism to allow individuals users to choose their own icons (or sets of
icons?) or to not have icons everywhere would be a
good complement
With current OFBiz state, CSS styles (themes) are the easiest way to achieve
the goal, roles still need more work (notably to
collect the features and group them by roles, then to have those roles set and
used in code), while a mechanism. Of course to
follow
Adrian idea this could apply not only to icons. But it's the thing which comes
instantly in mind. Images are shorcut for words.
After all, Chinese use them as words. I mean they don't encode their words in
letters, a proof that the power of alphabet is not
the
only way.
I was a long time user of APL while also working with traditionnal languages
(C, Pascal). APL is a symbolic language (was first a
macro assembler), for instance you have a sole symbol to represent/solve a
system of linear equations and you are not encouraged
to
use loops. I think you could compare APL vs C/Pascal to Chinese vs Alphabetized
languages...Ho sorry almost out of subjet, I'm a
holidays dreamer :o)
Jacques
From: "Adrian Crum" <adrian.c...@sandglass-software.com>
To understand our differences a little better, it might help to set aside the
subject of icons for a moment and consider another
visual element - the HTML <table> element. I believe the way HTML tables are
handled in OFBiz represents a good balance between
developers and theme designers. If we can agree on how tables are handled, then
maybe we can apply the same concept to icons and
agree on those too. If we can't agree on how tables are handled, then...
well... we will just have to agree to disagree. ;-)
OFbiz provides a CSS class for basic <table> element layout - called
basic-table. That class provides simple positioning and
spacing. The basic-table class is intended to be "decorated" with other classes
to add other visual embellishments. A developer
can add light-grid or dark-grid CSS classes to basic-table to give it a grid. A
developer can add a hover bar to a table by
adding
the hover-bar CSS class to basic-table. This CSS class decorator pattern has
been in use for a while now, and it seems to be a
good approach because it gets used a lot.
The developer is free to choose which classes make the most sense for the
screen they are developing. What the developer CAN'T do
is specify what those classes look like - that is left up to the theme
designer. The CSS classes are a way for the developer to
give the theme designer hints about what a particular HTML element should look
like without being specific about its visual
appearance.
The theme designer controls the positioning and spacing in basic-table. The
theme designer controls the color and line thickness
of light-grid and dark-grid. The theme designer controls the appearance of
hover-bar. Different themes might style those classes
differently, but what remains consistent across themes is that they are all used in
the same way. An HTML <table> element styled
with "basic-table light-grid" will always have a light grid - regardless of the
theme. Now, here is something interesting to
think
about - a theme designer could choose not to style the grids, and eliminate table grids
altogether. There is no "law" saying that
all CSS classes must be styled. A theme that eliminates grids may or may not
get used - it depends on the user. Some users might
prefer to have grids turned off - so they would select the "gridless" theme.
***This is where the balance between developer and
theme designer comes in*** - the developer provides a hint that a table should
have grids, but the developer doesn't force grids
on the theme designer or the user.
Now let's apply the icon conversation to the HTML <table> element example. What
has been suggested is that all themes be made
consistent by hard-coding table grids in the markup. When I objected to that,
it was suggested that table grids can be
enabled/disabled by a user setting. For the sake of compromise I agreed to
that, but I believe it is unnecessary because a user
could simply choose a theme that has grids enabled or disabled.
To summarize: What I am advocating is that we treat icons the same way as we do
all other visual elements - let the theme
designer
have control of their use. I see no valid reason why icons should be treated
differently. Users who want icons will choose a
theme
that uses them. Users who don't want icons will choose a theme that doesn't use
them. The system we use now is flexible and it
works - it doesn't need to be changed.
-Adrian
On 4/29/2011 2:20 AM, Nicolas Malin wrote:
Thanks all for you comments.
The last patch I did was mostly on icons, but was more an attempt to increase the
"user experience" by mixing actual icons
management and dynamic selection coming the visual theme.
Now I understand what is meant, and the directions everyone wants to go to,
which are quality and simplicity, and then lead to
innovation. I think we should then continue this way.
Adrian, you are insisting that theme designers should handle its icons, but I'm
more saying that we should normalize icon usages
so the developer or the theme designer are the more directed possible and so
the layouts are normalized.
I'm not sure that only using style attributes is the best way, as this is
chaining classes when you want to apply more than one
visual style, and this is also widely used in jQuery. This is working when the
developer is well advanced in his interface.
So I'm telling this would be better to add an objective or goal to a field, and
then:
* restrain usages by enumeration in the xsd
* restrain goals number linked to a field type (button, link, text, ...)
* help theme designer by fixing clear goals and style names
It would also be possible to add new values if exceptions are coming, but only
in this case...
On the design side, each theme would have a purpose.css file which will only
keep classes in direct relaation with the previous
definitions. The designer will then have a clear vision on field usage and what
to do for rendering.
I can work on a POC, which would come in the images folder, or create a generic
theme and then use it as a basis
Nicolas
Le 26/04/2011 21:31, Adrian Crum a écrit :
I agree. One of the things I've tried to do to help that along is by writing
the Best Practices on the Wiki site. But a more
design-oriented approach would help too. From my perspective, the Best Practices
basically say "you should do it this way", and
in the design-oriented pages you can learn more about WHY you should do it that
way.
I like the idea of working with the current community to get a consensus on
these things and then loosely enforcing them. I
keep
holding out hope that the desire to produce a quality product will increase.
I understand your viewpoint of just starting over with new code and new
community members. At first glance that seems
attractive. But it seems to me that's like curing cancer by executing the
patient.
-Adrian
On 4/26/2011 12:16 PM, David E Jones wrote:
Yes, that's true. That goes back to one of the big difficulties with something like OFBiz
managed in the "Apache way". OFBiz
isn't a project driven by specifications, and so many decisions are made in a
more ad-hoc manner.
If we were to step back and make OFBiz spec-driven by actually writing up
requirements and then creating designs (specs) based
on the requirements, and then implementing to those, and testing against them.
That sort of effort could happen right now by collaborating on documents that
represent requirements, and then on documents
that represent designs. Those would be separate from the project for (probably)
quite a while, so wouldn't interfere with
current happenings.
-David
On Apr 26, 2011, at 12:03 PM, Adrian Crum wrote:
I agree with you on the unnecessary complication of common or shared artifacts.
I have been ranting for years about the
Global
Decorator being filled with a lot of things that don't belong there, but
nothing changes - people keep dumping more stuff in
there. So the problem is caused by more than a lack of discussion in the design
phase, it's also caused by a lack of care
after the design.
-Adrian
On 4/26/2011 9:52 AM, David E Jones wrote:
And yes, not every idea is a good one and many things really don't belong in
the framework. Putting things in themes instead
of the framework is a good idea for many things. And on the topic of themes, it
would be nice (and reduce the incredible
amount of redundancy in themes) if the themes were limited to visual artifacts
such as images and style sheets, instead of
also including various templates. Take these hugely redundant theme templates
(especially for header) and combine that with
the practice of parameterizing every little thing... and you have an
error-prone tangle that makes customization difficult
and discourages innovation and improvement in the project.
Sorry for the rant, but this kind of thing has been going on for a long time
and is another reason why I still maintain that
the ONLY way OFBiz will ever have a clean framework separation, and even a
clean framework, is if it is a separate project
maintained by a different group of people than maintains the more
business-oriented functionality of OFBiz.
-David
On Apr 26, 2011, at 4:37 AM, Scott Gray wrote:
I agree with Adrian, the style element alone already gives more that enough
control to theme designers.
Every web developer has (or should have) at least a basic understanding of css
and every time we step away from such a
standard (like with additional attributes in the widgets) we make OFBiz a
little harder to use and maintain, it's plenty
hard enough already. Not every idea is a good idea and not every good idea is
really needed.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/04/2011, at 8:37 AM, Adrian Crum wrote:
Main style sheet:
.button-bar ul a.create,.button-bar a.create {
padding:6px 10px 6px 10px;
}
Optional icons style sheet:
.button-bar ul a.create,.button-bar a.create {
background: url(../images/button_sprite.png) no-repeat 0px 0px;
padding:6px 10px 6px 30px;
}
No changes to markup needed. It is the same thing we do to switch rendering
from LTR to RTL.
-Adrian
On 4/25/2011 1:19 PM, Nicolas Malin wrote:
Your are against me ? My popularity increases :)
At this time :
Screen definition :
------------------------
<link target="EditExampleLayer" ... style="buttontext create"/>
Output html render :
---------------------------
<a class="buttontext create" id="FindExample_LF_1_link"
href="javascript:void(0);">Nouvel exemple</a>
Style theme definition :
------------------------------
style.css :
.button-bar ul a.create,.button-bar a.create {
background: url(../images/button_sprite.png) no-repeat 0px 0px;
padding:6px 10px 6px 30px;
}
My proposition, after your first remark :
Screen definition :
------------------------
<link target="EditExampleLayer" ... style="buttontext">
<icons name="add">
</link>
Or
<link target="EditExampleLayer" ... style="buttontext" icons="add">
Or
<link target="EditExampleLayer" ... style="buttontext" purpose="add">
Output html render :
---------------------------
<a class="buttontext add" ...>Nouvel exemple</a>
Style theme definition :
------------------------------
icons.css :
.button-bar ul a.add,.button-bar a.add {
background: url(../images/button_sprite.png) no-repeat 0px 0px;
padding:6px 10px 6px 30px;
}
What's changes ? What is broken? Your are against widgets controlling styling
but at this time all icons define by style
attribute on elements to be used by theme. I propose more fexibility to explain
the element's purpose that will be work
by
screen renderer and after by theme designer.
To continue update icons improvement :
<set field="iconsModeViewEnumId from-field="userPreferences.VT_ICONS_MODE_VIEW"/>
<!--If User whant to view icons-->
<set field="iconsStyleLocation" from-field="userPreferences.VT_ICONS_"
global="true"/><!--If User have preference on
icons
to use-->
<service service-name="getIconsVisualThemeResources"><!--return the css file to
use that contains icons definition-->
<field-map field-name="visualThemeId"/>
<field-map field-name="iconsModeViewEnumId"/>
</service>
Nicolas
Le 25/04/2011 14:25, Adrian Crum a écrit :
I'm against the idea of widgets controlling styling. Period. I am against
Nicolas or any other developer deciding which
icons get used and where - that is a decision that should be reserved for theme
designers.
To summarize my view:
1. Icon display and the choice of icons should be left to the theme designer.
Therefore, icon references should be kept
in stylesheets.
2. If a theme designer wants to give the user an option to use icons or not,
then the theme's templates can
conditionally
load a cascading stylesheet that includes icons.
-Adrian
On 4/25/2011 5:14 AM, Jacques Le Roux wrote:
On a second thought, we may use another technology than CSS and still have
styles, see for instance in POS:
posstyles.xml. So yes,
styles add flexibility and independence.
At 1st glance, Adrian's proposition sounds better from flexibility POV. But, if
I have well understood, is still
limited
to icons or
not in the whole OFBiz (like Google bar) when Nicolas's allows to set it by
screens (why not even by form fields or
menu
entries?)
I think this is really an important point in UI and should be discussed by the
whole developers community, any other
opinions,
suggestions?
Thanks
Jacques
From: "Adrian Crum"<adrian.c...@sandglass-software.com>
You can control icon display through user preferences without embedding the
icons in markup. A user setting can
conditionally load
a stylesheet that references the icons.
I'm not against having new icons in the project. An expanded selection of icons
is a great tool for theme designers to
use. But
their use should be determined by the theme designers - not by screen widgets.
The OFBiz community has worked hard
over
the past 4
years trying to get styling out of markup and into stylesheets. I will push
hard against any effort to reverse that.
-Adrian
On 4/25/2011 1:32 AM, Nicolas Malin wrote:
Adrian I understand your remark but I'm not completely in agreement with that.
Icons is at once of the most visual but also a help user. We could associated
directly to a themes but the reality is
more
complex. If I take the GTK project, every user can define if he wants icons,
icons and text or only text
independently
of the
themes.
On issue OFBIZ-4259 I do an error to use icons through img because although
they are images, they are a more complex
management.
I'm not for their exploitation only through css or style because although they
results from it. We limit their
display
rendering
on one technology et style don't allow user preference managment.
I propose to continue icons integration, add a new element in screen renderer
that indicates what icons use on menu
and form
field. Thence following the user preference and then the themes we display
icons or not. Whether rendering css by
then
or
treatment with an image, it will be template renderer are made their work.
Nicolas
Le 25/04/2011 05:21, Ryan Foster a écrit :
I thought the original idea that Nicolas proposed, was for this to be
configurable by theme (adding a
layoutSettings.VT_ICONS_LOC to data config). I think that you should be able
to turn icons on and off as well as
change the
icon library location.
Ryan L. Foster
801.671.0769
cont...@ryanlfoster.com
ryanlfoster.com
On Apr 24, 2011, at 6:29 AM, Adrian Crum wrote:
The main problem I have with this is the idea that theme design has been taken
away from the theme designer. In
other words,
icons should be added by the theme designer - they should not appear in all
themes by default.
-Adrian
On 4/24/2011 5:26 AM, Jacques Le Roux wrote:
It's actually related to https://issues.apache.org/jira/browse/OFBIZ-4259 and
r1095984
I did not see any issues in Flat Grey, could you post a screenshot?
If it's really blocking (I doubt we can't fix any related issues), it should be
easy to configure with a property
in
widget.properties to bypass image rendering in menus (HtmlMenuRenderer.java
around line 500) and buttons
(MacroFormRenderer.java look for submitField.getImageLocation(context) or
maybe rather ModelFormField.java but
this one
existed before, see http://svn.apache.org/viewvc?view=revision&revision=1095984
for files changed)
Jacques
From: "Adrian Crum"<adrian.c...@sandglass-software.com>
I see that icons were added to menu items - maybe in rev 1088549. Is there a
chance we can revert that? Or at
least make it
configurable on a per-theme basis? The new icons break the layout in the Flat
Gray theme. It would be helpful if
a
theme can
choose to use the icons or not use them.
-Adrian
