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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/