Keyword expansion

[Johannes Schaback]

Hi,

I enabled the keyword expansion feature in SVN such that we get the
$author$ and "$Revision$ tag expanded again. This required to touch
every file such that every file had to be submitted to the svn again.
So dont wonder about the flood of files on your next update :)

Johannes

[Johannes Schaback]

you also got to modify a configuration file to make the keywords
expansion performed on every commit: Find the file 'config' in the
Subversion folder (on Windows its in c:/Document and
Settings/[username]/Application Data/Subversion) and modify it in such
way that it contains the following lines:

enable-auto-props = yes

[auto-props]
*.java = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Date
Author Id Revision HeadURL

Note that the last line starting with *.java is supposed to be one
single line (gmail might break this line)

Johannes

[Johannes Schaback]

It is very important that you setup subversions 'config' file BEFOR
you perform the next update!

[Boris Beaulant]

Ok, but isn't it a good moment to define a comment template for file,
type, etc ...?
Something like the attached file (eclipse only) ;)

Happy coding,
Bo

Johannes Schaback a écrit :

[Boris Beaulant]

Hi,

A small question about depth test flag :
Why the gl.glEnable(GL_DEPTH_TEST); and gl.glDepthFunc(GL_LEQUAL);
methods are useful in FengGUI ?

Thanks,
Bo

[Johannes Schaback]

Hi Boris,

yeah, please check out the 'make' directory, where I placed a code
template file and a code formatter file for Eclipse :)

Johannes

[Boris Beaulant]

Johannes Schaback a écrit :

> Hi Boris,
>
> yeah, please check out the 'make' directory, where I placed a code
> template file and a code formatter file for Eclipse :)
>

Ho yes ... sorry I had not seen it ;)
But in this template the 'file comment' is an empty javaDoc comment. But
in some classes I can found this :

/*
* FengGUI - Java GUIs in OpenGL (http://www.fenggui.org)
*
* Copyright (c) 2005, 2006 FengGUI Project
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details:
* http://www.gnu.org/copyleft/lesser.html#TOC3
*
* Created on Apr 18, 2005
* $Id: Graphics.java 28 2006-10-05 01:37:07Z schabby $
*/

Isn't it preferable to keep that ?

Bo

[Johannes Schaback]

A year ago, I experimented with several ways to draw windows
overlapped on the display (or in other container).

For the first approach I set up the projections matrix in othrogonal
projection mode and assigned z (depth) values to the widgest such that
they were drawn above or beneath each other. Although this way seemed
the natural way to go, it had several drawbacks which I will not
explain in detail here because it would require me to explain how I
made use of the z-coordinate.

The second approach (and the one we are still using today) is that the
effect of overlapping widgets is achieved exclusively by the ORDER in
which they are rendered. This way FengGUI really draws only on a 2D
plane. This actually renders the depth test obsolete, because we do
not an actual depth test. In other words: all FengGUI widgets have the
same distance to the viewer, such that the depth mask has to pass all
incoming pixels.

Long story short, we could savely disable the depth test. It is a
relict of the old days. You probably noticed the line
//TODO many of these commands are redundant
in the beginning of the setupStateVariables method.

However, please do not modify this code as it is crucial for FengGUI.
I will clean up the method myself when we start optimizing FengGUI.

Johannes

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Johannes Schaback]

> Isn't it preferable to keep that ?

Uh, yes! It is probably not totally up to date (i remember that I
changed a few things to the formatter Yesterday. I will export my most
recent version immediatly. Thx for brining this up

Johannes

[Boris Beaulant]

Tthanks for your long story ;) !
It's ok I do not modify this code, but at present it break all my GUI
when running in my game implementation. ;(

Bo

Johannes Schaback a écrit :

[Boris Beaulant]

I saw in the QTtheme's pixmap that ScrollBar slider are drawed for
Default, MouseOver and Pressed State. But it's not used, and there no
such states in Slider (DefaulState only). Is this only future feature ?
Is it possible to implement it ?

Bo

Johannes Schaback a écrit :

[Johannes Schaback]

> It's ok I do not modify this code, but at present it break all my GUI
> when running in my game implementation. ;(

Hmm, that's odd! In which way affects the depth test your GUI code?!?!

Johannes

[Johannes Schaback]

Hmm, I am not sure what you mean? :)

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Boris Beaulant]

My game's scene use depth test, and then GUI is not always render on
top, because of it's z value

Johannes Schaback a écrit :

[Boris Beaulant]

With a Button widget, you can set different texture for Default,
MouseOver or Pressed state, but on ScrollBar slader it seems that you
can't ... ;(

Johannes Schaback a écrit :

[Johannes Schaback]

Ah, that's interesting, because this should never happen actually. Are
you sure that you render FengGUI at the very end of your render loop?

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Johannes Schaback]

Can you send me the XML snippet in which you try to set a pixmap in
the ScrollBar? It is likely that this is a bug. :)

Johannes

[Boris Beaulant]

Yes FengGUI is rendered at the very end of your render loop . What is
the z value of FengGUI ?

Johannes Schaback a écrit :

[Boris Beaulant]

Johannes Schaback a écrit :

> Can you send me the XML snippet in which you try to set a pixmap in
> the ScrollBar? It is likely that this is a bug. :)
>

[...]
<ScrollBar>
<ScrollSlider>

<lineColor>
<Color rgba="0, 0, 0, 0"/>
</lineColor>

<HorizontalSliderButton>

<DefaultState>
<border>
<PixmapBorder
ref="horizontalSliderDefaultStateBorder"/>
else have got a stage thing there, because if I
define my pixmapborder outside it is correct, else the corner right,
edge top, bottom textures are wrong !
</border>
<background>
<PixmapBackground scaled="true">
<Pixmap x="27" y="2" width="1" height="9">
<Texture ref="DefaultStatePixmap" />
</Pixmap>
</PixmapBackground>
</background>
<Alignment value="middle" />
<Pixmap x="28" y="2" width="9" height="9">
<Texture ref="DefaultStatePixmap" />
</Pixmap>
<lineColor>
<Color rgba="0, 0, 0, 150"/>
</lineColor>
</DefaultState>

<MouseOverState>
... Here is it possible to do this ?
</MouseOverState>

</HorizontalSliderButton>

<VerticalSliderButton>

<DefaultState>
<border>
<PixmapBorder
ref="verticalSliderDefaultStateBorder"/>
</border>
<background>
<PixmapBackground scaled="true">
<Pixmap x="45" y="5" width="9" height="1">
<Texture ref="DefaultStatePixmap" />
</Pixmap>
</PixmapBackground>
</background>
<Alignment value="middle" />
<Pixmap x="45" y="6" width="9" height="9">
<Texture ref="DefaultStatePixmap" />
</Pixmap>
</DefaultState>

<MouseOverState>
... Here is it possible to do this ?
</MouseOverState>


</VerticalSliderButton>

</ScrollSlider>
</ScrollBar>

[Boris Beaulant]

Ho, yes an other question ... ;)

To implements my LeftTitleBarWindow, I need to set the Label
orientation. But at present it's not possible. What, in you opinion is
the best way to do this ?
- Generate a rotated char pixmap (I think it's not the best way : to heavy)
- Rotate the mesh on render phase (Light, but for the Label, the text
width become the height, and the height, the width ...)

I 've played with the Graphics.drawString() (add gl.rotate(...) ), and I
obtain a quite good result, but what do you think about that ?
You can see an exemple with rotation of 45° on all drawString()'s text
in attached file ...

Happy coding,
Bo

[Johannes Schaback]

Hmm, the actualy z value depends on your current projection and model
matrix. Both matrices are reset to default values before rendering
FengGUI. The z value used in FengGUI is z=0, because we only use
glVertex2i(...), not glVertex3x. You probably mean the distance of the
widgest to the viewer? It is 0 too.

Have you tried rendering FengGUI with the depth test disabled?

However, if widgets are partially occluded in your game, we may have a
serious problem! I would like to investigate that. Can you send a
screenshot as a first analysis? :P FengGUI takes screenshots by
pressing F12

Johannes

[Johannes Schaback]

Hi Boris,

Yeah, now we got one of the transformation we were talking about a
couple of days ago.

I would like to solve the issued as follows:
1) add a method 'public void rotate(float rad)' to IOpenGL that sets
the current model view matrix to rotate incomming vertices around the
z-axis.
2) Adjust LWJGLOpenGL and JOGLOpenGL accordingly
3) copy the code from Graphics.drawString in a method
Graphics.drawRotatedString(...) and perform the rotation before you
draw the string. Make use of the matrix stack (push and pop) to ensure
that later vertices dont get affected by your rotation.

Johannes

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:

[Johannes Schaback]

As for the PixmapBorder question I recommend the reading
http://fenggui.sourceforge.net/dokuwiki/doku.php?id=tut:pixmapborder:pixmapborder
:) Thanks to Josh it contains no mistakes anymore :)

As for the question concerning the <MouseOverState> element: yeah,
this works. <VerticalSliderButton> is parsed by the very same SAX
handler as <Button> such that <VerticalSliderButton> can contain the
same subelements.

Johannes

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Johannes Schaback]

Uh, I got you wrong with the pixmap border question. The answer is
yes, you can define your Pixmap border elsewhere and simply refer to
it by <PixmapBorder
ref="horizontalSliderDefaultStateBorder"/> :)

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

[Boris Beaulant]

Johannes Schaback a écrit :

> Hmm, the actualy z value depends on your current projection and model
> matrix. Both matrices are reset to default values before rendering
> FengGUI. The z value used in FengGUI is z=0, because we only use
> glVertex2i(...), not glVertex3x. You probably mean the distance of the
> widgest to the viewer? It is 0 too.
>

Ok, the problem is here, our z is [-1, 1] ... the default range

> Have you tried rendering FengGUI with the depth test disabled?
>

Yes and it works fine, that why I ask you about the interest of depth
test in FengGUI ;)

Bo

[Johannes Schaback]

ok, I gonna remove the depth test permanently. I file a
feature-request for that...

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Boris Beaulant]

Johannes Schaback a écrit :

> Hi Boris,
>
> Yeah, now we got one of the transformation we were talking about a
> couple of days ago.
>
> I would like to solve the issued as follows:
> 1) add a method 'public void rotate(float rad)' to IOpenGL that sets
> the current model view matrix to rotate incomming vertices around the
> z-axis.
> 2) Adjust LWJGLOpenGL and JOGLOpenGL accordingly
> 3) copy the code from Graphics.drawString in a method
> Graphics.drawRotatedString(...) and perform the rotation before you
> draw the string. Make use of the matrix stack (push and pop) to ensure
> that later vertices dont get affected by your rotation.
>
> Johannes
>

Good ... it's very near of what I did ;) !

[Boris Beaulant]

Johannes Schaback a écrit :

> Uh, I got you wrong with the pixmap border question. The answer is
> yes, you can define your Pixmap border elsewhere and simply refer to
> it by <PixmapBorder
> ref="horizontalSliderDefaultStateBorder"/> :)
>

Ho yes I know that, it very usfull, but the problem is that if you use
the 'ref' method, it do not do the same result has define the
PixmapBorder directly inside the <border> tags.

XML :

<PixmapBorder name="verticalSliderDefaultStateBorder">
<topLeftCorner>
<Pixmap x="43" y="0" width="2" height="4">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</topLeftCorner>

<topEdge>
<Pixmap x="45" y="0" width="8" height="4">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</topEdge>

<topRightCorner>
<Pixmap x="54" y="0" width="2" height="4">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</topRightCorner>

<rightEdge>
<Pixmap x="54" y="4" width="2" height="1">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</rightEdge>

<bottomRightCorner>
<Pixmap x="54" y="17" width="2" height="4">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</bottomRightCorner>

<bottomEdge>
<Pixmap x="45" y="17" width="8" height="4">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</bottomEdge>

<bottomLeftCorner>
<Pixmap x="43" y="17" width="2" height="4">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</bottomLeftCorner>

<leftEdge>
<Pixmap x="43" y="4" width="2" height="1">

<Texture ref="DefaultStatePixmap" />
</Pixmap>

</leftEdge>
</PixmapBorder>

- When using by <PixmapBorder ref="verticalSliderDefaultStateBorder"/>
---> ref.png
- When using by copy / paste the definition above ---> inside.png

[Johannes Schaback]

Yes, from your screenshot I see the you modified the regular
drawString code. My plan is to have an additional method
drawRotatedString or something like that.

An aside about the Graphics.java. In the far future, we will need top
optimize things a little in FengGUI (Display lists, less state changes
in opengl etc.). We will probably pull a lot of code out of
Graphics.java directly in the widgets to gain peak performance. For
example TextEditor will draw the entire text at once, instead if
repeated drawString(..) calls for every line. But dont worry about
that at the moment.

Johannes

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Johannes Schaback]

Hmm, this smells like a bug... because that should not happen actually.

Are you sure that there is no other element that sets
name="verticalSliderDefaultStateBorder"?

I got to think about that a little more...

Johannes

On 10/5/06, Boris Beaulant <b...@ankama.com> wrote:

[Boris Beaulant]

Yes I sure ;). The strange thing is that the texture aren't render in
the right place or at right size !

Johannes Schaback a écrit :

[Boris Beaulant]

Can I start to implement this idea ?
Bo

Johannes Schaback a écrit :

[Johannes Schaback]

yes. Please do so.

Thanks!

Johannes

[Johannes Schaback]

Odd indeed. I still have no clue what might cause this effect. I will
try to reproduce the bug in the QtCurve theme...

Johannes

On 10/6/06, Boris Beaulant <b...@ankama.com> wrote:
>

[Johannes Schaback]

Boris, for the time being, can you put that bug on the bug tracker?
Thx, Johannes

[Johannes Schaback]

Hi Boris, I cannot reproduce the bug. Both methods to define a pixmap
border work perfectly for me (by reference and by inline). However, I
updated the PixmapBorderTheme code such that it resets all pixmaps to
null before it starts parsing a <PixmapBorder> element. Does the
problem remain?

[Esa Tanskanen]

Hi,

My solution for implementing references in the InputOutputStream was to make
it both stealthed and free from the storage implementation. It's fully
configurable, you can change the names of the used XML attributes (name and
reference).

It also now throws a proper exceptions if the element to which the
"ref"-attribute refers to can't be found or is of an incompatible type. So
instead of the current way in the theme loading code, which just throws a
ClassCastException somewhere (and the user has to play detective to find out
what happened), it outputs the following kind of an exception:

org.fenggui.io.ChildConstructionException: the element
testRoot.testAnotherChild.testChild refers to an another element
'myOtherReference', but that element can't be found in the context

<testAnotherChild data="collection" value="50">
<testChild name="blaa" first-name="Matti" last-name="Meikäläinen"
foo="4444"/>
<testChild first-name="Mikko" last-name="Koljonen" foo="12345"/>
<testChild ref="myReference"/>
--> <testChild ref="myOtherReference"/>
<testChild first-name="Matti" last-name="Meikäläinen" foo="4444"/>
</testAnotherChild>

As you see, it even shows where in the XML document the problem occured!

Also, it now defines a context system for the XML document. Here's an
example of what I mean:

<testRoot data="rootdata" value="1">
<testChild name="myReference" first-name="Jaakko" last-name="Joro"
foo="22"/>

<testAnotherChild data="blaa" value="5">
<testChild name="myOtherReference" />
</testAnotherChild>

<testAnotherChild data="collection" value="50">
<testChild ref="myReference"/> <!-- OK -->
<testChild ref="myOtherReference"/> <!-- Error -->
</testAnotherChild>
</testRoot>

As you see, the elements inside the "collection"-element can't see the
elements inside the "blaa"-element. Also, the system uses the name hiding
principle:

<testRoot data="rootdata" value="1">
<font name="myReference" systemName="arial" size="22"/>

<label ...>
<color name="myReference" value="255, 255, 255, 255" />
<color ref="myReference" /> <!-- OK -->
</testAnotherChild>
</testRoot>

The element named "myReference" inside the label-element hides the font with
the same name, so the reference is perfectly unambiguous.

So what do you think? :)

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

[Boris Beaulant]

Johannes Schaback a écrit :

> Hi Boris, I cannot reproduce the bug. Both methods to define a pixmap
> border work perfectly for me (by reference and by inline). However, I
> updated the PixmapBorderTheme code such that it resets all pixmaps to
> null before it starts parsing a <PixmapBorder> element. Does the
> problem remain?
>

Yes it seem to solve the problem ;) !
Thanks !
Bo

[Boris Beaulant]

Johannes Schaback a écrit :

> yes. Please do so.
>
> Thanks!
>
> Johannes
>

Good, I've commited this. You can try to play with it ;)

Label and LeftTitleBarWindow have been updated too.

You can try it in the LabelExemple...

Bo

[Boris Beaulant]

At present I've got a compilation error with the last SVN update :

"AnotherTestIOSaveable cannot be resolved to a type" in file
org.fenggui/test/org/fenggui/io/main.java

Bo

[Esa Tanskanen]

Ah damnit, I forgot to include that file in the commit. Now it's there :)

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

[Boris Beaulant]

Thank for the resizable window Johannes !!!!
It's very nice !!!

[Johannes Schaback]

Hi Esa,

I carfully read your mail to understand exactly what you implemented.
I got to say that your proposal is extremly nifty! Especially the
context dependent reference resolution. But that is also my complaint.
It is a bit too complicated from my point of view.

> It also now throws a proper exceptions if the element to which the
> "ref"-attribute refers to can't be found or is of an incompatible type. So
> instead of the current way in the theme loading code, which just throws a
> ClassCastException somewhere (and the user has to play detective to find out
> what happened), it outputs the following kind of an exception:

Yeah, that is great! We definitely need something like that. Debugging
the theme XML file was very painful. Good work!

> Also, it now defines a context system for the XML document. Here's an

Well yeah, that's what I believe is hard to grasp for beginners (or
artists :P). In addition I often define a reference in a subtree of my
theme file somewhere and want to refer to that reference in another
subtree, which will not not visible in your proposed implementation.

A globally visible reference resolution mechanism is my prefered choice here.

> Also, the system uses the name hiding [...]

That means that names are type dependent, right? E.g. a font reference
called "myRef" is not the same reference for a color that is also
defines as "myRef". Did I understand that correctly?

I would prefer to throw an exception if a reference is defined that
has already been defined earlier. I believe this would make the hole
concept easier because errors are reported immediatly which in turn
will make debugging easier for the artist.

What do you think? :)

Johannes

[Esa Tanskanen]

>I carfully read your mail to understand exactly what you implemented.
>I got to say that your proposal is extremly nifty! Especially the
>context dependent reference resolution. But that is also my complaint.
>It is a bit too complicated from my point of view.

Compicated in what way? Do you mean what you said later:

>Well yeah, that's what I believe is hard to grasp for beginners (or
>artists :P). In addition I often define a reference in a subtree of my
>theme file somewhere and want to refer to that reference in another
>subtree, which will not not visible in your proposed implementation.

Of course, there could be a way to use both global and context resolution.
One way would be a "global:" -prefix for the names, but maybe that would be
too complicated (as well as would having a global="yes" attribute). An
another way would be to be able to refer to the element with a dot notation
(for example, myBorders.myCoolBorder).

It's easy to make this functionality toggable, though.

> > Also, the system uses the name hiding [...]
>
>That means that names are type dependent, right? E.g. a font reference
>called "myRef" is not the same reference for a color that is also
>defines as "myRef". Did I understand that correctly?

Nope, the names are not type dependant. What I mean is that the color was
"closer" in the hierarchy, so it shadows the name outside of it. But this
could be very easily made to also throw an exception.

I've implement your purposed changes in the code, I'll make a commit soon.

[Esa Tanskanen]

The recent checkout caused the following compiling errors:

Severity and Description Path Resource Location Creation Time Id
FontSAXHandler cannot be resolved to a
type fenggui-svn/src/org/fenggui/render Font.java line
93 1160146863781 84501
FontSAXHandler cannot be resolved to a
type fenggui-svn/src/org/fenggui/render Font.java line
93 1160146863781 84502
The import org.fenggui.util.FontSAXHandler cannot be
resolved fenggui-svn/src/org/fenggui/render Font.java line
36 1160146863781 84498
The method contains(int, int) is undefined for the type
Rectangle fenggui-svn/src/org/fenggui/text TextRun.java line
115 1160146865250 84696

Also, should I go and change the org.fenggui.xml.theme to use the new I/O
system?

>From: "Esa Tanskanen" <fladim...@hotmail.com>
>Reply-To: FengGUI-D...@googlegroups.com
>To: FengGUI-D...@googlegroups.com

_________________________________________________________________
Uutisista turhaan tietoon. Mitä ikinä etsitkin, MSN Search löytää hakemasi.
http://search.msn.fi

[Johannes Schaback]

Hi Esa,

> Of course, there could be a way to use both global and context resolution.
> One way would be a "global:" -prefix for the names, but maybe that would be
> too complicated (as well as would having a global="yes" attribute). An
> another way would be to be able to refer to the element with a dot notation
> (for example, myBorders.myCoolBorder).

I like the dot notation! (myBorders.myCoolBorder) This gives the whole
thing a object oriented flavor (well... actually more like structs in
C). And that's a concept peole know already and makes all references
publicly accesible.

> Nope, the names are not type dependant. What I mean is that the color was
> "closer" in the hierarchy, so it shadows the name outside of it. But this
> could be very easily made to also throw an exception.

Oh, ok. I misunderstood you. In terms of the dot notation it makes
sense to leave it that way. References like myBorder.coolFont and
myLabel.coolFont are then possible although both coolFont attributes
contain different values.

Johannes

[Johannes Schaback]

> The recent checkout caused the following compiling errors:

That's odd. My sources compile smoothly.

> Also, should I go and change the org.fenggui.xml.theme to use the new I/O
> system?

Yes Please!!

Johannes

[Esa Tanskanen]

OK, maybe it was just that the project wasn't properly refreshed in Eclipse.
It works now...

It seems that I won't be having free time before Sunday (it's Friday after
all ;) but then I guess doing the required modifications to the theme
loading won't take that long.

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

_________________________________________________________________