Re: Don't touch the theme class files

[Johannes Schaback]

Hi Esa,

I am not sure if you received the last may concerning that issue,
because Rainer and I are currently re-designing the state concept
alongside with the visual properties that each widgets has. I am
afraid you have to wait a little until we are done in order to avoid
double work. The states (and the contained visual properties) are
likely to be ordered in a tree structure in the future. I am sorry for
the inconvenience!!

Do you skype or GoogleChat or ICQ or YahooMessenger? We could exchange
some ideas on that issue maybe...

Johannes

On 10/11/06, Esa Tanskanen <fladim...@hotmail.com> wrote:
>
> .... to be exact.
>
> /Esa
>
> _________________________________________________________________
> Uutisista turhaan tietoon. Mitä ikinä etsitkin, MSN Search löytää hakemasi.
> http://search.msn.fi
>
>
> >
>

[Esa Tanskanen]

Yeah, I got your mail, but I thought it had nothing to do with the themes...
I've got MSN Messenger, this email address is the account.

_________________________________________________________________
Nyt löydät etsimäsi tiedot nopeasti niin koneeltasi kuin netistä.
http://toolbar.msn.fi

[Johannes Schaback]

Too bad, I dont have a MSN account... I got so many IMs running
simultaneously, such that I had to draw the line somewhere. :)

But the modifications are almost done. I hope that I will manage to
check in my stuff on Friday. I will then commment the changes and
provide a detailed description and justification.

Cheers, Johannes

[Esa Tanskanen]

OK, maybe you could suggest me one of them?

[Johannes Schaback]

Rainer and I use Skype most of the time. But Josh, Boris and me all
have GoogleChat running around the clock. So maybe you want to try
GoogleChat. I can send you an invitation in case you do not have a
Google account.

But on second thought, I could understand if you rather want to "chat"
on the mailing list. After all that's what the list made for (and
everyone can follow our conversation). Let me know what you prefer. :)

[Esa Tanskanen]

>I can send you an invitation in case you do not have a
>Google account.

OK, that'd be nice.

>But on second thought, I could understand if you rather want to "chat"
>on the mailing list. After all that's what the list made for (and
>everyone can follow our conversation). Let me know what you prefer. :)

I prefer the both. I'd consider a chat a better place for detailed
discussion about the coding process, but more like for a general discussion.
Also the chat could be used for a bit more informal talk... :)

_________________________________________________________________
Windows-työpöytähaun avulla löydät tiedot koneeltasi silmänräpäyksessä.
http://toolbar.msn.fi

[Johannes Schaback]

Alright!

On 10/11/06, Esa Tanskanen <fladim...@hotmail.com> wrote:
>

[Esa Tanskanen]

Hi,

It'd allow for a lot more flexibility in the themes if it'd be possible to
separate the images to several layers. For example, the shadows would be in
a layer below the actual graphics, so that they wouldn't shadow other
elements in the same level (buttons wouldn't shadow other buttons, but
they'd shadow windows). I don't see how it'd be too difficult to implement.
What do you think?

Also, is it possible to change the blending mode when rendering specific
elements or pixmaps? That'd also be nice, sometimes an additive or
multiplicative blender would be in order...

/Esa

[Johannes Schaback]

> It'd allow for a lot more flexibility in the themes if it'd be possible to
> separate the images to several layers. For example, the shadows would be in
> a layer below the actual graphics, so that they wouldn't shadow other
> elements in the same level (buttons wouldn't shadow other buttons, but
> they'd shadow windows). I don't see how it'd be too difficult to implement.
> What do you think?

I dont not think that we urgently need a new concept for layering
images. Shadows can easily be accomplished with a ShadowBorder. And
for the layered images, we have the CompositeBackground since several
days which does exactly what you propose.

> Also, is it possible to change the blending mode when rendering specific
> elements or pixmaps? That'd also be nice, sometimes an additive or
> multiplicative blender would be in order...

The blending function is set to gl.glBlendFunc(GL_SRC_ALPHA,
GL_ONE_MINUS_SRC_ALPHA) per default. But you can extend the IOpenGL
interface to allow switching between other blending functions of
course. However, I believe it is not sensible to parameterize widgets
which blending function to use from my point of view. What exactly do
you have in mind to accomplish with additive or multiplicative
blending for widgets?

Johannes

[Esa Tanskanen]

> > It'd allow for a lot more flexibility in the themes if it'd be possible
>to
> > separate the images to several layers. For example, the shadows would be
>in
> > a layer below the actual graphics, so that they wouldn't shadow other
> > elements in the same level (buttons wouldn't shadow other buttons, but
> > they'd shadow windows). I don't see how it'd be too difficult to
>implement.
> > What do you think?
>
>I dont not think that we urgently need a new concept for layering
>images. Shadows can easily be accomplished with a ShadowBorder. And
>for the layered images, we have the CompositeBackground since several
>days which does exactly what you propose.

The problem is that the shadow border shouldn't take any space. Otherwise
the components would be too sparsely placed.

> > Also, is it possible to change the blending mode when rendering specific
> > elements or pixmaps? That'd also be nice, sometimes an additive or
> > multiplicative blender would be in order...
>
>The blending function is set to gl.glBlendFunc(GL_SRC_ALPHA,
>GL_ONE_MINUS_SRC_ALPHA) per default. But you can extend the IOpenGL
>interface to allow switching between other blending functions of
>course. However, I believe it is not sensible to parameterize widgets
>which blending function to use from my point of view. What exactly do
>you have in mind to accomplish with additive or multiplicative
>blending for widgets?

Lighting and colored shadows, mainly. I'd like to create a theme like many
of those digital abstract art images...

[Johannes Schaback]

> The problem is that the shadow border shouldn't take any space. Otherwise
> the components would be too sparsely placed.

Hmm, I see your point, but how large do you plan to have your shadows?
More than 10 pixels? In Windows the shadows are only about 5 pixels
thick :)

> Lighting and colored shadows, mainly. I'd like to create a theme like many
> of those digital abstract art images...

Hmm, not sure what you mean :) Do you got an example?

Johannes

[Esa Tanskanen]

Well, the usual Windows theme is designed pure useability in mind, not the
looks. My shadows are usually over 20 pixels thick, just because they fade
out instead being hard-cut. But instead of shadows I was actually thinking
more about some graphical parade behind the elements which is not so
important, but is there to improve the looks.

>From: "Johannes Schaback" <johannes...@gmail.com>
>Reply-To: FengGUI-D...@googlegroups.com
>To: FengGUI-D...@googlegroups.com

_________________________________________________________________
Uutiset ja kasvot uutisten takaa. MSN Search, täyden palvelun hakukone.
http://search.msn.fi

[Johannes Schaback]

> Well, the usual Windows theme is designed pure useability in mind, not the
> looks. My shadows are usually over 20 pixels thick, just because they fade
> out instead being hard-cut. But instead of shadows I was actually thinking
> more about some graphical parade behind the elements which is not so
> important, but is there to improve the looks.

Concerning the think shadows I am afraid that there is little that we
can do with our current way to render widgets, because everything that
is drawn outside of the "widget space" is clipped :((

As for the graphical finesse (not sure what you mean with "parade"),
we can certainly do something about that. Can you file a detailed
feature-request on that behalf so that we can think about it a little
longer how to accomplish your desired effect? It may be that similar
requirements will come up in the future and I would like to be
prepared to allow all sorts of effects without rewriting (or adding)
too much code to the existing widgets.

Actually I am thinking of a something like a general but simple effect
framework. Maybe just an interface IEffect that has two methods:
setupEffect() and tearDownEffect() or similar. Instances of this
interface can be assigned to any widget. The setupEffect methods is
called before the widget is drawn. After the widget has been drawn,
the tearDownEffect method is called. This would allow to switch the
blending function for widgets as well as to render whole containers
with some freaky affine transformation (projective, etc.). But as I
said, that's nothing more than a though right now and we certainly
need to think about it a bit longer :)

Johannes

[Boris Beaulant]

Hi all,

I recently discovered that my Window's pixmap borders (16 slices) are
clipped on top (see the scrennshot in attached file). From my side
nothing change in the theme.xml. I have to try to look at the
PixmapBorder class, but nothing seem to be wrong, the topLeft,
topLeftEdge, topEdge, topRightEdge and topRight were present in the
paint method.
Do you have any idea of what can be the origin of this problem ?

Else about window's shadow, it's clear that it could not be include in
the widget space, and in this case those effect can be added to all
widgets ...

Happy coding,
Bo

[Johannes Schaback]

Hi Boris,

> Do you have any idea of what can be the origin of this problem ?

I guess it has something to do with recent changes to how borders are
drawn. Previously we passed the widget to the paint() method of the
borders. Now we pass the position, width and height to the borders.
This allows for nested borders (i.e. multiple borders for a widget).

Apparently I havent tested the Pixmapborder with 16 slices well
enough. I will check and rectify accordingly!

Thanks for reporting this btw.

> Else about window's shadow, it's clear that it could not be include in
> the widget space, and in this case those effect can be added to all
> widgets ...

Despite the reason that hard-cut shadows are not desirable which would
force widgets to leave large gaps between them, I am afraid it is not
absolutely clear to me why shadows should not be part of the widget
space. However, maybe I am having a too specific idea in mind how to
accomplish shadows... l what would you guys suggest how to render
borders?

Johannes

[Johannes Schaback]

> Concerning the think shadows I am afraid that there is little that we
> can do with our current way to render widgets, because everything that
> is drawn outside of the "widget space" is clipped :((

Just a quick note that came to my mind a few minutes ago. You can
always "layout" your widgets with the StaticLayoutManager. This allows
to position widgets arbitrarily. So although the shadow border would
consume too much space when layouted regularly, you can simply put
your widgets closer together by manually specifying their position.

Johannes

[Esa Tanskanen]

>Just a quick note that came to my mind a few minutes ago. You can
>always "layout" your widgets with the StaticLayoutManager. This allows
>to position widgets arbitrarily. So although the shadow border would
>consume too much space when layouted regularly, you can simply put
>your widgets closer together by manually specifying their position.

But then we'd run to the issue that the buttons (and other elements) would
shadow each other, and that's not desireable.

[Johannes Schaback]

> But then we'd run to the issue that the buttons (and other elements) would
> shadow each other, and that's not desireable.

yapp... That's true unfortunately :(

[Esa Tanskanen]

What about just implementing several layers, each rendered separately on top
of each other?

>From: "Johannes Schaback" <johannes...@gmail.com>
>Reply-To: FengGUI-D...@googlegroups.com
>To: FengGUI-D...@googlegroups.com
>Subject: Re: FengGUI: Layers and blending modes

_________________________________________________________________

[Johannes Schaback]

However, it still works for windows in the Display container :P

After I finish Boris' bug with the pixmap border tonight, I will think
about how to tackle that. Any ideas already? Suggestions? :)

I implemented key traversal for Button btw, but I have not committed
it yet. I first want to get it done for all standard widgets.

Johannes

[Johannes Schaback]

> What about just implementing several layers, each rendered separately on top
> of each other?

Hmm, not sure if I understand you correctly, can you be more specific?
Do you mean z-layers? or rather general layers such that each widget
can chose what to draw in which layer?

[Esa Tanskanen]

General layers, yes (if by z-layer you mean using the z-coordinate). Of
course, since the layers must be rendered bottom-up (because of blending),
we'd need to buffer the contents of the border in a display list or in our
own specialized command list.

>From: "Johannes Schaback" <johannes...@gmail.com>
>Reply-To: FengGUI-D...@googlegroups.com
>To: FengGUI-D...@googlegroups.com
>Subject: Re: FengGUI: Layers and blending modes

_________________________________________________________________

[Johannes Schaback]

I still not sure if I totally grasp what you suggest. Let me try to
get it straight. You suggest FengGUI to have let's say 3 global
layers. The first layer for the containers, the second layer for
borders and non-clipped stuff and the third layer for the widget
content. By making use of display lists (or other buffers) we would be
able to render all three layers in a bottom-up manner... Is that
correct?

Johannes

[Boris Beaulant]

Other subject, other question .. ;)

In FengGUI the default alphabet is english, it's possible add german
too, but frensh is not there. Then my first question is : can I add
french to the Alphabet enum ?
Else, at present the font define by a theme load a font with the default
alphabet (english here), is there any way to by able to define the
FengGUI default alphabet ?

For exemple a FengGUI.setDefaultAlpahbet(Alphabet) method could be a
good thing. And in this way the FontTheme uses this alphabet to create
tis fonts.
The proble is if you change the default alphabet you need to reload all
the texture fonts ...

What do you think about that ?

Bo

[Esa Tanskanen]

Close, but not exactly. There should be an unlimited number of layers. If a
layer is used, then it exists. The widgets will always render themselves on
top of the window, so they have different layers than the windows. A Layers
container is passed to the drawing methods:

class Layers {
private Map<Integer, Integer> _layerDisplayListIndices = new
HashMap<Integer, Integer>();

public void selectLayer(int index) {
Integer displayList = _layerDisplayListIndices.get(index);
if (displayList == null) {
displayList = /* create a display list */
_layerDisplayListIndices.put( index, displayList );
}

selectDisplayList( displayList );
}

public void drawLists() {
for (int list : _layerDisplayListIndices.values()) {
drawDisplayList(list);
}
}

public void clear() {
_layerDisplayListIndices.clear();
}
}

However, the downside is that it'd also make the rendering slightly more
unefficient.

_________________________________________________________________

[Johannes Schaback]

Hi Boris!

> In FengGUI the default alphabet is english, it's possible add german
> too, but frensh is not there. Then my first question is : can I add
> french to the Alphabet enum ?

yes, please do so!

> For exemple a FengGUI.setDefaultAlpahbet(Alphabet) method could be a
> good thing. And in this way the FontTheme uses this alphabet to create
> tis fonts.

Yeah, I guess FengGUI.java is certainly a good place to store a global
and static default alphabet. But actually I think it would be better
to store the default alphabet directly in Alphabet.java. Such that you
could access the defaullt font via Alphabet.getDefaultFont(). I guess
that is a bit more intuitive?

(and yes, you are assuming right, the default font should actually be
hold in Font.java and not Label.java :) We need there a
setDefaultFont() method too btw!! )

> The proble is if you change the default alphabet you need to reload all
> the texture fonts ...

Hmm, yeah, I understand the problem, but I suggest that we do not
bother to reload all fonts to make the language switch. Usually people
will setup the language before they start building their GUIs, such
that all necessary items and labels will have the right font assigned.
But despite from that it is quite difficult to reload all fonts,
because fonts may be stored on disk, where you cannot switch the
alphabet anyway. In addition one has always the possibility to create
a font by specifiying an alphabet.

Johannes

[Johannes Schaback]

hmm, ok, I need to digest that a little :)

[Johannes Schaback]

As an alternative (quick and dirty with emphasize on dirty) we could
modify the drawing policy in Container such that the borders of all
child widgets are drawn first (non-clipped) and then the backgrounds
and contents of the widgets (clipped). This way one could define
arbitrary borders that do now overlapp other widgets in the same
container...

Johannes

On 10/23/06, Johannes Schaback <johannes...@gmail.com> wrote:

[Boris Beaulant]

Johannes Schaback a écrit :

> Hi Boris!
>
>
>> In FengGUI the default alphabet is english, it's possible add german
>> too, but frensh is not there. Then my first question is : can I add
>> french to the Alphabet enum ?
>>
>
> yes, please do so!
>

Ok, but afer thinking about that I remember how Flash manage embedded
glyphs (see the attached file). What do you think if we use the
organisation in the Alphabet class instead of using ENGLISH, GERMAN, ...

>
>> For exemple a FengGUI.setDefaultAlpahbet(Alphabet) method could be a
>> good thing. And in this way the FontTheme uses this alphabet to create
>> tis fonts.
>>
>
> Yeah, I guess FengGUI.java is certainly a good place to store a global
> and static default alphabet. But actually I think it would be better
> to store the default alphabet directly in Alphabet.java. Such that you
> could access the defaullt font via Alphabet.getDefaultFont(). I guess
> that is a bit more intuitive?
>
> (and yes, you are assuming right, the default font should actually be
> hold in Font.java and not Label.java :) We need there a
> setDefaultFont() method too btw!! )
>
>

I'm not sure to understand, do you mean that we need to write
Font.setDefaultFont() and Label.setDefaultFont() static methods ?

Regards,
Bo

[Esa Tanskanen]

Yeah, but sometimes the dimensions of the borders should matter. I think
some kind of a layer approach would also be nice if the GUI could be
animated in the future. I guess animated pixmaps aren't supported yet?

[Johannes Schaback]

Hi Esa

Animated Pixmaps are not implemented yet indeed. I tried to recruit a
guy who seems to know something about animated textures (compression
and stuff). But I guess we will have to do it by ourselfs. However,
animted textures are quite fancy. I attach greater importance to the
XML stuff at the moment. :)

Johannes

[Johannes Schaback]

> Yeah, but sometimes the dimensions of the borders should matter. I think
> some kind of a layer approach would also be nice if the GUI could be
> animated in the future. I guess animated pixmaps aren't supported yet?

Whops, I sent my answer too quickly. In my proposed method for drawing
the borders, *before* we draw the content of the widgets does not
imply that the size of the border does not matter :) It would matter
in fact for the Layout Managers as it does right now. All we would
gain is that sibling widgets (widgets in the same container) do not
shadowed each other.

Cheers,

Johannes

[Esa Tanskanen]

Indeed, I've just been having several artistical ideas lately. It'd be quite
nifty to implement the animation as a 3D texture, which would allow for easy
smooth transistions between frames. However, they require an OpenGL
extension to be supported, so maybe it'd be best to use several textures
instead.

But actually more important than the animated textures would be some simple
transistions. For example, if a window is opened, a stretch effect could be
used. Also color tinting would allow for some nice effects. After all, I'd
like to use the GUI for games, and they require all kinds of fancy stuff :)

>From: "Johannes Schaback" <johannes...@gmail.com>
>Reply-To: FengGUI-D...@googlegroups.com
>To: FengGUI-D...@googlegroups.com
>Subject: Re: FengGUI: Layers and blending modes

_________________________________________________________________

[Johannes Schaback]

> Ok, but afer thinking about that I remember how Flash manage embedded
> glyphs (see the attached file). What do you think if we use the
> organisation in the Alphabet class instead of using ENGLISH, GERMAN, ...

Rendering glyphs becomes awful slow when reaching a certain amount of
displayed characters. As far as I know, OpenGL does not provide direct
glyph support such that you always have to draw the splines through
regular opengl calls. In addition, it is trivial to shade your fonts
nicely (lets say with some blending effect, golden shiny borders,
etc.), because the characters are not images anymore but need to be
rendered by yourself.

I think the problem with the alphabets in manageable for Latin based
alphabets. Moreover, the main guy behind jME said in one of his forum
posts that he likes the way FengGUI does the fonts. :)
Our current method may be unpractical for Asian fonts though. However,
there are reports that state the most Asian languages only use a very
small subset of all possible characters. I know from Chinese that you
can read a newspaper when you know about 2000 characters (which are
probably not more than 1MB on Pixmaps I guess). Since Asian characters
have many redundant elements (like in our chase redundant characters
in words), it is bit inefficient to draw all character as images... so
yeah, it is irony that we use the Chinese Feng symbol as our logo, but
are actually not sure if we can display all Chinese characters in
FengGUI. :P

> I'm not sure to understand, do you mean that we need to write
> Font.setDefaultFont() and Label.setDefaultFont() static methods ?

Yes, I would suggest that. Following the Information Expert pattern I
would put the default statically in Font.java. Thus moving it from
Label.java to Font.java. But it is not urgent, only good practice...
if you can speak of "good practice" for static variables :)

Similar I would prefer to have the standard alphabet in Alphabet.java.

Cheers,

Johannes

[Esa Tanskanen]

Just a quick question - why does the LabelStateTheme have the
"text"-variable? What is it supposed to do?

[Johannes Schaback]

> Indeed, I've just been having several artistical ideas lately. It'd be quite
> nifty to implement the animation as a 3D texture, which would allow for easy
> smooth transistions between frames. However, they require an OpenGL
> extension to be supported, so maybe it'd be best to use several textures
> instead.

I remember I read a few things about how to implement animated
textures (e.g. for flames or stuff). It was actually not too
complicated. Can you file a feature-request on the behalf? :)

> But actually more important than the animated textures would be some simple
> transistions. For example, if a window is opened, a stretch effect could be
> used. Also color tinting would allow for some nice effects. After all, I'd
> like to use the GUI for games, and they require all kinds of fancy stuff :)

Yapp, I totally agree. I am still thinking about the FX framework
(well, you cannot really speak of a framework, because that includes
"frame" and "work" and my current idea is more a "frame" than "work").
I guess I can give it a shot soon and we can see how it turns out. Can
you add and assign that FX issue in the feature request tracker to me?
I will implement it after I fixed Boris' PixmapBorder bug and the key
traversal issue.

Johannes

[Esa Tanskanen]

>I remember I read a few things about how to implement animated
>textures (e.g. for flames or stuff). It was actually not too

>complicated. Can you file a feature-request on the behalf? :)¨

Wouldn't it be just as simple as using several textures for that? Am I
missing something?

[Esa Tanskanen]

It seems that I can't assign the tasks to anyone, I can only create them...

_________________________________________________________________
Windows-työpöytähaun avulla löydät tiedot koneeltasi silmänräpäyksessä.
http://toolbar.msn.fi

[Johannes Schaback]

That is a very good question, because from a intuition point of view
the text string is an "instance specific" attribute and not a general,
theme attribute.

Well, the reason is very simple though. For example in case you want
to assign a custom icon as the close button you need to remove the "X"
which is there per default. Thus you set <text></text> (empty string).

Johannes

[Esa Tanskanen]

OK, I talked too early, now the assignment works...

[Johannes Schaback]

> Wouldn't it be just as simple as using several textures for that? Am I
> missing something?

You are totally right in general. You can simply display a series of
Pixmaps or whole textures. But OpenGL provides some nice functions for
that purpose which we may want to make use of. This would allow us to
play whole movies in FengGUI, or at least intros. But maybe that is a
bit too much already and a simple (uncompressed) series of pixmaps
suffices.

Somthing like an Animation class that holds several Pixmaps is a
sensible idea I guess.

Johannes

PS: oh boy, imagine one could have buttons that burn!

[Esa Tanskanen]

Where is that used for? At least it's not used when the look of a Button is
set up...

[Johannes Schaback]

The member variable "currentState" in ButtonTheme.java is quite
important actually: When the parser hits the <mouseOverState>-element,
all subsequent XML elements need to be forwarded to the associated
LabelStateTheme (in this case mouseOverState). Thus the parser sets
the currentState = mouseOverState such that all startElement(...) etc.
calls are redirected to the mouseOverState. If the the parsers finds
the </mouseOverState>-element, it sets currentState=null until it
encounters <defaultState> or <pressedState> and so on.
You will encounter this in many theme classes. This way the theme
classes have control over their "sub-elements".

Johannes

On 10/24/06, Esa Tanskanen <fladim...@hotmail.com> wrote:
>

[Esa Tanskanen]

Hi,

The Font-class doesn't contain any name for the font. Thus, it'd be
difficult to generate any sensible name for the saved font. In fact, the
Font class doesn't contain any information that could be used to "save" the
font in the theme XML file (as <font systemName="arial" size="20" />).

It's the same with pixmaps, there's no way to know how the pixmap is
retrieved...

Also, I noticed this: height = texHashMap.get('a').getHeight();

I'd say that's not very accurate. And if the character set doesn't have the
letter A in it (for example, a chinese font) that would go crashing down.

/Esa

[Johannes Schaback]

> The Font-class doesn't contain any name for the font. Thus, it'd be
> difficult to generate any sensible name for the saved font. In fact, the
> Font class doesn't contain any information that could be used to "save" the
> font in the theme XML file (as <font systemName="arial" size="20" />).
> It's the same with pixmaps, there's no way to know how the pixmap is
> retrieved...

I understand the problem. This actually originates from the fact the
the themes were never designed to be saved! Only to be loaded...

I suggest to ignore the problem at the moment and make the fonts and
pixmaps simply not saveable because people will usually define the
theme manually. All we need at the moment is that the themes can be
loaded as with the old XML handlers. I believe that we do not harm our
design by postponing this decision.

However, we will run in this problem again when we got to the "GUI
instance serialization" like for sending GUIs over the network. This
will also require to assign names to widgets (not only to pixmaps and
fonts).... It will also require some sort of basic resource manager to
keep track of what textures (fonts, pixmaps) we got in the video
memory. I create a feature-request on that behalf.

The whole resource management appears very simple at the beginning,
but it turns out to be quite difficult. Are we going to send fonts
over the network as well or shall they be stored locally only? Are we
sending pixmaps over the network? Do we want to send everything over
the network?

The more I think about it the more I believe it would be easiest to
NOT stream anything that depends on the video memory. Everything that
requires memory management (fonts, pixmaps) is stored locally and is
refered to via names in the XML streams. What do you think?

> Also, I noticed this: height = texHashMap.get('a').getHeight();
>
> I'd say that's not very accurate. And if the character set doesn't have the
> letter A in it (for example, a chinese font) that would go crashing down.

Nope, that's okay. All character pixmaps have the same height. Thus,
'a' has the same height as any other character of that font. :)

Cheers,

Johannes

[Boris Beaulant]

Hi Johannes,

Alphabet again ... ;)

> Yeah, I guess FengGUI.java is certainly a good place to store a global
> and static default alphabet. But actually I think it would be better
> to store the default alphabet directly in Alphabet.java. Such that you
> could access the defaullt font via Alphabet.getDefaultFont(). I guess
> that is a bit more intuitive?

When you say "...access the defaullt font via
Alphabet.getDefaultFont().." do you mean that Alphabet need to give a
'Font' object ? Isn't it preferable to have something like
Alphabet.getDefaultAlphabet() that returns an 'Alphabet' ?

> Rendering glyphs becomes awful slow when reaching a certain amount of
> displayed characters. As far as I know, OpenGL does not provide direct
> glyph support such that you always have to draw the splines through
> regular opengl calls. In addition, it is trivial to shade your fonts
> nicely (lets say with some blending effect, golden shiny borders,
> etc.), because the characters are not images anymore but need to be
> rendered by yourself.

> I think the problem with the alphabets in manageable for Latin based
> alphabets. Moreover, the main guy behind jME said in one of his forum
> posts that he likes the way FengGUI does the fonts. :)
> Our current method may be unpractical for Asian fonts though. However,
> there are reports that state the most Asian languages only use a very
> small subset of all possible characters. I know from Chinese that you
> can read a newspaper when you know about 2000 characters (which are
> probably not more than 1MB on Pixmaps I guess). Since Asian characters
> have many redundant elements (like in our chase redundant characters
> in words), it is bit inefficient to draw all character as images... so
> yeah, it is irony that we use the Chinese Feng symbol as our logo, but
> are actually not sure if we can display all Chinese characters in
> FengGUI. :P

It's right that in this case tha pixmap would be larger ! And it could
be difficult to manage it efficiently.

To summarize all about Alphabet :
1. Add a Alpahabet.getDefaultAlphabet()
2. Add a Font.getDefaultFont() and Label.getDefaultFont() (returns a
Font that uses the default Alphabet)

Am I right ?

Else, thanks for the PixmapBorder bug fix ;)

Bo

[Johannes Schaback]

> When you say "...access the defaullt font via
> Alphabet.getDefaultFont().." do you mean that Alphabet need to give a
> 'Font' object ? Isn't it preferable to have something like
> Alphabet.getDefaultAlphabet() that returns an 'Alphabet' ?

Uh, yes, silly me! Alphabet.getDefaultFont makes no sense of course. I
meant (and you guessed right) getDefaultFont() to be in Font.java, not
Alphabet.java of course! This happens when I answer mails in a rush.
Sorry! So yes, Alphabet.getDefaultAlphabet() is what I had in mind.
:)

> It's right that in this case tha pixmap would be larger ! And it could
> be difficult to manage it efficiently.

Maybe it would be a good idea to add an EXTENDED_ASCII alphabet to
Alphabet.java that contains all the characters from 40 to 255 in the
ASCII table (except these "border" characters of course). This would
cover most roman languages and makes an explicit alphabet switch
unnecessary.

>
> To summarize all about Alphabet :
> 1. Add a Alpahabet.getDefaultAlphabet()
> 2. Add a Font.getDefaultFont() and Label.getDefaultFont() (returns a
> Font that uses the default Alphabet)
>
> Am I right ?

Yes, perfectly right! My apologies again for the confusion earlier in
this discussion.

Cheers,

Johannes