libufo-devel — Discussion forum for users and developers

Re: [UFO-devel] destroyed signal

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

On Tuesday 23 August 2005 02:04, Andreas Beckermann wrote:
> Hi
> sometimes I need a signal that is emitted right before an object is
> destroyed. Would it be possible to add a "destroyed" signal to
> ufo::UObject, that is emitted by the destructor?

I have added a sigDestroyed signal to UObject.


Regards,
Johannes

Re: [UFO-devel] ufo::UObject::trackPointer()

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

On Monday 22 August 2005 05:41, Andreas Beckermann wrote:
> Hi
> there is a problem with ufo::UObject::trackPointer() versus
> ufo::UObject::releasePointer():
> trackPointer() adds and references the given pointer unconditionally.
> However releasePointer() _releases_ the pointer once, but _removes_ it as
> often as it appears in the list.

I have changed releasePointer to remove only the first occurence of the 
pointer in the list.
This should fix the problem.


Regards,
Johannes

[UFO-devel] destroyed signal

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

Hi
sometimes I need a signal that is emitted right before an object is destroyed. 
Would it be possible to add a "destroyed" signal to ufo::UObject, that is 
emitted by the destructor?

CU
Andi

[UFO-devel] ufo::UObject::trackPointer()

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

Hi
there is a problem with ufo::UObject::trackPointer() versus 
ufo::UObject::releasePointer():
trackPointer() adds and references the given pointer unconditionally.
However releasePointer() _releases_ the pointer once, but _removes_ it as 
often as it appears in the list.

So something like
  trackPointer(foo);
  trackPointer(foo);
  releasePointer(foo);
causes a memory leak: even if you have a second releasePointer(foo) in the 
code, it won't be able to actually release the pointer.

ufo::UObject::releasePointer() also doesn't give any warning about this, so 
that such a bug would be very hard to find. The attached patch is an example 
of such a warning.
I propose to additionally call unreference() as often as actually required 
(i.e. oldsize - m_pointers.size() times). With such a patch the above error 
message may not be required, depending on whether this kind of use is 
supposed to be allowed.

Last but not least:
ufo::UComboBox c'tors trigger this bug:
  trackPointer(m_textEdit);
  add(getTextEdit());
where getTextEdit() returns m_textEdit. ufo::UWidget::addImpl() calls 
trackPointer() nearly unconditionally and always does in this case.

CU
Andi

[UFO-devel] ufo::UImageIcon

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

Hi
I have committed a ufo::UBoDrawableIcon class to the libufo extension of 
Boson.
This class simply provides an ufo::UIcon object for a ufo::UDrawable. It has 
completely replaced ufo::UImageIcon in Boson, as it
a) provides the same functionality
b) also works with non-image drawables

Maybe you may consider this as a replacement for ufo::UImageIcon, too. You can 
find it at
http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/ufoext/ubodrawableicon.cpp?rev=1.1&view=log
http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/ufoext/ubodrawableicon.h?rev=1.1&view=log

CU
Andi

Re: [UFO-devel] memory leak3: icons/images

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

On Tuesday 16 August 2005 16:29, Andreas Beckermann wrote:
[...]
> Therefore, when the ufo::UImageIcon object unreference()s all it's
> pointers, the reference count of the image will still be 1 and the image
> won't ever be deleted.
> ufo::UAbstractDisplay::removeVolatileData() is never called, as this would
> be done by the d'tor of ufo::UGL_Image.
>
> In addition: the d'tor of ufo::UAbstractDisplay does not
> 1. delete remaining objects in m_volatileData
> 2. does not emit a warning/error about remaining objects. Very bad for
> debugging.

Oops, that was a rough transition from UContextGroup to UDisplay.
The context group thing is deprecated in favor of a (hopefully) simplified 
design for hardware memory.

The display shall be the main connection to the native system.
It loads system libraries, creates windows and should keep track of allocated 
hardware surfaces/textures.
Everything which is created using the same display shares its data.
So much for the theory.

I'll move the missing parts from UContextGroup to UAbstractDisplay.
This should fix that bug.


Many thanks,
Johannes

[UFO-devel] cvs commits mailing list

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

Hi,

I have set up a mailing list to get notice of new CVS commits:
lib...@li...

For subscription, see here:
http://lists.sourceforge.net/lists/listinfo/libufo-commits


Regards,
Johannes

Re: [UFO-devel] ufo::UTextWidget: (small) memory leak

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

On Wednesday 17 August 2005 10:53, Andreas Beckermann wrote:
> Hi
> ufo::UTextWidget::m_textLayout seems to be never deleted. However it is
> created by the c'tor.

Thanks. Should be fixed in CVS.


Regards,
Johannes

[UFO-devel] ufo::UTextWidget: (small) memory leak

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

Hi
ufo::UTextWidget::m_textLayout seems to be never deleted. However it is 
created by the c'tor.

CU
Andi

[UFO-devel] memory leak3: icons/images

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

Hi
suppose the following:
ufo::UButton* button = new ufo::UButton(...);
...
ufo::UImage* image = new ufo::UGL_Image(...); // load an image
button->setIcon(new ufo::UImageIcon(image));
...
parentOfButton->removeAll();

What I would expect here: the removeAll() call removes the button (which 
actually works) which in turn removes the icon (which works, too) and 
therefore the image.

However what actually happens:
when ufo::UGL_Image::paint() is called, it calls 
ufo::UGL_Image::ensureImage(). Once this is called the very first time, it 
creates the texture and calls ufo::UDisplay::addVolatileData(this).
ufo::UAbstractDisplay::addVolatileData() however, calls 
ufo::UGL_Image::reference().

Therefore, when the ufo::UImageIcon object unreference()s all it's pointers, 
the reference count of the image will still be 1 and the image won't ever be 
deleted.
ufo::UAbstractDisplay::removeVolatileData() is never called, as this would be 
done by the d'tor of ufo::UGL_Image.

In addition: the d'tor of ufo::UAbstractDisplay does not
1. delete remaining objects in m_volatileData
2. does not emit a warning/error about remaining objects. Very bad for 
debugging.


Wow, this one has really been difficult to find.

CU
Andi

Re: [UFO-devel] memory leak2: style hints

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

On Tuesday 16 August 2005 14:06, Andreas Beckermann wrote:
> Hi
> another memory leak (a small one this time):
> ufo::UWidget::detachStyleHints() creates a new object and stores it in
> m_styleHints, however it is never deleted. ufo::UWidget::setStyleHints()
> would delete it, but it is not called on destruction.

Thanks.
Should be fixed in developer CVS.


Regards,
Johannes

Re: [UFO-devel] memory leak

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

On Tuesday 16 August 2005 13:50, Andreas Beckermann wrote:
[...]
> where "buffer" is the ufo::UVertexArray. So here we come to the important
> part: In ufo::UVertexArray::getArray():
>   float * ret = new float[getCount() * 3];
>   [...]
>   return ret;
>
> Since glInterleavedArrays() does not free the pointer (and certainly
> doesn't delete it), this is a memory leak. The getArray() pointer is never
> freed anywhere.
> (ubasicstyle.cpp, line 210 is only one example of this leak)
>
> To give you an idea of the size of this leak: valgrind reports about 2.7 MB
> (!) definitely lost in a short session of a small test application.

Ouch.
Many thanks.
I have committed a patch so that UVertexArray keeps track of the allocated 
memory and deletes it on destruction.


Regards,
Johannes

[UFO-devel] memory leak2: style hints

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

Hi
another memory leak (a small one this time):
ufo::UWidget::detachStyleHints() creates a new object and stores it in 
m_styleHints, however it is never deleted. ufo::UWidget::setStyleHints() 
would delete it, but it is not called on destruction.

CU
Andi

[UFO-devel] memory leak

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

Hi
line 210 of ubasicstyle.cpp:
  g->drawVertexArray(UGraphics::LineStrip, &array);
where array is a ufo::UVertexArray. In the corresponding 
ufo::UGL_Graphics::drawVertexArray():
  ugl_driver->glInterleavedArrays(GL_V3F, 0, buffer->getArray());
where "buffer" is the ufo::UVertexArray. So here we come to the important 
part: In ufo::UVertexArray::getArray():
  float * ret = new float[getCount() * 3];
  [...]
  return ret;

Since glInterleavedArrays() does not free the pointer (and certainly doesn't 
delete it), this is a memory leak. The getArray() pointer is never freed 
anywhere.
(ubasicstyle.cpp, line 210 is only one example of this leak)

To give you an idea of the size of this leak: valgrind reports about 2.7 MB 
(!) definitely lost in a short session of a small test application.

CU
Andi

Re: [UFO-devel] ufo::UFocusManager vs ufo::UWidget

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

On Friday 22 July 2005 18:23, Andreas Beckermann wrote:
> Hi
> the patch to ufo::UFocusManager that makes it consume events, breaks
> certain situations. Consider the following:
> There is a widget that takes mouse click events and it has a child that
> takes some kind of mouse events (m_eventState & MouseEvents, not talking
> about motion events here).
>
> A mouse click event is delivered to the child widget. Now imagine it is not
> interested in it (but the parent will be!) - it is now (because of
> ufo::UWidget::processEvent()) delivered to the focusmanager, which consumes
> it (requesting the focus).
> So the event is not propagated to the parent, even if the child does not
> make use of the focus at all.

Hmm, okay, I have removed the event consuming and replaced it with a check 
whether the given mouse event was already processed.
This should cover the above problem and the multiple mouse focus problem.

Should be in developer CVS.

Regards,
Johannes

Re: [UFO-devel] mouse press events and ufo::UMenuItem

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

On Monday 15 August 2005 03:21, Andreas Beckermann wrote:
[...]
> I am not fully sure if this problem appears in official libufo cvs, too,
> but I think this patch should not have any evil side effects (actually the
> menu item _should_ consume the event, as it waits for the corresponding
> release event then).
> You can test whether the problem appears in official libufo by doing:
> Click on a menu item and hold the button. If the menu gets hidden, then the
> bug does appear. If the menu gets hidden only after releasing the button,
> then not.

I couldn't reproduce the bug but have applied your patch.


Thanks,
Johannes

[UFO-devel] mouse press events and ufo::UMenuItem

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

Hi
the attached fix makes sure that MousePress events are consumed when clicking 
on a menu item.
Without this patch the event may get propagated back to other widgets and 
eventually causing a call to closeMenuPopups() that hides the menu. The click 
on the menu item is still correctly processed, but the following mouse press 
event is then not eaten by the menu item anymore (because 
w_under_mouse->contains(e->getLocation()) is false then).

I am not fully sure if this problem appears in official libufo cvs, too, but I 
think this patch should not have any evil side effects (actually the menu 
item _should_ consume the event, as it waits for the corresponding release 
event then).
You can test whether the problem appears in official libufo by doing:
Click on a menu item and hold the button. If the menu gets hidden, then the 
bug does appear. If the menu gets hidden only after releasing the button, 
then not.

(It certainly does happen for me, but as said before I am using a heavily 
modified event dispatch code that also works for layered panes)

CU
Andi

[UFO-devel] code/boson/boufo

[abmann <bos...@li...>]

code/boson/boufo boufopushbutton.cpp,1.1,1.2 boufopushbutton.h,1.1,1.2
Author: abmann
Sun Aug 14 00:37:09 PDT 2005
Update of /cvsroot/boson/code/boson/boufo
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24110


Modified Files:
	boufopushbutton.cpp boufopushbutton.h 
Log Message:
Consume MouseDragged events in pushbuttons.

MouseDragged events are sent to the button when it is pressed down and the mouse
is moved (before the button is released again).
This fixes selectionrect problems when clicking a button: when the mouse is
moved a bit while clicking the button, the event is propagated to the parent of
the button which draws a selectionrect (which never disappears, as the button
eats the button release event).

This should fix bug #107646.


CC'ing libufo-devel, as this problem probably appears in official libufo, too.
However we use our own event code which also works with layered panes, and I did
not want to write yet another test application just to test whether the problem
appears with official cvs, therefore I am not patching libufo directly.

CCMAIL: lib...@li...

Re: [UFO-devel] commits

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

On Wednesday 20 July 2005 11:46, Johannes Schmidt wrote:
> 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

There are some docs on the sourceforge site about this:
http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#scriptsyncmail

However I didn't like syncmail very much, as I did not want the mails to 
include the diff at that time. Instead I am using a modified version of the 
KDE script, which you can find at 
http://cvs.sourceforge.net/viewcvs.py/boson/CVSROOT/loginfo.pl?rev=1.3&view=log

At some time I will either switch to syncmail or to a more recent version of 
the KDE script, as I am now considering to include diffs into the log mails. 
One day :-)

CU
Andi

[UFO-devel] ufo::UFocusManager vs ufo::UWidget

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

Hi
the patch to ufo::UFocusManager that makes it consume events, breaks certain 
situations. Consider the following:
There is a widget that takes mouse click events and it has a child that takes 
some kind of mouse events (m_eventState & MouseEvents, not talking about 
motion events here).

A mouse click event is delivered to the child widget. Now imagine it is not 
interested in it (but the parent will be!) - it is now (because of 
ufo::UWidget::processEvent()) delivered to the focusmanager, which consumes 
it (requesting the focus).
So the event is not propagated to the parent, even if the child does not make 
use of the focus at all.

CU
Andi

Re: [UFO-devel] UWidget::getPreferredSize()

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

Am Samstag 16 Juli 2005 22:28 schrieb Andreas Beckermann:
> 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.

Thanks, should be in (developer) CVS.

cu,
Johannes

Re: [UFO-devel] ULabel

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

Am Samstag 16 Juli 2005 20:45 schrieb Andreas Beckermann:
> 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.
[...]
Okay, I'll add a style type (CE_Label bla) or a widget pointer (or both).
Have to take some closer look before.

cu,
Johannes

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

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

Am Mittwoch 20 Juli 2005 07:22 schrieb Andreas Beckermann:
> 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.

Many thanks.
I have applied a different patch which creates the text model right at the 
beginning of the c'tor (similar to other widgets).


Regards,
Johannes

Re: [UFO-devel] ufo::UTextLayout crash

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

Am Mittwoch 20 Juli 2005 07:57 schrieb Andreas Beckermann:
> 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.

Thanks.
A maxWidth of 0 should already be caught by the check above the while loop
(if condition with maxWidth <=0) ... ?
Anyway I have committed your patch.

cu,
Johannes

Re: [UFO-devel] ufo::UInternalFrame uninitialized variable

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

Am Dienstag 19 Juli 2005 18:07 schrieb Andreas Beckermann:
> Hi
> m_frameState in widgets/uinternalframe.cpp is not being initialized. Patch
> attached.

Thanks, should be in (developer) CVS.

cu,
Johannes