fenggui-development — development related discussions take place here

post on "migration to jSeamless"

[Johannes S. <joh...@gm...>]

Hi interested FengGUI users and not-so-active developers,

There is a recent post on our forum
(http://www.fenggui.org/forum/index.php?topic=95.0) that suggests to
make FengGUI become the opengl binding for jSeamless which claims to
be an UI abstraction layer is abstract enough to handle different
rendering peers (Flash, XHTML, Swing, OpenGL, etc.). It is my
understanding that this joint venture would mean to take the event
handling, naming scheme, structure and compontens of jSeamless for
granted and concentrate on the part to get jSeamless renderered in
OpenGL. As I can see the pros and cons for either sides, I would like
ask you for some comments on that.

I have not digged on the source code yet, so I cannot answer questions
like whether it is actually doable to render jSeamless with OpenGL...
So this is more are general and maybe strategic question :)

What do you think?

Thanks, Johannes

SVN comment for last patch

[Johannes S. <joh...@gm...>]

Hi,

I forgot to comment my last (small) svn commit: I started to work on a
GridBagLayout manager as it has been requested on the forum. It's a
quite complicated one, so you better dont use it at the moment.

Johannes

New methods in IOpenGL

[Whackjack <wha...@gm...>]

All,
  Okay, I've made a decent sized change in IOpenGL to support the glGet*()
methods that both LWJGL and JOGL provide.
These methods return an array of the corresponding type that contain the
results of the call. However, since LWJGL and JOGL
both provide their own sets of OpenGL constants, I needed to add an
abstraction over that.  The result is IOpenGL.Attribute.
Attribute is a Java enum that represents the native OpenGL attribute.  It is
up to the corresponding IOpenGL implementation to
map an Attribute to its own integer value.
  Allow me to provide an example:

public int getLineWidth(IOpenGL gl)
{
    // I know that GL_LINE_WIDTH is only one integer, not an array of them
like GL_PROJECTION_MATRIX
    return gl.getInteger(IOpenGL.Attribute.LINE_WIDTH)[0];
}

  I'm aware that this is a bit cumbersome, but I couldn't think of another
way to do this.  Note that in the Attribute enum,
there is no GL_ prefix for each attribute.  I did this on purpose to avoid
confusion with LWJGL's and JOGL's static values.
Currently, the only values I have in there are CURRENT_COLOR and
LINE_WIDTH.  Feel free to add more if you need them.
The only rules should be that you follow the naming convention and PLEASE
keep them in alphabetical order.
  As for how this "enum -> static int" mapping happens in each IOpenGL
implementation, there is currently a private method
called getAttrib() in each of the implementations to look it up (right now,
just a switch/case).  The lookup method is not defined
on IOpenGL because that is an implementation detail that the upper layers
don't need to know about.
  I am aware of the practical limitation of the current switch/case lookup
method, so perhaps as it gets larger, we'll need to come
up with a more scalable approach (maybe a Map or a properties file).
  Please let me know if you run into any issues and I'll try to address them
ASAP.

Thanks,

Josh K

Re: Additional GL functions in IOpenGL

[Johannes S. <joh...@gm...>]

Hi Josh!

It's no problem to extend IOpengl. Just make sure that they do the
same on LWJGL and JOGL :)

Johannes

On 4/17/07, Whackjack <wha...@gm...> wrote:
> All,
>   I was wondering if we could add some more OpenGL functions to the IOpenGL
> interface. Specifically, the glGet() functions.
> I have need of retrieving some GL attributes, but I discovered there was no
> way to get to them (at least not that I could see).
> I know these are exposed in LWJGL and I assume they are in JOGL as well.
>
> Thanks!
>
> Josh K
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>

Additional GL functions in IOpenGL

[Whackjack <wha...@gm...>]

All,
  I was wondering if we could add some more OpenGL functions to the IOpenGL
interface. Specifically, the glGet() functions.
I have need of retrieving some GL attributes, but I discovered there was no
way to get to them (at least not that I could see).
I know these are exposed in LWJGL and I assume they are in JOGL as well.

Thanks!

Josh K

Re: LWJGL file inclusion

[Johannes S. <joh...@gm...>]

Hi Josh!

yeah, it makes some trouble to get FengGUI running with LWJGL (it's no
problem for JOGL because it comes along with the current JRE). The
reasons why we havent included ALL necessary files in the project is
that everybody runs a different configuration. Three of us have a
windows box, Rainer uses Linux and others (Nolan I as far as I
remember) have a Mac. But that's actually no good argument against
keeping all necessary native libs in a separate folder so that people
can chose which platform libraries they want to use.

Do you mind copying the latest LWJGL stuff in a folder in
'third-party'? We need to update to the latest LWJGL anyway. Thanks a
lot in advance :)

Johannes



On 4/10/07, Whackjack <wha...@gm...> wrote:
> Hi all,
>   Earlier, I attempted to run some of the examples but ran into a library
> problem.  It doesn't look like the FengGUI repository includes the native
> libraries for LWJGL.  Whether or not FengGUI should redistribute third-party
> libraries is a different conversation.  My complaint is that it included the
> JAR, but not the native libraries.  When I downloaded the latest LWJGL
> binaries and added those native libraries to the path, it failed because of
> version mismatching.  I had to import the newest LWJGL JAR file in the path,
> instead of using the one that comes with FengGUI.
>   I guess my problem with all this is dependency management.  If we're going
> to include any part of a third-party library, I believe we should include
> everything that's needed to make it fully functional (or at least not fail
> at runtime).  Of course, we could go the other way and not include LWJGL in
> the repository and just mandate a separate download, which I don't have a
> problem with.  Let's see if we can't work this out on this email thread.
>
> Thanks!
>
> Josh K
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>

LWJGL file inclusion

[Whackjack <wha...@gm...>]

Hi all,
  Earlier, I attempted to run some of the examples but ran into a library
problem.  It doesn't look like the FengGUI repository includes the native
libraries for LWJGL.  Whether or not FengGUI should redistribute third-party
libraries is a different conversation.  My complaint is that it included the
JAR, but not the native libraries.  When I downloaded the latest LWJGL
binaries and added those native libraries to the path, it failed because of
version mismatching.  I had to import the newest LWJGL JAR file in the path,
instead of using the one that comes with FengGUI.
  I guess my problem with all this is dependency management.  If we're going
to include any part of a third-party library, I believe we should include
everything that's needed to make it fully functional (or at least not fail
at runtime).  Of course, we could go the other way and not include LWJGL in
the repository and just mandate a separate download, which I don't have a
problem with.  Let's see if we can't work this out on this email thread.

Thanks!

Josh K

Re: Labels ...

[Johannes S. <joh...@gm...>]

Hi Boris!

Sorry for answering so lately.

> I'd like to talk about an issue about Labels. Labels set their minSize
> accordingly to the text they contain. In some cases, it results in a broken
> layout.

Yeah, if the text or the pixmap of a label changes and the size of the
label is not big enough than the layout is screwed up. This does not
only apply to Label but also to every other widget. As a matter of
fact each GUI library struggles with that issue and they have
different ways to solve it.

If the content of a widget becomes too large, then the content gets
clipped at the border of the widget.

> If we have a Label with dynamic content, and if the content is
> suddenly very long, the container is forced to adapt, and can look strange.

Uh, there is an important distinction: the Container does only
ACTIVELY adapt the minSize, not the actual size! Because the
updateMinSize() calls go up in the widget tree while the layout()
calls only decent (!) the widget tree from the containers to the
widgets (leafs).

> Could it be possible to add some kind of optional maxSize to ITextWidget
> ?

Hmm, I think a special solution for ITextWidget wouldnt be a good
idea. Either we extend every widget with the additional dimension
attribute maxSize or we dont do it at all. From my experience (boohoo)
I can tell that as few dimension attributes as possible are easier to
handle in the layout managers.

> Another way to look at it could be to create a textRenderer which
> replace "a Very Long and Useless Label" by "A Very Lo..." if we assign
> it a width (in pixel).

That's a good idea. In fact I implemented that sort of cut-off
renderer for Table. Might be that you can copy-paste some code there.
I suggest to copy (or subclass) DirectTextRenderer to
BoundedTextRenderer which has an additional width attribute according
to which it cuts of the string and replaces the last few letters with
periods.

> PS : addWidget(IWidget w, int index) done ...

yeah, I saw it. great job! Thanks!


Johannes

Labels ...

[Boris B. <bo...@an...>]

Hi all,

I'd like to talk about an issue about Labels. Labels set their minSize 
accordingly to the text they contain. In some cases, it results in a broken
layout. If we have a Label with dynamic content, and if the content is 
suddenly very long, the container is forced to adapt, and can look strange.

Could it be possible to add some kind of optional maxSize to ITextWidget 
? Another way to look at it could be to create a textRenderer which 
replace "a Very Long and Useless Label" by "A Very Lo..." if we assign 
it a width (in pixel).

What do you think about it ?
Looking forward to read your answer.

Bo

PS : addWidget(IWidget w, int index) done ...


Johannes Schaback a écrit :
> Hi everyone!
>
> @Boris, First of all thanks a ton for all the patches!! I havent
> browsed through all your work yet but I noticed one minor thing that I
> would like to suggest:
> You added an addToEnd and addToStart (or similar) methods to
> Container. I would rather like to have a method addWidget(IWidget w,
> int index) that takes the widget to be added as well as an index where
> to put the widget in the container list.
>
> as a side note: you (Boris) pointed out a valid issue in the comment
> of the SVN commit I just talked about. The concenpt how FengGUI
> realizes the z-layers in Display (for windows) is probably not the
> smartest one. I hope to replace the whole window-Display-z-layer-issue
> by a little Window Manager implementation someday.
>
> Btw, does anyone feel like taking care of making it possible to render
> Container on a texture? This is an interessting and rewarding
> challenge. I am currently too busy with my non-FengGUI live (shame on
> me)  to do it myself...
>
> Johannes
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>
>   

Minor things such as z-layers, window manager and rendering FengGUI to textures

[Johannes S. <joh...@gm...>]

Hi everyone!

@Boris, First of all thanks a ton for all the patches!! I havent
browsed through all your work yet but I noticed one minor thing that I
would like to suggest:
You added an addToEnd and addToStart (or similar) methods to
Container. I would rather like to have a method addWidget(IWidget w,
int index) that takes the widget to be added as well as an index where
to put the widget in the container list.

as a side note: you (Boris) pointed out a valid issue in the comment
of the SVN commit I just talked about. The concenpt how FengGUI
realizes the z-layers in Display (for windows) is probably not the
smartest one. I hope to replace the whole window-Display-z-layer-issue
by a little Window Manager implementation someday.

Btw, does anyone feel like taking care of making it possible to render
Container on a texture? This is an interessting and rewarding
challenge. I am currently too busy with my non-FengGUI live (shame on
me)  to do it myself...

Johannes

Re: Color changes

[Johannes S. <joh...@gm...>]

Hi Josh!

Adding the colors specified in SVG 1.1 is totally fine for me. The
simplest way to do that would probably to extend colorMap in the
static constructor (line 196) like colorMap.put("firebrick", new
Color(178f/255f, 34f/255f, 34f/255f)); Extending the pre-defined list
of public final static colors, e.g. like public static final Color
FIREBRICK = new Color(178f/255f, 34f/255f, 34f/255f); is also totally
fine for me.

Thanks for bringing this up!

Johannes

On 3/26/07, Whackjack <wha...@gm...> wrote:
> All,
>   To accommodate the upcoming addition of SVG support to FengGUI, we'll need
> to make a few changes.
> Luckily, these changes should not impact anything greatly.  The first of
> these changes is to the Color class.
> The SVG spec defines many colors that are not currently listed in the Color
> class or may not have the same
> values.  I propose amending the Color class to include/update its list of
> pre-defined colors to match what
>  is defined in the SVG spec (specifically, to the color list in the
> following link):
>
> http://www.w3.org/TR/SVG11/types.html#ColorKeywords
>
> Again, the impact of this should be minimal and if nothing else, will
> provide non-SVG using developers a great
> many more pre-defined colors.
> Please let me know what you think.
>
> Josh K
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>

Color changes

[Whackjack <wha...@gm...>]

All,
  To accommodate the upcoming addition of SVG support to FengGUI, we'll need
to make a few changes.
Luckily, these changes should not impact anything greatly.  The first of
these changes is to the Color class.
The SVG spec defines many colors that are not currently listed in the Color
class or may not have the same
values.  I propose amending the Color class to include/update its list of
pre-defined colors to match what
is defined in the SVG spec (specifically, to the color list in the following
link):

http://www.w3.org/TR/SVG11/types.html#ColorKeywords

Again, the impact of this should be minimal and if nothing else, will
provide non-SVG using developers a great
many more pre-defined colors.
Please let me know what you think.

Josh K

Re: FengGUI and SVG

[Johannes S. <joh...@gm...>]

Yipp, you got write access to the SVN. It may be clever to create an
additional source folder for your sub-project, because you will
probably need many third-party libraries and we can separate the SVG
stuff a little from the core FengGUI stuff. What do you think?

Johannes

On 3/26/07, Whackjack <wha...@gm...> wrote:
> Actually, on second thought, it looks like I might have access already.
> Thanks!
>
> Josh K
>
>
> On 3/25/07, Whackjack < wha...@gm...> wrote:
> > Excellent!  This should be a lot of fun =).  Would you be able to get me
> SVN access to the project?
> > I've done some researching, and I think I'm ready to begin coding.  I'll
> start another thread about the
> > design based on what I've learned about SVG so far.
> >
> > Josh K
> >
> >
> >
> > On 3/24/07, Johannes Schaback < joh...@gm... > wrote:
> > > Hi Josh!
> > >
> > > Fantastic! There is nobody working on that. In fact it was me who
> > > added this request to the list :)
> > >
> > > A FengGUI extension that makes it possible to render SVG files in
> > > FengGUI will be an extremely valuable feature and place FengGUI in a
> > > very good position in the GUIs-on-gl niche. So, yes, please go for it!
> > > This would be terrific!!
> > >
> > > Buzz me on my Google Talk whenever you want. This is project will be
> > > very exciting!
> > >
> > > Johannes
> > >
> > > On 3/21/07, Whackjack < wha...@gm... > wrote:
> > > > All,
> > > >   I was looking at the front page of the FengGUI wiki and saw that
> there is
> > > > a desire to render SVG documents using Batik.
> > > > Is anyone currently working on this?  If not, I'd love to tackle this.
>  I'm
> > > > in desperate need of something to do :-P.
> > > >
> > > > Josh
> > > >
> > > >
> -------------------------------------------------------------------------
> > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > > > opinions on IT & business topics through brief surveys-and earn cash
> > > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > _______________________________________________
> > > > Fenggui-development mailing list
> > > > Fen...@li...
> > > >
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
> > > >
> > > >
> > >
> > >
> -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > > opinions on IT & business topics through brief surveys-and earn cash
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Fenggui-development mailing list
> > > Fen...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
> > >
> >
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>

Re: FengGUI and SVG

[Whackjack <wha...@gm...>]

Actually, on second thought, it looks like I might have access already.
Thanks!

Josh K

On 3/25/07, Whackjack <wha...@gm...> wrote:
>
> Excellent!  This should be a lot of fun =).  Would you be able to get me
> SVN access to the project?
> I've done some researching, and I think I'm ready to begin coding.  I'll
> start another thread about the
> design based on what I've learned about SVG so far.
>
> Josh K
>
> On 3/24/07, Johannes Schaback <joh...@gm... > wrote:
> >
> > Hi Josh!
> >
> > Fantastic! There is nobody working on that. In fact it was me who
> > added this request to the list :)
> >
> > A FengGUI extension that makes it possible to render SVG files in
> > FengGUI will be an extremely valuable feature and place FengGUI in a
> > very good position in the GUIs-on-gl niche. So, yes, please go for it!
> > This would be terrific!!
> >
> > Buzz me on my Google Talk whenever you want. This is project will be
> > very exciting!
> >
> > Johannes
> >
> > On 3/21/07, Whackjack <wha...@gm... > wrote:
> > > All,
> > >   I was looking at the front page of the FengGUI wiki and saw that
> > there is
> > > a desire to render SVG documents using Batik.
> > > Is anyone currently working on this?  If not, I'd love to tackle
> > this.  I'm
> > > in desperate need of something to do :-P.
> > >
> > > Josh
> > >
> > >
> > -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > > opinions on IT & business topics through brief surveys-and earn cash
> > >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Fenggui-development mailing list
> > > Fen...@li...
> > > https://lists.sourceforge.net/lists/listinfo/fenggui-development
> > >
> > >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Fenggui-development mailing list
> > Fen...@li...
> > https://lists.sourceforge.net/lists/listinfo/fenggui-development
> >
>
>

Re: FengGUI and SVG

[Whackjack <wha...@gm...>]

Excellent!  This should be a lot of fun =).  Would you be able to get me SVN
access to the project?
I've done some researching, and I think I'm ready to begin coding.  I'll
start another thread about the
design based on what I've learned about SVG so far.

Josh K

On 3/24/07, Johannes Schaback <joh...@gm...> wrote:
>
> Hi Josh!
>
> Fantastic! There is nobody working on that. In fact it was me who
> added this request to the list :)
>
> A FengGUI extension that makes it possible to render SVG files in
> FengGUI will be an extremely valuable feature and place FengGUI in a
> very good position in the GUIs-on-gl niche. So, yes, please go for it!
> This would be terrific!!
>
> Buzz me on my Google Talk whenever you want. This is project will be
> very exciting!
>
> Johannes
>
> On 3/21/07, Whackjack <wha...@gm...> wrote:
> > All,
> >   I was looking at the front page of the FengGUI wiki and saw that there
> is
> > a desire to render SVG documents using Batik.
> > Is anyone currently working on this?  If not, I'd love to tackle
> this.  I'm
> > in desperate need of something to do :-P.
> >
> > Josh
> >
> >
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> > opinions on IT & business topics through brief surveys-and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Fenggui-development mailing list
> > Fen...@li...
> > https://lists.sourceforge.net/lists/listinfo/fenggui-development
> >
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>

Re: FengGUI and SVG

[Johannes S. <joh...@gm...>]

Hi Josh!

Fantastic! There is nobody working on that. In fact it was me who
added this request to the list :)

A FengGUI extension that makes it possible to render SVG files in
FengGUI will be an extremely valuable feature and place FengGUI in a
very good position in the GUIs-on-gl niche. So, yes, please go for it!
This would be terrific!!

Buzz me on my Google Talk whenever you want. This is project will be
very exciting!

Johannes

On 3/21/07, Whackjack <wha...@gm...> wrote:
> All,
>   I was looking at the front page of the FengGUI wiki and saw that there is
> a desire to render SVG documents using Batik.
> Is anyone currently working on this?  If not, I'd love to tackle this.  I'm
> in desperate need of something to do :-P.
>
> Josh
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Fenggui-development mailing list
> Fen...@li...
> https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>

Back from holidays

[Johannes S. <joh...@gm...>]

Hi, sorry guys, I have been away from home for a week and decided to
not take my computer along. That's why I have not replied on the forum
and to mails (yet).

Johannes

FengGUI and SVG

[Whackjack <wha...@gm...>]

All,
  I was looking at the front page of the FengGUI wiki and saw that there is
a desire to render SVG documents using Batik.
Is anyone currently working on this?  If not, I'd love to tackle this.  I'm
in desperate need of something to do :-P.

Josh

Re: Enabled / Disabled scrollBar

[Johannes S. <joh...@gm...>]

Hi Boris!

Thanks for adding the patch!

>Todo - find a solution to this problem : when you press a button and
> release the mouse outside the button, the release
>event isn't received.

Actually this is intended behavior. Otherwise there would be no way to
"cancel" a click on a button. Try that on any OS: Click on a button
and keep the mouse pressed. Then move the cursor from the button and
release the mouse. The button wont be pressed (i.e, the underlaying
action wont be executed).

Have fun!

Johannes


On 3/14/07, Johannes Schaback <joh...@gm...> wrote:
> Hi Boris!
>
> Yeah, we should add the possibility to disable ScrollBars and Sliders.
> Actually there is a bunch of remaining widgets for which it would make
> sense to have this features.
>
> Ok, anyway, let's do Slider and ScrollBar first.
>
> >     - By making Slider and ScrollBar ObservableWidget (but is it wise ?)
>
> This is the way to go. Checkout Button for an example on how to use
> the activation listener:
>
>   addActivationListener(new IActivationListener() {
>         public void widgetActivationChanged(ActivationEvent activationEvent)
>         {
>                 getAppearance().setEnabled(LABEL_DISABLED, true);
>         }});
>
> You can then conveniently setup the appearance for the disabled state
> via decorators.
>
> We may want to think about adding an isEnabled check to all event
> firing methods in ObservableWidget in order to only fire mouse and key
> events if the widget is actually enabled. Currently, we fire mouse and
> key events regardless if the widget is enabled or not.
>
> Thanks!
>
> Johannes
>

Re: Enabled / Disabled scrollBar

[Johannes S. <joh...@gm...>]

Hi Boris!

Yeah, we should add the possibility to disable ScrollBars and Sliders.
Actually there is a bunch of remaining widgets for which it would make
sense to have this features.

Ok, anyway, let's do Slider and ScrollBar first.

>     - By making Slider and ScrollBar ObservableWidget (but is it wise ?)

This is the way to go. Checkout Button for an example on how to use
the activation listener:

  addActivationListener(new IActivationListener() {
	public void widgetActivationChanged(ActivationEvent activationEvent)
	{
		getAppearance().setEnabled(LABEL_DISABLED, true);
	}});

You can then conveniently setup the appearance for the disabled state
via decorators.

We may want to think about adding an isEnabled check to all event
firing methods in ObservableWidget in order to only fire mouse and key
events if the widget is actually enabled. Currently, we fire mouse and
key events regardless if the widget is enabled or not.

Thanks!

Johannes

Enabled / Disabled scrollBar

[Boris B. <bo...@an...>]

Hi Johannes,

I would like to tell you about a problem we have. Currently, it is not 
possible to enable/disable Sliders and ScrollBars. I think it could be a 
nice improvement.
Examples :
- When the component needing a scrollbar is completly displayed, it 
could be nice to see the scrollBar turn gray and its buttons disabled 
too. The slider button inside it could even not be displayed.

- If the user of our application decided to lock some settings, the 
slider button sould not be able to move.

How to implement it : It may be done in many ways.
    - By moving the "enabled" attribute from ObservableWidget to 
StandardWidget.
    - By making Slider and ScrollBar ObservableWidget (but is it wise ?)
    - By implementing the "enabled" attribute in each Widget that need 
it... but that doesn't seem a good way to do it.

Tell me what you think about it. I'm looking forward to see your opinion 
on that subject.

Bo

Forum on FengGUI.org

[Johannes S. <joh...@gm...>]

Hi!

I just installed a little forum on FengGUI.org. I hope that our user
base will use it to report bugs, ask questions, express feature
requests, discuss future plans or just generally talk about (Feng-)GUI
related stuff.

Of course, it is pretty sparse on topics at the moment, so it would
awesome if you could register a user in the forum and add something to
the discussion from time to time so that the forum may hopefully
become a place for exchanging thoughts between us and our users.

http://www.fenggui.org/forum/index.php

cheers,

Johannes

Re: Combobox

[Rainer A. <ra...@ra...>]

Hey Johannes,

thanks a lot for implementing that feature ;) I'm going to test this in 
my game tomorrow (no wait...today ;) )
I'll also do some more changes/bug fixes as I'm going to revise all our 
FengGUI related code and maybe implement some features for the Table 
(cell renderer stuff...)


Greetings,
Rainer

-- 
DI(FH) Rainer Angermann
Rarebyte Game Development
web: http://www.rarebyte.com
mail: ra...@ra...
phone: +43 720 504298



Johannes Schaback schrieb:

>Hi Rainer,
>
>I added the feature we spoke about this afternoon to the trunk. The
>(popup-) list of a combo box that contains more elements than actually
>fit on the screen can now be scrolled.
>
>Cheers,
>
>Johannes
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys - and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Fenggui-development mailing list
>Fen...@li...
>https://lists.sourceforge.net/lists/listinfo/fenggui-development
>
>
>  
>

Combobox

[Johannes S. <joh...@gm...>]

Hi Rainer,

I added the feature we spoke about this afternoon to the trunk. The
(popup-) list of a combo box that contains more elements than actually
fit on the screen can now be scrolled.

Cheers,

Johannes

theme description via XML: type registry for widgets and decorators

[Johannes S. <joh...@gm...>]

Hi Esa,

I am currently removing all static calls to the TYPE_REGISTRY from the
widgets and decorators in order to replace them with a centralized way
to register all types the XML streaming facility in XMLTheme. In other
words, I remove the static blocks from the widgets and register all
widgets and decorators in XMLTheme to a type registry that is now also
in XMLTheme. This is pretty much what I suggested the last time we
talked about the type registry.

As you probably remember the ugliest problem with the static
registration calls in the widgets and decorators is that you have to
instantiate a widget before you can actually load its theme (because
the plain static block in the widget wont be executed otherwise and
thus it wont register to the type registry in org.fenggui.FengGUI).

However, although we both thought that a centralized registration
routine would be a simple solution, it might not be the neatest way to
do that. So I just wanted to ask you whether you had a brain wave in
the meantime since we lasted chat on how to solve the registration
issue?

Cheers,

Johannes