libufo-devel — Discussion forum for users and developers

Re: [UFO-devel] commits

[Johannes S. <sch...@us...>]

Am Sonntag 17 Juli 2005 16:46 schrieb Andreas Beckermann:
> Hi
> would it be possible to setup a libufo-commits list?
> It would help me a lot in keeping the boson copy of libufo in sync with
> official cvs. The reason for this is that I cannot easily copy a new
> version of the whole library, as I have to reintegrate all of the patches
> that we applied to it but never got applied to the official version.

This is a great idea.
I was already pondering about that, but didn't have the time to set it up.
As you are using something similar for boson, do you have some scripts to 
automate that?


Regards,
Johannes

[UFO-devel] ufo::UTextLayout crash

[Andreas B. <b_...@gm...>]

Hi
when maxWidth is 0 by some reason, ufo::UTextLayout::getPreferredSize() may 
crash due to a line length of 4294967295.

The reason is that in ufo::UTextLayout::layout() lineStart will be increased 
by 1 per iteration. Therefore it is at 1 in the 2nd iteration - but the line
int wrap_index = (index > 0) ? index - 1 : 0;
causes wrap_index to be 0 then.
Therefore
 UTextLine line(lineStart, wrap_index - lineStart, lineHeight, pos);
causes a length of 0-1 which is an underflow for uints.

Patch attached.

CU
Andi

[UFO-devel] Invalid memory access in ufo::UTextWidget

[Andreas B. <b_...@gm...>]

Hi
The c'tor of ufo::UTextWidget calls setContentType() which in turn calls 
setDocument(), which has a line
getTextModel()->document = m_doc;

However getTextModel() casts m_model into a ufo::UTextModel, but at the 
beginning of the c'tor m_model is just a ufo::UWidgetModel. Only a few lines 
later m_model is set to a ufo::UTextModel.

The attached patch fixes the problem, but is not very nice: I the fact that 
m_doc is NULL only, if called from the c'tor.

CU
Andi

[UFO-devel] ufo::UInternalFrame uninitialized variable

[Andreas B. <b_...@gm...>]

Hi
m_frameState in widgets/uinternalframe.cpp is not being initialized. Patch 
attached.

CU
Andi

[UFO-devel] commits

[Andreas B. <b_...@gm...>]

Hi
would it be possible to setup a libufo-commits list?
It would help me a lot in keeping the boson copy of libufo in sync with 
official cvs. The reason for this is that I cannot easily copy a new version 
of the whole library, as I have to reintegrate all of the patches that we 
applied to it but never got applied to the official version.

CU
Andi

[UFO-devel] UWidget::getPreferredSize()

[Andreas B. <b_...@gm...>]

Hi
ufo::UWidget::getPreferredSize() returns the maxSize parameter, if 
maxSize.isEmpty() is true.
I believe it is better to use ufo::UDimension() instead, i.e. (0,0). The reson 
for this is, that the widget should does not have any size anyway (as size in 
one direction is 0), but layouts may get confused by the maxSize value in the 
other direction.

This fixes a possible bug with custom layouts (I did not check whether it can 
happen with official layouts, too) that is very hard to find (took me the 
whole day):
when (in a box layout) all previous children took away all space in the 
orientation direction, then the current child will get maxSize in the other 
direction. This additional (useless) space takes away space from siblings of 
the container widget.

CU
Andi

Re: [UFO-devel] ULabel

[Andreas B. <b_...@gm...>]

On Saturday 16 July 2005 20:01, Johannes Schmidt wrote:
> On Saturday 16 July 2005 19:35, Andreas Beckermann wrote:
> > Hi
> > ufo::ULabel::getPreferredSize() now uses getContentsSize() to calculate
> > its size, which in turn uses ufo::UStyle::getCompoundPreferredSize().
> >
> > I can change the outlook of the ufo::ULabel class by reimplementing
> > ufo::UStyle::paintComponent(). However then I also need to reimplement
> > the preferred size calculation of the ufo::ULabel.
> > But by reimplementing ufo::UStyle::getCompoundPreferredSize(), I also
> > change the behaviour of ufo::UButton. Any way around this?
> >
> > I am probably going to subclass the ufo::ULabel class, but I think that's
> > a suboptimal solution only, as I have to make sure that no plain
> > ufo::ULabel objects are created anymore.
> > Providing either a ufo::UCompound pointer or a
> > ufo::UStyle::ComponentElement in ufo::UStyle::getCompoundPreferredSize()
> > would fix the problem.
>
> I assume that this covers the multline label problem.

Yep, but I consider this a general problem. It'll probably come up again, if I 
ever write custom layouts for the sake of look and feel.

> Before digging too much into this problem, let me ask whether it is an
> option for you to use UTextWidget which has support for multiple lines and
> line wrapping ...

I am not willing to replace my working code with something new and untested.

> Regards,
> Johannes

CU
Andi

Re: [UFO-devel] ULabel

[Johannes S. <sch...@us...>]

On Saturday 16 July 2005 19:35, Andreas Beckermann wrote:
> Hi
> ufo::ULabel::getPreferredSize() now uses getContentsSize() to calculate its
> size, which in turn uses ufo::UStyle::getCompoundPreferredSize().
>
> I can change the outlook of the ufo::ULabel class by reimplementing
> ufo::UStyle::paintComponent(). However then I also need to reimplement the
> preferred size calculation of the ufo::ULabel.
> But by reimplementing ufo::UStyle::getCompoundPreferredSize(), I also
> change the behaviour of ufo::UButton. Any way around this?
>
> I am probably going to subclass the ufo::ULabel class, but I think that's a
> suboptimal solution only, as I have to make sure that no plain ufo::ULabel
> objects are created anymore.
> Providing either a ufo::UCompound pointer or a
> ufo::UStyle::ComponentElement in ufo::UStyle::getCompoundPreferredSize()
> would fix the problem.

I assume that this covers the multline label problem.
Before digging too much into this problem, let me ask whether it is an option 
for you to use UTextWidget which has support for multiple lines and line 
wrapping ...


Regards,
Johannes

[UFO-devel] ULabel

[Andreas B. <b_...@gm...>]

Hi
ufo::ULabel::getPreferredSize() now uses getContentsSize() to calculate its 
size, which in turn uses ufo::UStyle::getCompoundPreferredSize().

I can change the outlook of the ufo::ULabel class by reimplementing 
ufo::UStyle::paintComponent(). However then I also need to reimplement the 
preferred size calculation of the ufo::ULabel.
But by reimplementing ufo::UStyle::getCompoundPreferredSize(), I also change 
the behaviour of ufo::UButton. Any way around this?

I am probably going to subclass the ufo::ULabel class, but I think that's a 
suboptimal solution only, as I have to make sure that no plain ufo::ULabel 
objects are created anymore.
Providing either a ufo::UCompound pointer or a ufo::UStyle::ComponentElement 
in ufo::UStyle::getCompoundPreferredSize() would fix the problem.

CU
Andi

Re: [UFO-devel] Keyboard events not firing and Texture fonts not working?

[Johannes S. <sch...@us...>]

On Saturday 16 July 2005 17:42, Mark Robson wrote:
> On 16/07/05, Johannes Schmidt <sch...@us...> wrote:
> > Argl, every change to the source does produce bugs.
> > There was missing an break; statement.
> > Should be fixed in CVS.
>
> I've got the latest version out of CVS (ufo-0.5 project?) , but this
> has made no difference.
>
> Both problems still appear - Texture fonts won't work, and the
> "events" demo reports no keyboard events (even after clicking on the
> UWidget)

This is a sourceforge issue.
The anonymous CVS has a 24 hour lag compared to developer CVS.
I don't know the exact reason and whether this will be changed in the future.
But for now you just have to wait if you want CVS versions.

FYI, I have uploaded a new snapshot which includes all changes.


Regards,
Johannes

Re: [UFO-devel] Keyboard events not firing and Texture fonts not working?

[Mark R. <ma...@gm...>]

On 16/07/05, Johannes Schmidt <sch...@us...> wrote:
> Argl, every change to the source does produce bugs.
> There was missing an break; statement.
> Should be fixed in CVS.

I've got the latest version out of CVS (ufo-0.5 project?) , but this
has made no difference.

Both problems still appear - Texture fonts won't work, and the
"events" demo reports no keyboard events (even after clicking on the
UWidget)

Cheers
Mark

Re: [UFO-devel] Can't set a font

[Johannes S. <sch...@us...>]

On Saturday 09 July 2005 12:33, Mark Robson wrote:
[...]
> > Furthermore, in older releases there was an X11/GLX font renderer
> > which can use all fonts visible to your X server.
> > If you are interested, I can fix it for current releases.
>
> No, that is not important. I  am more interested in the textured
> fonts, especially if I have the program to create custom ones.
>
> This will enable me to use fonts not present on the user's machine. It
> would also be nice if my program uses the same fonts on Windows and
> Linux.

I have attached a prerelease of the source code with which I created the 
distributed font files.
You'll need SDL, SDL_ttf and libUFO.

Compiling should work via
g++ ugentgafont.cpp -o ugentgafont `sdl-config --cflags --libs` `pkg-config 
--cflags --libs ufo` -lSDL_ttf

To create a font file, call it with the ttf file and optionally
the point size as arguments.

[...]
> Good luck with your exams.

Thanks.
I assume the results will turn out satisfactory.


Regards,
Johannes

Re: [UFO-devel] Keyboard events not firing and Texture fonts not working?

[Johannes S. <sch...@us...>]

On Saturday 16 July 2005 12:12, Mark Robson wrote:
> Two issues I've come across:
>
> 1. Keyboard events are not firing on plain UWidgets. This is
> demonstrated by the "events" test program in the libufo distribution.
> The keyboard events don't fire at all, even after I click on the
> widget.

Oops, the focus manager didn't consumed mouse events. Therefore they were 
propagated to the parent (which was focused then).
Fixed in CVS.

> 2. Texture fonts don't seem to work at all either. This did work on an
> older CVS version of libufo. I'm setting
>
> UFO_FONT=gl_texture_font
> UFO_FONT_DIR=/home/mark/unpack/ufo-0.8.0/data/font
>
> But to no avail. I've also tried setting UFO_FONT to texture_font.

Argl, every change to the source does produce bugs.
There was missing an break; statement.
Should be fixed in CVS.

[...]
> I'm trying to make a game which has a play area drawn with OpenGL plus
> some menus and popup windows (UIInternalFrame) which do various other
> things.
>
> I want to capture keyboard events on the main window, only if a popup
> does not currently have the focus. How can I do this? I've tried
> putting keyboard event handlers on my context's ContentPane, but this
> only seems to work if there is a child control which is focused.

If a focused widget is going to be hidden or removed,
the root pane will be focused.
Try to add your keyboard handlers to the root pane.
There is also support for event listener and event grabber
(using some of UContext's methods) but I consider it somehow broken ..

> Is it that plain UWidgets don't take keyboard focus by default? If so,
> what can I do to make it so that it can?

UWidget should be focusable.


> Cheers for a great library

Thanks!


Regards,
Johannes

Re: [UFO-devel] menubar removal

[Johannes S. <sch...@us...>]

On Thursday 14 July 2005 23:47, Andreas Beckermann wrote:
> Hi
> URootPane::setMenuBar() is buggy when there is already a menubar set:
> instead of removing the existing one, there is a second menubar added.
>
> The attached patch fixes the problem.
> Note that the URootPane::setMenuBar() part of the patch is ugly, but it
> gets the job done for me.

Thanks!
Added to CVS.

Regards,
Johannes

Re: [UFO-devel] valgrind

[Johannes S. <sch...@us...>]

On Friday 15 July 2005 12:14, Andreas Beckermann wrote:
> Hi
> The attached patch fixes several errors reported by valgrind.

Thanks!
Applied to CVS.


Regards,
Johannes

[UFO-devel] Keyboard events not firing and Texture fonts not working?

[Mark R. <ma...@gm...>]

Two issues I've come across:

1. Keyboard events are not firing on plain UWidgets. This is
demonstrated by the "events" test program in the libufo distribution.
The keyboard events don't fire at all, even after I click on the
widget.

2. Texture fonts don't seem to work at all either. This did work on an
older CVS version of libufo. I'm setting

UFO_FONT=3Dgl_texture_font
UFO_FONT_DIR=3D/home/mark/unpack/ufo-0.8.0/data/font

But to no avail. I've also tried setting UFO_FONT to texture_font.

Neither of them makes any difference. The "properties" test program
correctly reports the values, but there is no difference in font
rendering.

I'm trying to make a game which has a play area drawn with OpenGL plus
some menus and popup windows (UIInternalFrame) which do various other
things.

I want to capture keyboard events on the main window, only if a popup
does not currently have the focus. How can I do this? I've tried
putting keyboard event handlers on my context's ContentPane, but this
only seems to work if there is a child control which is focused.

Is it that plain UWidgets don't take keyboard focus by default? If so,
what can I do to make it so that it can?

Cheers for a great library

Mark

Re: [UFO-devel] UGL_Graphics

[Johannes S. <sch...@us...>]

Am Freitag 15 Juli 2005 12:06 schrieb Andreas Beckermann:
> UGL_Graphics::resetAttributes()/resetDeviceViewMatrix() is marked virtual
> in UGL_Graphics, but not in UGraphics. Therefore calling
> UGraphics::resetAttributes()/resetDeviceViewMatrix() is a noop with no
> error message or anything else that indicates why nothing is working.
>
> These methods are deprecated now, but I think UGraphics::begin() is not a
> full replacement in the way it is now.
> I will either need to patch it to provide a boolean "pushAttributes"
> parameter, or I need to continue using the previous approach.
> The reason for this is that my graphic cards drivers provide a maximal
> projection matrix stack depth of 4 only. Therefore the unconditional
> pushMatrix() of UGL_Graphics::begin() might turn out to be a problem
> easily. Even worse: the OpenGL spec requires a max depth of 2 only, so this
> pushMatrix() call may be useful, but can turn out to be problematic (as it
> did for me).
>
> I'd propose to make resetDeviceViewMatrix()/resetAttributes() virtual in
> UGraphics again and just call it from begin(), instead of reimplementing it
> there. Then one can decide not to use begin() and use the other methods
> instead.

Okay.


Regards,
Johannes

Re: [UFO-devel] setColor()

[Johannes S. <sch...@us...>]

Am Freitag 15 Juli 2005 00:30 schrieb Andreas Beckermann:
> Hi
> UGL_Graphics::setColor() calls glEnable()/glDisable()/glBlendFunc().
> This makes using this method within a glBegin()/glEnd() pair impossible. I
> consider that very unintuitive.

Indeed.
At first, I will change it so that those calls are only executed if alpha 
values have been enabled/disabled.

Well, this does not fix it if you change colors from opaque to transparent 
ones, but right now I don't know how to check if we are between an 
glBegin/glEnd call.
Anyway you should avoid to mix GL and UFO methods ...

If you have more thoughts about this, please let me know.


Regards,
Johannes

[UFO-devel] valgrind

[Andreas B. <b_...@gm...>]

Hi
The attached patch fixes several errors reported by valgrind.

CU
Andi

[UFO-devel] UGL_Graphics

[Andreas B. <b_...@gm...>]

Hi
UGL_Graphics::resetAttributes()/resetDeviceViewMatrix() is marked virtual in 
UGL_Graphics, but not in UGraphics. Therefore calling 
UGraphics::resetAttributes()/resetDeviceViewMatrix() is a noop with no error 
message or anything else that indicates why nothing is working.

These methods are deprecated now, but I think UGraphics::begin() is not a full 
replacement in the way it is now.
I will either need to patch it to provide a boolean "pushAttributes" 
parameter, or I need to continue using the previous approach.
The reason for this is that my graphic cards drivers provide a maximal 
projection matrix stack depth of 4 only. Therefore the unconditional 
pushMatrix() of UGL_Graphics::begin() might turn out to be a problem easily. 
Even worse: the OpenGL spec requires a max depth of 2 only, so this 
pushMatrix() call may be useful, but can turn out to be problematic (as it 
did for me).

I'd propose to make resetDeviceViewMatrix()/resetAttributes() virtual in 
UGraphics again and just call it from begin(), instead of reimplementing it 
there. Then one can decide not to use begin() and use the other methods 
instead.

CU
Andi

Re: [UFO-devel] UBasicStyle

[Johannes S. <sch...@us...>]

Am Donnerstag 14 Juli 2005 23:00 schrieb Andreas Beckermann:
> Hi
> In ui/ubasicstyle.cpp, UBasicStyle::getCompoundPreferredSize(), line 1554
>                         std::max(text_size.h, icon_size.w)
> should be
>                         std::max(text_size.h, icon_size.h)
> I believe.
> Why I do so? Well, first it looks more logical and second it fixes one of
> the damn bugs I've been hunting for the last two days ;-)
>
> Image-labels look much better when they use the height of the image as
> height of the widget, instead of the width of the image as height of the
> widget ;-)

Ouh, yes, many thanks :)

Should be in (developer) CVS.

Regards,
Johannes

[UFO-devel] setColor()

[Andreas B. <b_...@gm...>]

Hi
UGL_Graphics::setColor() calls glEnable()/glDisable()/glBlendFunc().
This makes using this method within a glBegin()/glEnd() pair impossible. I 
consider that very unintuitive.

CU
Andi

[UFO-devel] menubar removal

[Andreas B. <b_...@gm...>]

Hi
URootPane::setMenuBar() is buggy when there is already a menubar set: instead 
of removing the existing one, there is a second menubar added.

The attached patch fixes the problem.
Note that the URootPane::setMenuBar() part of the patch is ugly, but it gets 
the job done for me.

CU
Andi

[UFO-devel] UBasicStyle

[Andreas B. <b_...@gm...>]

Hi
In ui/ubasicstyle.cpp, UBasicStyle::getCompoundPreferredSize(), line 1554
                        std::max(text_size.h, icon_size.w)
should be
                        std::max(text_size.h, icon_size.h)
I believe.
Why I do so? Well, first it looks more logical and second it fixes one of the 
damn bugs I've been hunting for the last two days ;-)

Image-labels look much better when they use the height of the image as height 
of the widget, instead of the width of the image as height of the widget ;-)

CU
Andi

Re: [UFO-devel] compile error

[Johannes S. <sch...@us...>]

Am Mittwoch 13 Juli 2005 21:49 schrieb Andreas Beckermann:
> Hi
> current cvs: udocumentfactory.hpp includes udocumentfilter.hpp (and uses
> classes from it) which is gone.
>
> It looks like the header wasn't committed after changing it

This was already checked in.

After some checks, it seems that this change is now in
anonymous CVS, viewCVS, and the latest snapshot.
If you update your libUFO copy, it should work.


Regards,
Johannes