FengGUI and jME
Johannes Schaback
I managed to get FengGUI rendered on top of jME, but only if we load a
texture in jME too :-/... I still have no clue why textures are not
displayed when loading no textures in jME....
Here is a screenshot: https://fenggui.dev.java.net/images/jMEWithFengGUI.png
Johannes
Whackjack
Thanks for looking into it =)
Josh
Johannes Schaback
Boris Beaulant
What is the best way (layout) to have a single size fixed centred button
on the screen ?
I tried the BorderLayout with layout data set to center and
setExpandable to false, but my button stay on the bottom left corner of
my container :(
Bo
Rainer Angermann
iirc, there is a method which may help you:
StaticLayout.center(widget, container);
Your widget should then be centered in the given container.
Greetings,
Rainer
Boris Beaulant schrieb:
-- DI(FH) Rainer Angermann Rarebyte Game Development web: http://www.rarebyte.com mail: rai...@rarebyte.com phone: +43 720 504298
Johannes Schaback
The best way is using StaticLayout. The StaticLayout is assigned to
Display per default. Basically you do:
Button b = new Button("This is a Button");
display.addWidget(b);
b.setSize(200, 200);
StaticLayout.center(b, display);
Johannes
Boris Beaulant
Johannes Schaback a écrit :
Boris Beaulant
Is there, at the moment, a simple way to display in image and manipulate
it as a widget ?
I found the workaround to create a Box and set a PixmapBackground mapped
to the desired image.
If there's no simple way, what do you think about create a new simple
widget called "Image", for exemple, that implements a "setImage(String)"
method ?
In this widget the image could be scaled or not ...
Regards,
Bo
Rainer Angermann
for displaying an image I always use the Label widget, it provides a setPixmap(Pixmap pixmap) method and if there is no text, it just renders the image. However, it does not support scaling afaik.
Greetings,
Rainer
Boris Beaulant schrieb:
Hi all, Is there, at the moment, a simple way to display in image and manipulate it as a widget ? I found the workaround to create a Box and set a PixmapBackground mapped to the desired image. If there's no simple way, what do you think about create a new simple widget called "Image", for exemple, that implements a "setImage(String)" method ? In this widget the image could be scaled or not ... Regards, Bo
Boris Beaulant
Bo
Rainer Angermann a écrit :
Boris Beaulant
At present there's no dedicated image widget. It could be a good thing
to implements a simple "Image" widget that can work like that :
Image imageWidget = new Image();
imageWidget.setScaled(true);
imageWidget.setImage("image.png");
or
imageWidget.setPixmap(pixmap);
...
Bo
Johannes Schaback
Label l = new Label();
l.setPixmap(new Pixmap(Binding.getInstance().getTexture("image.png")));
:)
Johannes
Johannes Schaback
Well yes, Label does not support scaling. The scaling requirement for
icons etc. has not crossed my path yet.
Label also draws the image when there is text btw.
Not sure whether we should have another widget just for images, but I
guess it doesnt hurt. What do you need to scaling for anyway?
Johannes
On 9/19/06, Boris Beaulant <b...@ankama.com> wrote:
>
Johannes Schaback
l.setAlignment(Alignment.MIDDLE);
Boris Beaulant
Johannes Schaback a écrit :
> [...]
>
> Not sure whether we should have another widget just for images, but I
> guess it doesnt hurt. What do you need to scaling for anyway?
>
>
>
Yes, it doesn't hurt ;) ... But it can be very usefull if you want to
represent image at any place and any size in a simple way with only 2
parameters : file name and a boolean.
After it's right that you can play with alignment if it's not scaled
(center, top left, etc ...)
Bo
Johannes Schaback
> represent image at any place and any size in a simple way with only 2
> parameters : file name and a boolean.
> After it's right that you can play with alignment if it's not scaled
> (center, top left, etc ...)
Hmm, I don't want FengGUI to be particularly easy to use but reliable
and fast. Also we should avoid to develop things twice. I dont see the
need for scaling pixmaps yet, but it may appear to me one day and I
agree that this is a missing feature.
However, I am actually thinking that scaling should be better done in
the pixmap itself (following the Information Expert pattern). I need
som time to think about it a little before I come to a decision.
Having a chat with Rainer may also help. Meanwhile, all your comments
are appreciated.
Johannes
> Bo
>
>
> >
>
Boris Beaulant
Johannes Schaback a écrit :
> Hmm, I don't want FengGUI to be particularly easy to use but reliable
> and fast. Also we should avoid to develop things twice. I dont see the
> need for scaling pixmaps yet, but it may appear to me one day and I
> agree that this is a missing feature.
>
Ho no, I think nothing is develop twice here. A Label is designed to
display text, and sometimes image. But it's not it's primary goal.
You want FengGUI is as fast as possible, then why use a Label that
manage string to display an image ?
You can see in the attached file my implementation of the PixmapWidget
(simply extract java files from the jar).
The jar contains the PixmapWidget, and two exemples PixmapWidgetExemple
and a modified SplitContainerExemple ?
The PixmapWidget have only four properties :
- a pixmap
- a boolean that indicate if we need to scale the bitmap
- a boolean that indicate if we need to keep aspect ratio when scaling
- an alignment property
By default, the min size is set to the pixmap size.
Maybe it's not a perfect implementation and it could contains some bug I
did it only in 1 hour ;), but I know that I need this widget to design
my the GUI of the game I'm working on, then if you decide it could not
take a place in FengGUI, it's not a problem for me I will use it anyway ...
I need this widget tu simple display the character equipment, or spells
or what else ...
Or if anyone have a best solution, I'm totaly open ;)
Happy coding ;)
Bo
>
Johannes Schaback
Thanks for the code. I will check it out out asap. I am quite busy for
the rest of this week (yeah I got another live beside FengGUI :P ) so
it may take a day or two.
ok, couldnt resist... I just had a brief look at it though and it
looks pretty good to me already :) I will get back to you soon.
Johannes
On 9/19/06, Boris Beaulant <b...@ankama.com> wrote:
Esa Tanskanen
is developed, then Label should be changed to use that widget.
It's always best to avoid doing double the work. The same thing can be
applied to the XML routines - it'd be best to use a single method for both
saving and loading data. For example, we'd have an XMLInputOutputStream
class with the following kind of methods:
int process( int val, String name ) {
if (_saving) {
save(name, val); // Or inline the saving routine here
}
else {
val = load(name); // Or inline the loading routine here
}
return val;
}
// Usage example:
class MyWidget extends Widget {
void process( XMLInputOutputStream stream ) {
super.process( stream );
x = stream.process( x, "x" );
y = stream.process( y, "y" );
data = stream.process( data, "text-data" );
etc = stream.process( etc, "something-else" );
}
}
MyWidget widget = new MyWidget(...);
// To save the data:
XMLInputOutputStream stream = new XMLInputOutputStream(
XMLInputOutputStream.SAVE );
widget.process( stream );
// To load the data:
XMLInputOutputStream stream = new XMLInputOutputStream(
XMLInputOutputStream.LOAD );
widget.process( stream );
See how this way saves half of the work compared to writing the toXML and
fromXML routines. However, the code I posted is just an example. And there's
still the chance to use XStream (I haven't had the time to look into
FengGUI's code more closely)
_________________________________________________________________
Windows-työpöytähaun avulla löydät tiedot koneeltasi silmänräpäyksessä.
http://toolbar.msn.fi
Johannes Schaback
> is developed, then Label should be changed to use that widget.
yeah, 50% of the PixmapWidget behaviour is already implemented in
Label (namely if scaled = false). But the thing is that we dont have
some way to scale pixmaps and it seems straightforward to do it in a
special widget. On the other hand, my initial idea was to scale
pixmaps directly in org.fenggui.render.Pixmap. I dont have the time
right now to decide that :)
Your idea how to solve the XML streaming is clever and looks very
promising to me! Can you provide an inital implementation? Say in
org.fenggui.xml.XMLInputOutputStream? As Josh would say: I am getting
good vibes on that! :)
Johannes
Boris Beaulant
Esa Tanskanen a écrit :
> I wouldn't vote for an additional widget to display images. If such a widget
> is developed, then Label should be changed to use that widget.
>
Bo
Boris Beaulant
Johannes Schaback a écrit :
> yeah, 50% of the PixmapWidget behaviour is already implemented in
> Label (namely if scaled = false). But the thing is that we dont have
> some way to scale pixmaps and it seems straightforward to do it in a
> special widget. On the other hand, my initial idea was to scale
> pixmaps directly in org.fenggui.render.Pixmap. I dont have the time
> right now to decide that :)
>
Yes, but a pixmap is a sort of mask on a texture then it don't care
about scaled anything.
Else it's right that in this case every where pixmap is using, scaling
could be done (Background for exemple ;) )
Bo
>
Johannes Schaback
I am afraid I have bad news concerning the PixmapWidget. I decided not
to put it in the FengGUI distribution. The reason is that having a
special widget for scaling is actually only one kind of possible image
transformation you can do. Other stuff people might want to apply on
images are: rotation, flip, invert, squeeze, translate and so on.
Thus, in order to continue your idea of a pixmap transformation
widget, you would need to implement all these methods and parameterize
them. This will become increasingly messy and it is likely that it
will never perfectly match the users requirements. Therefore, people
shall use Canvas or extend Widget and override paint() to do all their
fancy image transformation stuff.
Regards
Johannes
PS: I am on my way to Poland to buy the essentials for our house
warming party :)
Boris Beaulant
Ok, but is it possible to have an other package like "FengGUIUtilities"
that hold such widget ? or put it in contrib !
Because I undestand, but not defend, your position about make FengGUI as
general as possible.
But in I know that as a user of FengGUI I prefer having simple tools to
avoid rewrite a routine each time I need it.
I know that my pixmap implementation doesn't make any rotation, or what
else, but its goal is to display a single image with layout management
in the fastest way.
In my opinion, rotation, trnaslation, flip, etc would be implemented in
"canvas" with a drawImage and you can put there multiple images (not the
same needs)
Else I can say that I'm a little lost in your reasoning : you approve a
Label that hold pixmap then a component that do more than its job and
refuse a "pixmapwidget" that does only what it must.
By refusing pixmapwidget I presume that the idea to have Labels that
extends "simple" (no rotation, flip, etc) pixmapwidget is not
corresponding to you vision of FengGUI, but why ?
If by the past you decided to add pixmap to Label isn't it because it
correspond to a special need ?
I will stop here because I think I'm a little borring with my
PixmapWidget ;)
Else, have a nice trip ;) , and don't forget that Open Source is the
best place to have colaborative works !
Happy coding,
Bo
Johannes Schaback a écrit :
Johannes Schaback
> Ok, but is it possible to have an other package like "FengGUIUtilities"
> that hold such widget ? or put it in contrib !
I hope org.fenggui.contrib to be a package where people can contribute
general widgets that are more fancy but do not belong to the class of
standard widgets. For example I could think of having a gauge-like
widget, or a turning knob, chat window, console window or something
like that. The problem with the PixmapWidget is that it is a basic
widget but cannot fully embrace its purpose because there are too many
ways you might want to transform an image.
Please check how AWT, Swing, SWT, qt, GTK, etc. handle this issue.
There is no component that is exclusivly dedicated to display
transformed images. At least not that I know of. They all expect you
to do some simple coding if you want to transform your images.
Interestingly, all of them have some sort of Graphics class which you
can feed with your image along with a transformation matrix (often
hidden, but it all comes down to affine transformations). This way
they ensure maximal flexibility and it really does not require so much
code. In FengGUI you can use the Canvas widget which works similar to
the Canvas component in AWT.
Suppose we have an implementation of IPaintListener and put it in the
canvas. Perhaps something like this:
final Pixmap myPixmap = createMeAPixmapSomehow();
final Canvas c = new Canvas();
c.setPaintListener(new IPaintListener() {
public void paint(Graphics g)
{
g.drawScaledImage(myPixmap, 0, 0, c.getInnerSize().getWidth().
c.getInnerSize().getHeight());
}
})
This does exactly what we want to accomplish with the PixmapWidget and
allows for absolute flexibility.
> Because I undestand, but not defend, your position about make FengGUI as
> general as possible.
> But in I know that as a user of FengGUI I prefer having simple tools to
> avoid rewrite a routine each time I need it.
It is difficult to find a state where generality and (easy-to-use-)
usability are optimally distributed over a design. I draw the line
here although I know you would shift the line a bit more in the
usability direction.
> In my opinion, rotation, trnaslation, flip, etc would be implemented in
> "canvas" with a drawImage and you can put there multiple images (not the
> same needs)
My point exactly. And the sad truth is that some of the methods havent
been implemented yet (e.g rotate, etc, etc.). Graham was actually the
last person who worked on the Graphics interface. We will need to have
some more feature requests. What remains is the questions which
transformations we shall actually implement? :D As a minimalist, I
vote for only
- rotation
- translation (well, that's obvious)
- scaling
Comments on how we might be able to apply all three of them
simultaniously without setting up a transformation matrix? :)
> Else I can say that I'm a little lost in your reasoning : you approve a
> Label that hold pixmap then a component that do more than its job and
> refuse a "pixmapwidget" that does only what it must.
I apologize I haven't made myself clear. I guess I was bit in a hurry
this morning.
I do understand that this appears a bit picky from my side. I stand by
the principle "a good design is not when there is nothing to add, but
when there is nothing to be removed" I guess that were Leibnitz'
words...
PixmapWidget serves the purpose to display images. So can label.
PixmapWidget also serves the purpose to scale Widgets. But it cannot
completely fullfil all possible desires of people how the image is to
be transformed (at least not with the current course we are following
of doing the transformations in Graphics). It would thus become a
special-case-widget which is less than what your work deserves.
> By refusing pixmapwidget I presume that the idea to have Labels that
> extends "simple" (no rotation, flip, etc) pixmapwidget is not
> corresponding to you vision of FengGUI, but why ?
Yes, I don't want Label to perform any transformation on the displayed
image ('cept the translation that comes with the alignment). While it
would be technially possible to apply arbitray transformations, it is
my conviction that Label should only provide the daily-needs
functionalty. Fancy stuff has to be done by the user himself.
> If by the past you decided to add pixmap to Label isn't it because it
> correspond to a special need ?
Yes. In fact I borrowed the idea of having a pixmap AND a text in the
Label from SWT. Similar to SWT, FengGUI draws the pixmap on the left
side when a text AND a pixmap is provided. This way you can easily
assign an icon to something that is labelled with a text (e.g. in
menus, tabs, buttons, etc.). However, If you only provde a pixmap (and
no text), only the pixmap is drawn, without interfering with the
behaviour of the widgets that make use of Label.
> I will stop here because I think I'm a little borring with my
> PixmapWidget ;)
I am sorry for your trouble. Nevertheless, I hope it comes in handy
for your project. You need to know that you belong to those FengGUI
developers who contribute the most and that you are a valuable member
of this team which is why I hate to disappoint you on the
PixmapWidget.
> Else, have a nice trip ;) , and don't forget that Open Source is the
> best place to have colaborative works !
Yeah, but even open-source projects need some guidance every now and then :)
Have fun!
Johannes
Boris Beaulant
my next request ;)
Else I think the List widget has a strange behavior. The first item is
on the bottom and if the widget isn not fill completly, the items are
align bottom. Is it what you want or it it a bug ?
Can I do somethong for that : item align on top and the first on top ?
Regards,
Bo
Johannes Schaback a écrit :
Johannes Schaback
> on the bottom and if the widget isn not fill completly, the items are
> align bottom. Is it what you want or it it a bug ?
> Can I do somethong for that : item align on top and the first on top ?
I believe you mean that the items are glued to the bottom if the list
has too few elements to fill the entire space of the list, right?
Yeah, that is a bug indeed. I remember I fixed the very same bug for
the table couple of months ago.
The items have to be drawn in top-down order. More precise, the item
that is first inserted in the list is drawn at the end
(First-in-last-out). Swiching the order is not necessary from my point
of view.
We may want to introduce cell renderes here too.
We may want to you only draw those items that are actually visible
(that's a bit tricky though, but achievable via examing the clip space
at run-time).
Bo, can you materialize a case on that behalf? :)
Peace,
Johannes
Boris Beaulant
Johannes Schaback a écrit :
>> Else I think the List widget has a strange behavior. The first item is
>> on the bottom and if the widget isn not fill completly, the items are
>> align bottom. Is it what you want or it it a bug ?
>> Can I do somethong for that : item align on top and the first on top ?
>>
>
> I believe you mean that the items are glued to the bottom if the list
> has too few elements to fill the entire space of the list, right?
> Yeah, that is a bug indeed. I remember I fixed the very same bug for
> the table couple of months ago.
>
Yes the items are glued to the bottom ;)
> The items have to be drawn in top-down order. More precise, the item
> that is first inserted in the list is drawn at the end
> (First-in-last-out). Swiching the order is not necessary from my point
> of view.
>
I think that the common way for that is :
addItem("Item1")
+-----------------+
| Item 1 |
| |
| |
+-----------------+
addItem("Item2")
+-----------------+
| Item 1 |
| Item 2 |
| |
+-----------------+
addItem("Item3")
+-----------------+
| Item 1 |
| Item 2 |
| Item 3 |
+-----------------+
--> The first item on the top. Look at the swing list, item indexed 0 if
on the top of the list.
> We may want to introduce cell renderes here too.
>
Good idea !
> We may want to you only draw those items that are actually visible
> (that's a bit tricky though, but achievable via examing the clip space
> at run-time).
>
> Bo, can you materialize a case on that behalf? :)
>
Does that mean update the actual List widget ?
Bo
Johannes Schaback
> +-----------------+
> | Item 1 |
> | |
> | |
> +-----------------+
>
> addItem("Item2")
> +-----------------+
> | Item 1 |
> | Item 2 |
> | |
> +-----------------+
>
> addItem("Item3")
> +-----------------+
> | Item 1 |
> | Item 2 |
> | Item 3 |
> +-----------------+
Precisely. I love ASCII-Art! It says more than 1K words. :)
> > Bo, can you materialize a case on that behalf? :)
> >
> Does that mean update the actual List widget ?
Yes. Thanks for taking care of that!
You can check out Table.java. We draw the items there from the top as
well... Bascially this means you need to use a y variable initiated
like that
int y = getInnerSize().getHeight() - font.getHeight.
Then you do the drawing like g.drawString(0, y, "yadda yadda") or something
and decrement y -= font.getHeight();
Tata
Johannes