libufo-devel — Discussion forum for users and developers

[UFO-devel] Popup Menus

[Casper B. <dec...@on...>]

Posted a code snippet at rafb for easier reading, which can be found at 
here <http://www.rafb.net/paste/results/ZRm0io78.nln.html> (url: 
http://www.rafb.net/paste/results/ZRm0io78.nln.html ).


So the first question would be, in the code snippet given above, am i 
using the popup menu correctly?
If so, there seems to be a couple of issues with them.

The first one would be logic-wise, shouldn't the popup menu be closed 
without any setup from the user when an item is activated?
Now it's not all that trivial to connect each sigActivated to a 'close 
slot', but it feels like this should be handled by the popup menu itself.


Next up is an odd bug i produced and was able to reproduce every time i 
tried,  a screencap of it can be found  here 
<http://img400.imageshack.us/img400/8471/screencap10ta.jpg> (url: 
http://img400.imageshack.us/img400/8471/screencap10ta.jpg).
To reproduce it just highlight an item, leave the popup menu's bounds, 
and enter it again from above.

And logic-wise, should items really be highlighted when the mouse is not 
over them?


Next up, when adding "sub-menus" (i.e adding a UMenu as a child of 
UPopupMenu) the highlighting isn't present when hovering it, it works 
when clicking on it tho.


I Have the feeling that i'm just abusing the class tho, if that's the 
case i'd appreciate an example! :)



 

[UFO-devel] Patch: ufo::UGL_Graphics::mapToDevice()

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

Hi
attached a patch that fixes ufo::UGL_Graphics::mapToDevice():
the last coordinate inside a rect is (rect.y + rect.h - 1), not (rect.y + 
rect.h).

CU
Andi

Re: [UFO-devel] Better position management using ufo/glut

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

On Saturday 04 March 2006 00:58, Elie `woe` BLETON wrote:
> Hi !
>
> Thanks for the quick answer. Here are the results of my attempts that
> considered your first answers. I think I didn't quite get some points.
>
> Here they are:
> > If you set the layout manager to a NULL pointer
> > [UWidget::setLayout(NULL)], the child widgets will be position relatively
> > to its parent.
>
> I assumed that the positionning you are referring to is the one
> accessed UWidget::setLocation(int x, int y) (or UWidget::setBounds for
> this matter).
> I tried to apply the NULL layout to my root pane
> (myContext->getRootPane()->setLayout(NULL)), giving arbitrary
> coordinates like (42, 42) to my widgets. I doesn't really works as
> expected, since the widgets simply disappear.

If you do not use a layout manager, you have to specify both, location and 
size (well, perhaps this should be changed).
For most cases, you want the widget to have the so called "preferred size", a 
computed value where the widget has the size to display all of its content.
Try:
widget->setSize(widget->getPreferredSize());

> Could you give me a bit more information on the (x,y) coordinate
> system you are using (if I'm to trust the docs, (0,0) is top left of
> the screen), or perhaps I'm missing some call to get that custom
> positonning ?

That's correct. (0,0) is the top left corner.

> > > I'm looking for a way to get some colors inside the TextEdit
> > > component, for "syntax highlighting" purposes.
> >
> > I'm sorry, this is on the ToDo-list, but there are more important things
> > on it, too ...
>
> I'd be glad to contribute some code if you can provide me some
> directions as to "where" to update the code. I assume it could inherit
> from UTextEdit class since it could share many properties. Beside the
> syntax analysis, perhaps could you provide some hint on "how" to apply
> colors to parts of the text.

All drawing is usually done using the graphics object.
You can set the color (UGraphics::setColor), paint some primitives and text 
(UGraphics::drawString).

> I looked a bit at the font rendered (both basic and ogl) without
> seeing anything related to color, but I know from screenshots (alas)
> that it's possible - but I'm very reluctant into using CSS styles to
> apply the colors (could be heavy for syntax highlighting).
> Despite looking at the code (I have no IDE but emacs, grep, less and a
> shell - so no "nice" method tree ...), I still don't get to the part
> where the widgets are actually *drawn* (UWidget::repaint() ..
> UGraphics::? ... ?), and where I could specify the colors.

UWidget::paintWidget is a virtual method which you might to overwrite to get 
your own look.
paintWidget by default calls the appropriate style method to draw its 
background and content.
Different text colors, e.g. for labels, are done via setForegroundColor
(or setPalette).

> > Well, actually, here comes some new questions, so I use your quotes to
> > act as separators
>
> Regarding widgets, do you think I could make some use of glTranslateX
> functions in some way or another to provide something a bit more
> "dynamic" or "animated" ? If it's possible, where are the available
> entry points to the widget drawing code (without having to mess with
> UFO code)

I do not know exactly what you mean with entry points, but UWidget::paint does 
the necessary set up of the graphics object and calls paintWidget and other 
methods to paint the widget and its children.


Regards,
Johannes

Re: [UFO-devel] Better position management using ufo/glut

[Elie `w. B. <dro...@gm...>]

Hi !

Thanks for the quick answer. Here are the results of my attempts that
considered your first answers. I think I didn't quite get some points.
Here they are:

> If you set the layout manager to a NULL pointer [UWidget::setLayout(NULL)=
],
> the child widgets will be position relatively to its parent.

I assumed that the positionning you are referring to is the one
accessed UWidget::setLocation(int x, int y) (or UWidget::setBounds for
this matter).
I tried to apply the NULL layout to my root pane
(myContext->getRootPane()->setLayout(NULL)), giving arbitrary
coordinates like (42, 42) to my widgets. I doesn't really works as
expected, since the widgets simply disappear.
Could you give me a bit more information on the (x,y) coordinate
system you are using (if I'm to trust the docs, (0,0) is top left of
the screen), or perhaps I'm missing some call to get that custom
positonning ?

> > I'm looking for a way to get some colors inside the TextEdit
> > component, for "syntax highlighting" purposes.
> I'm sorry, this is on the ToDo-list, but there are more important things =
on
> it, too ...

I'd be glad to contribute some code if you can provide me some
directions as to "where" to update the code. I assume it could inherit
from UTextEdit class since it could share many properties. Beside the
syntax analysis, perhaps could you provide some hint on "how" to apply
colors to parts of the text.

I looked a bit at the font rendered (both basic and ogl) without
seeing anything related to color, but I know from screenshots (alas)
that it's possible - but I'm very reluctant into using CSS styles to
apply the colors (could be heavy for syntax highlighting).
Despite looking at the code (I have no IDE but emacs, grep, less and a
shell - so no "nice" method tree ...), I still don't get to the part
where the widgets are actually *drawn* (UWidget::repaint() ..
UGraphics::? ... ?), and where I could specify the colors.


> Well, actually, here comes some new questions, so I use your quotes to ac=
t as
> separators
>

Regarding widgets, do you think I could make some use of glTranslateX
functions in some way or another to provide something a bit more
"dynamic" or "animated" ? If it's possible, where are the available
entry points to the widget drawing code (without having to mess with
UFO code)

Thanks again,

--
Elie `woe` BLETON
http://www.lwo-lab.net
EPITA - B2 2009 - http://www.epita.fr

[UFO-devel] Re: help me

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

Hi Lidia,

sorry for the late reply ...

Am Dienstag, 28. Februar 2006 19:11 schrieb LIDIAa ARISTA SANCHEZ:
> Can you help me?

I hope I can :)

> I don't understand signal and slot, someday I prove QT and I  understand
> but if I puth in me class someone slot, it said :
>
> no matching function for call to `slot(<unknown type>)'
> candidates are: ufo::USlot0 ufo::slot(void (*)())
>
> Why?, me instruction is:
> combo->sigActivated().connect(slot(DrawMesh::&activar));

If you connect to a member method of a class, you have to provide 2 things:
a) A reference to an object of that class
b) A pointer to a member method

Try something like this:
combo->sigActivated().connect(slot(*combo, &DrawMesh::activar));

As a side note:
I want to achieve what is called delegates in other languages. Main point is 
to provide an object oriented way of plain C call backs (function pointers). 
If you want more info on this topic, search for C++ and delegates or member 
function pointer etc.
But you don't need that info if you just want to use it :)

> I don't understand  very well how I use the next clases UEvent,
> UObjectSlotNode, USlotBase, USlotEven,
> but you said a Dr. Luis M. de la Cruz S.
>
> If you are using Class methods, you need an object slot (in
> uobjectslot.hpp).
>
> but I don't understand this class.

You should use any of the slot class yourself. All the work should be done by 
the overloaded function: slot.

Hope that helps.
If it is still unclear, don't hesitate to ask.

Regards,
Johannes

Re: [UFO-devel] Better position management using ufo/glut

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

Hi,

Am Freitag, 3. M=E4rz 2006 00:27 schrieb Elie `woe` BLETON:
> I subscribed to this mailing lists for a week now and I didn't get any
> mail from it, so I'm quite surprised.=20

I have to pass some of my degree exams these weeks, so I am quite busy.
And some people still insist on writing emails directly to me :)

> I hope there are still some people left reading.
>
> I'm having problems getting libufo positioning my controls the way I
> want them. I can force the  root pane (or the context ?) to take a
> subset of the GLUT area, but the controls inside of it are ordered
> automatically (well, it's possible to force the widgets to get
> displayed horizontally or vertically, but that's not what I'm looking
> for). I'm looking for a way to position them by hand, ideally in
> relative coordinates - but I can cope with absolute screen/context
> coordinates as well.

If you set the layout manager to a NULL pointer [UWidget::setLayout(NULL)],=
=20
the child widgets will be position relatively to its parent.

> On a different subject, I tried to use frames, but it seems they don't
> work in a glut context since any call to myWindow->createFrame()
> returns a NULL pointer. Is there a way to get this working, or is it
> simply impossible ?

Usually you create an internal frame (class UInternalFrame) and add it to t=
he=20
root pane (URootPane::addFrame(UInternalFrame*)).
That should work.

> Last, I'm looking for a way to get some colors inside the TextEdit
> component, for "syntax highlighting" purposes. I have the feeling that
> I will have to code it myself some way, but if someone have some
> advice on the subject, I'd be glad to hear it.

I'm sorry, this is on the ToDo-list, but there are more important things on=
=20
it, too ...

Thanks for considering libUFO. If there are still questions left, don't=20
hesitate to ask.


Regards,
Johannes

[UFO-devel] Better position management using ufo/glut

[Elie `w. B. <dro...@gm...>]

Hello everyone,

I subscribed to this mailing lists for a week now and I didn't get any
mail from it, so I'm quite surprised. I hope there are still some
people left reading.

I'm having problems getting libufo positioning my controls the way I
want them. I can force the  root pane (or the context ?) to take a
subset of the GLUT area, but the controls inside of it are ordered
automatically (well, it's possible to force the widgets to get
displayed horizontally or vertically, but that's not what I'm looking
for). I'm looking for a way to position them by hand, ideally in
relative coordinates - but I can cope with absolute screen/context
coordinates as well.

On a different subject, I tried to use frames, but it seems they don't
work in a glut context since any call to myWindow->createFrame()
returns a NULL pointer. Is there a way to get this working, or is it
simply impossible ?

Last, I'm looking for a way to get some colors inside the TextEdit
component, for "syntax highlighting" purposes. I have the feeling that
I will have to code it myself some way, but if someone have some
advice on the subject, I'd be glad to hear it.

Thanks for your advices,

--
Elie `woe` BLETON
http://www.lwo-lab.net
EPITA - B2 2009 - http://www.epita.fr

Re: [UFO-devel] BoUfo widget deleter

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

Am Freitag 02 Dezember 2005 11:51 schrieb Andreas Beckermann:
[...]
> > > A normal ufo::UObject that is added to the widget using trackPointer()
> > > is _not_ sufficient, as this is deleted by the ufo::UObject d'tor only
> > > and at this point the ufo::UWidget has already been destroyed.
> >
> > Just a quick question:
> > Where do you actually use the UWidget pointer in your BoUfoWidget d'tor?
> > If haven't found any direct access to the UWidget object here:
> > http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/boufowidget.
> >cp p?rev=1.9&view=markup
>
> The deleter does not do so at all (directly).
> It deletes the corresponding BoUfoWidget, which in turn uses the
> ufo::UWidget pointer or related pointers.
>
> This for example:
> http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/bouforadiobutt
>on.cpp?view=markup the d'tor uses the mButtonGroup pointer. That button
> group is deleted by the ufo::UButton that is encapsulated by the
> BoUfoWidget and therefore is deleted by the ufo::UWidget d'tor.

I do not want to nitpick, but the button group is not deleted by UButton.
Anyway it is probably saver to increase the reference count of the button 
group at creation.

> Other (much more difficult to solve) examples can be found in the actual
> boson code. For example in the gameview/bosongameview.cpp

Sorry, still I haven't found an example, where a UWidget pointer is used in 
the BoUfoWidget d'tor.


Regards,
Johannes

Re: [UFO-devel] Xv support using GLX in libUFO...

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

Am Freitag 02 Dezember 2005 00:44 schrieb joe...@op...:
[...]
> > > Am I missing something obvious ?
> > > Does this sound like it is doable ? (in fullscreen ?)
> >
> > Hmm, do you have some sort of a minimal example?
>
> The minimal example is quite big. I'll try to make one using simple Xv if I
> can (I have one somewhere, but....)
>
> > How did you intialize your GLX window in your pure GLX environment?
>
> Slightly differently to the way UFO does it I think. I'm working down the
> path of using the dummy driver and given UFO the context once its
> created... but now I seem to be having trouble opening the DVB card (!)

If you think that there is any way I could help,
please don't hesitate to ask.


Regards,
Johannes

Re: [UFO-devel] Events and layered panes

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

On Tuesday 13 December 2005 18:58, Johannes Schmidt wrote:
> Am Donnerstag 01 Dezember 2005 18:40 schrieb Andreas Beckermann:
> [...]
>
> > > Just a side note:
> > > Keep the GUI stuff clearly separated from your game engine stuff or you
> > > will end up in an unmaintainable, monolithic source tree.
> > > If the event haven't been processed by the GUI, send it to your game
> > > engine.
> >
> > Is there _any_ relation to the patch or are you just trying to be the
> > teacher? ;-)
>
> The relation is that you definitely have one of the most complex GUI
> designs I've ever seen. 

I have? I disagree...
The only "complex" part is that we want transparency (and even translucency in 
the future) and yeah, that's exactly what I need the patch for, that we are 
talking about.
Oh and of course: without transparency libufo would be totally pointless to 
me, I could achieve the same with Qt/KDE (much easier even - no need for a GL 
solution).

> There are easier methods which do not depend on the 
> event dispatching method.
> You are using several nested layered panes, big widget hierarchies and so
> on. Layered panes were designed to handle popups and internal frames.

Yeah, I can see that from the code. libufo is clearly not designed to be used 
in an environment that uses transparency a lot. This was somewhat surprising 
to me, as I have always thought that is the main reason for why someone would 
use OpenGL for a GUI at all.
And that's also what the patch is for: it make libufo support more than only 
simple popups and internal frames.

> And all I can see on the screen shots are a command frame and
> some text buffers.

Oh wow, I can see much more. I can see a minimap (often only the boson logo, 
as the minimap is not available to the player - but it's the same widget) and 
the game area itself. Both are BoUfoWidget objects (the wrapper around 
ufo::UWidget in boson).

> Now if neither the command frame nor the text frame or other GUI elements
> processed the event, it should be processed by the game engine.

There are many more.
Firs of all the most visible layered pane contains the
* chat widget
* pause label
* what you call the command frame (which contains the actual command frame, 
the minimap and a few debug widgets)

These should be separate widgets in the same layered pane, as they all must 
overlap.

This layered pane is embedded into a "main" layered pane, which is used by the 
actual game GUI. Besides the above mentioned widget (the layered pane) it 
contains
* the canvas widget (reponsible for rendering the actual game world, i.e. 
ground + units)
* placement preview widget
* tooltip label
* cursor widget
* selectionrect widget
* several debugging widgets

Most, but not all of them can receive events. And it is very (!!!) important 
that they receive them in the correct order. For example if the canvas widget 
receives a click on the map before another widget, it'll eat the event. This 
is not intended, if the mouse is currently on a button in the commandframe.

Also widgets can overlap (that is intended and in most cases very important!) 
and so it can happen that a button is on top of a different button (this is 
not intended, but unavoidable .. at least by code design). And here the 
priorities must be correct, too - if widget A is on top of B, then A must 
receive all events before B does. But if A doesn't want the events, then B 
must receive them, before the game GUI does.

> Or you could register event listeners at the internal frame, which is used
> to display the command frame, 

It isn't, it's a widget.
I don't know if the same would be possible with widgets (and not only frames) 
- but the point is I don't want to. The libufo event listeners are not very 
powerful and not really nice to use. In addition I simply don't trust them, 
as they are pretty much unused in libufo. AFAICS only menu/popups use them at 
all and even they do that for extremely simple tasks only. So I'd have to 
figure out how to use them correctly myself, and even then would risk to find 
bugs.
I don't want to debug yet another piece of code in libufo - especially since 
it's very hard to debug libufo (not because of the code itself - the code 
itself is pretty good. But rather because of the issues I mentioned long ago, 
e.g. *.hpp heades and especially distinction of src/ and include/ directories 
which force me to have several editor sessions opened all the time, only to 
perform simple tasks. Most libufo debugging sessions take much longer than 
simply rewriting all of the relevant code).

And last but not least: the patch works. It works very well, even in my 
"complex" GUI design (which I consider a "normal" GUI design from a game 
POV). So why not include a patch that supports both, simple and complex 
designs instead of the simple ones only?

> and redispatch it to your game widget if none 
> of the buttons did process the event (otherwise it won't bubble up).
>
> Both are independent of the way how event dispatching is done and
> there are surely more solutions to do that.

This sounds pretty much like "do the correct event dispatching yourself". Why 
doesn't the library do that? I thought that's the main point of a widget 
toolkit?

> [...]
>
> > > I thought of adding a separate event dispatcher (which can be added to
> > > the display), which chooses to which widget(s) the event is sent.
> > > Anyway, this may take some time, as I am really busy these days.
> >
> > May I read this as a "this patch won't ever make it into official cvs" ?
>
> Yes.
> Probably it is best to override UXContext instead of patching
> UAbstractContext.

Honestly: not a surprise to me. Not a single non-trivial patch I sent in got 
ever applied. And even the trivial ones usually got rewritten.
I didn't really expect it to change anytime soon.

> Regards,
> Johannes

CU
Andi

Re: [UFO-devel] $Id

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

Am Mittwoch 30 November 2005 22:13 schrieb Andreas Beckermann:
> Hi
> just a quick question: do you actually use the $Id feature of CVS in the
> *.cpp/*.hpp files?

I have used them for some internal checking in times where I do not
have access to the sourceforge CVS tree.

> I remember those lines were removed in the KDE project a long time ago,
> because they primarily increase the size of the diffs.
>
> I am asking because I am currently updating our libufo copy and the $Id
> lines mean that I have to check _every_ single file for changes, as they of
> course are different in two different projects.

Perhaps you could use some perl scripts to remove those lines from 
diffs/history files ...


Regards,
Johannes

Re: [UFO-devel] Events and layered panes

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

Am Donnerstag 01 Dezember 2005 18:40 schrieb Andreas Beckermann:
[...]
> > Just a side note:
> > Keep the GUI stuff clearly separated from your game engine stuff or you
> > will end up in an unmaintainable, monolithic source tree.
> > If the event haven't been processed by the GUI, send it to your game
> > engine.
>
> Is there _any_ relation to the patch or are you just trying to be the
> teacher? ;-)

The relation is that you definitely have one of the most complex GUI
designs I've ever seen. There are easier methods which do not depend on the 
event dispatching method.
You are using several nested layered panes, big widget hierarchies and so on.
Layered panes were designed to handle popups and internal frames.

And all I can see on the screen shots are a command frame and
some text buffers.
Now if neither the command frame nor the text frame or other GUI elements 
processed the event, it should be processed by the game engine.
Or you could register event listeners at the internal frame, which is used to 
display the command frame, and redispatch it to your game widget if none of 
the buttons did process the event (otherwise it won't bubble up).

Both are independent of the way how event dispatching is done and
there are surely more solutions to do that.

[...]
> > I thought of adding a separate event dispatcher (which can be added to
> > the display), which chooses to which widget(s) the event is sent.
> > Anyway, this may take some time, as I am really busy these days.
>
> May I read this as a "this patch won't ever make it into official cvs" ?

Yes.
Probably it is best to override UXContext instead of patching 
UAbstractContext.


Regards,
Johannes

Re: [UFO-devel] GL/gl.h, GL/glx.h

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

Hi,

sorry, had to meet a very important dead line ...

Am Mittwoch 30 November 2005 22:41 schrieb Andreas Beckermann:
[...]
> Well, it is meant
> as a feature request: can we have some kind of configure check or so that
> defines the to-be-included file in config.h ?
> -> libufo could then use the define instead of a hardcoded GL/gl.h and
> GL/glx.h to include the relevant files.

I could set up something which is similar to the data dir selection.
If a configure param is specified, use this include, otherwise use the
default includes.

Please register a feature request at the sourceforge tracker as reminder:
http://sourceforge.net/tracker/?group_id=27973&atid=392159


Regards,
Johannes

[UFO-devel] $Id

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

Hi
just a quick question: do you actually use the $Id feature of CVS in the 
*.cpp/*.hpp files?
I remember those lines were removed in the KDE project a long time ago, 
because they primarily increase the size of the diffs.

I am asking because I am currently updating our libufo copy and the $Id lines 
mean that I have to check _every_ single file for changes, as they of course 
are different in two different projects.
What do you use them for?

CU
Andi

[UFO-devel] GL/gl.h, GL/glx.h

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

Hi
the attached includes bogl.h instead of GL/gl.h and boglx.h instead of 
GL/glx.h.

Of course this is nonsense in the official libufo cvs, as bogl.* is specific 
to the boson project. Why do I send this anyway? Well, it is meant as a 
feature request: can we have some kind of configure check or so that defines 
the to-be-included file in config.h ?
-> libufo could then use the define instead of a hardcoded GL/gl.h and 
GL/glx.h to include the relevant files.

This would save me from applying the attached patch every time I update our 
libufo copy.

CU
Andi

Re: [UFO-devel] BoUfo widget deleter

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

On Thursday 01 December 2005 15:33, Johannes Schmidt wrote:
> Am Mittwoch 30 November 2005 23:52 schrieb Andreas Beckermann:
> > Hi
> > the attached patch is pretty controversial, but I decided to give it a
> > try anyway.
> >
> > In Boson we cannot use libufo directly, due to
> > a) conflicting toolkits
> > b) different APIs
>
> Well, as may best please you.
>
> > Therefore I have written a BoUfo library that provides the required
> > widgets in wrapper classes. However this solution has one major problem:
> > destruction. A statement such as
> >   ufoWidget->removeAll();
> > would delete all ufo widgets, however not the corresponding wrapper
> > objects. Therefore I have patched our libufo copy to introduce a "widget
> > deleter". This is simply an object that is deleted at the beginning of
> > the ufo::UWidget d'tor. Any class deriving from this class can do cleanup
> > tasks that may be necessary before the widget actually is deleted.
> >
> > A normal ufo::UObject that is added to the widget using trackPointer() is
> > _not_ sufficient, as this is deleted by the ufo::UObject d'tor only and
> > at this point the ufo::UWidget has already been destroyed.
>
> Just a quick question:
> Where do you actually use the UWidget pointer in your BoUfoWidget d'tor?
> If haven't found any direct access to the UWidget object here:
> http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/boufowidget.cp
>p?rev=1.9&view=markup

The deleter does not do so at all (directly).
It deletes the corresponding BoUfoWidget, which in turn uses the ufo::UWidget 
pointer or related pointers.

This for example:
http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/bouforadiobutton.cpp?view=markup
the d'tor uses the mButtonGroup pointer. That button group is deleted by the 
ufo::UButton that is encapsulated by the BoUfoWidget and therefore is deleted 
by the ufo::UWidget d'tor.

Other (much more difficult to solve) examples can be found in the actual boson 
code. For example in the gameview/bosongameview.cpp

> Regards,
> Johannes

CU
Andi

Re: [UFO-devel] BoUfo widget deleter

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

Am Mittwoch 30 November 2005 23:52 schrieb Andreas Beckermann:
> Hi
> the attached patch is pretty controversial, but I decided to give it a try
> anyway.
>
> In Boson we cannot use libufo directly, due to
> a) conflicting toolkits
> b) different APIs

Well, as may best please you.

> Therefore I have written a BoUfo library that provides the required widgets
> in wrapper classes. However this solution has one major problem:
> destruction. A statement such as
>   ufoWidget->removeAll();
> would delete all ufo widgets, however not the corresponding wrapper
> objects. Therefore I have patched our libufo copy to introduce a "widget
> deleter". This is simply an object that is deleted at the beginning of the
> ufo::UWidget d'tor. Any class deriving from this class can do cleanup tasks
> that may be necessary before the widget actually is deleted.
>
> A normal ufo::UObject that is added to the widget using trackPointer() is
> _not_ sufficient, as this is deleted by the ufo::UObject d'tor only and at
> this point the ufo::UWidget has already been destroyed.

Just a quick question:
Where do you actually use the UWidget pointer in your BoUfoWidget d'tor?
If haven't found any direct access to the UWidget object here:
http://cvs.sourceforge.net/viewcvs.py/boson/code/boson/boufo/boufowidget.cpp?rev=1.9&view=markup


Regards,
Johannes

Re: Re: [UFO-devel] Xv support using GLX in libUFO...

[<joe...@op...>]

> > I'm working on a project which displays digital TV on an Epia box 
> using the
> > mpeg acceleration (through XvMC). I previously used fltk as its OSD
> > interface, but I'd like to use libUFO to allow me to get 3D objects
> > overlayed on TV. I previously had a GLX program which had 3D objects 
> over
> > TV (which I still have working), but my efforts today with libUFO have 
> hit
> > a bit of a dead end.
> >
> > I have used the UXGLXDriver and taken the Window and Display * from it
> 
> You take the window from the GLX video device (UXGLXDevice or sth.) 
> right?
> The glx driver just knows of the root window.

Yep.

> > fed them to the XvMC startup program, but it doesn't seem to work ;
> 
> You pure GLX program did work?

Yes and it still does. I have 2 squares in 3D overlayed on top of a playing DVB stream.

> I do not have experience with mixing GL with other drawing stuff.
> How does XvMC draws its videos? Via Xlib?

It uses Xvideo - which is chromakeyed on by the hardware (every pixel of a set colour is replaced by a pixel from a separate given framebuffer when the pixel colour is sent out to the monitor - no data copying required).

> > Am I missing something obvious ?
> > Does this sound like it is doable ? (in fullscreen ?)
> 
> Hmm, do you have some sort of a minimal example?

The minimal example is quite big. I'll try to make one using simple Xv if I can (I have one somewhere, but....)

> How did you intialize your GLX window in your pure GLX environment?

Slightly differently to the way UFO does it I think. I'm working down the path of using the dummy driver and given UFO the context once its created... but now I seem to be having trouble opening the DVB card (!)

Thanks for the reply.

Bye - Joel.

Re: [UFO-devel] signals and slots

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

Am Mittwoch 30 November 2005 23:05 schrieb Andreas Beckermann:
> Hi
> are signals/slots still supposed to work with the receiver object not being
> a ufo::UObject?
> I get the following error:
>
> ../../../ufo/include/ufo/signals/uobjectslot.hpp: In constructor
> 'ufo::UObjectSlotNode::UObjectSlotNode(void (*)(void*), Obj*, void
> (ufo::UObject::*)()) [with Obj = BoUfoWidget]':
> ../../../ufo/include/ufo/signals/uobjectslot.hpp:177:   instantiated from
> 'ufo::USlot1<P1> ufo::slot(Obj&, void (Obj::*)(P1)) [with P1 =
> ufo::UMouseEvent*, Obj = BoUfoWidget]'
> ../../../boson/boufo/boufowidget.cpp:448:   instantiated from here
> ../../../ufo/include/ufo/signals/uobjectslot.hpp:90: error: invalid
> static_cast from type 'BoUfoWidget*' to type 'ufo::UObject*'
> ../../../boson/boufo/boufowidget.cpp: At global scope:
>
> Changing the static_cast into a dynamic_cast makes the compile time error
> go away .. whether a runtime error is left behind is still to be tested.

That should work. You may even omit the cast as this is an upcast.

It seems that my compiler realized that this line of code is only executed if 
object is derived from UObject (due to the static template check).

But indeed, some compiler may complain about that; I'll change this.


Regards,
Johannes

Re: [UFO-devel] UBoxLayout

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

On Thursday 01 December 2005 15:09, Johannes Schmidt wrote:
> Am Mittwoch 30 November 2005 23:05 schrieb Andreas Beckermann:
> > Hi
> > the attached patch implements "stretch" areas for UBoxLayout and makes
> > widgets use remaining space.
>
> Something like this is already implemented using the flex attribute
> (I think since Feb 05) which corresponds to the XUL flex attribute.
>
> [...]
>
> > After that I am going to move this file into our "ufoext" library and
> > make a "don't use UBoxLayout - use this instead" policy in BoUfo.
>
> If the flex attribute (which truly is hardly documented outside of the XUL
> files) does not fit your needs, this will be the best way.

At least the hint that flex is defined by XUL would have been helpful.. it 
seems that the "flex" attribute should do the same as the "stretch" attribute 
in my patch. Well, I know that my code is working, so I don't see much point 
in porting over to the "official" code. And certainly not while that official 
code is undocumented. I hate working with black boxes if there are better 
ways.
So I'm gonna maintain this in an extension library, just like the multiline 
label patch and some smaller things :)

> Regards,
> Johannes

CU
Andi

Re: [UFO-devel] Events and layered panes

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

On Thursday 01 December 2005 15:23, Johannes Schmidt wrote:
> Am Donnerstag 01 Dezember 2005 00:01 schrieb Andreas Beckermann:
[...]
> Just a side note:
> Keep the GUI stuff clearly separated from your game engine stuff or you
> will end up in an unmaintainable, monolithic source tree.
> If the event haven't been processed by the GUI, send it to your game
> engine.

Is there _any_ relation to the patch or are you just trying to be the 
teacher? ;-)

> To your problem:

I don't have a problem, the attached patch fixed pretty much everything a long 
time ago for me.

> I thought of adding a separate event dispatcher (which can be added to the
> display), which chooses to which widget(s) the event is sent.
> Anyway, this may take some time, as I am really busy these days.

May I read this as a "this patch won't ever make it into official cvs" ?

> cu,
> Johannes

CU
Andi

Re: [UFO-devel] Events and layered panes

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

Am Donnerstag 01 Dezember 2005 00:01 schrieb Andreas Beckermann:
> Hi
> attached is a patch that I have sent before, I believe (or at least
> mentioned).

Sorry, there are probably several patches which are lost in email flood.
I've been very busy last weeks doing some uni stuff.

> It implements layered pane compatible event handling. 
> Umm, well, this patch has been used in Boson for quite some time, here the
> comment in my README about this patch:
>
> - Patch to uabstractcontext.hpp, uabstractcontext.cpp and uwidget.cpp
>   to improve events for our needs:
>   Instead of delivering a mouse event to root->getVisibleWidgetAt(), we
>   implement a getVisibleWidgetsDFS() function, that starts at the root and
> finds
>   all currently visible widgets (at the relevant point) using a depth first
> search
>   and returns them in a stack.
>   We then dispatch it to every widget on the stack until one widget
> consumes the event (in that case we stop then).
>   This especially fixes layered panes: previously an event was delivered to
> the
>   topmost layer only and to the layered pane itself, if the widget was not
>   interested in that event. Now the event is first delivered to the topmost
>   layer, then to the layers below it, then to the layered pane.
>
>
> This patch makes pretty much the difference between "libufo is usable" and
> "libufo is unusable" for us: it is extremely important that a click on a
> button is dispatched to the button and clicks on everything else is
> delivered to the stuff below that. (yeah, that was the simple version)

Just a side note:
Keep the GUI stuff clearly separated from your game engine stuff or you will 
end up in an unmaintainable, monolithic source tree.
If the event haven't been processed by the GUI, send it to your game engine.

To your problem:
I thought of adding a separate event dispatcher (which can be added to the 
display), which chooses to which widget(s) the event is sent.
Anyway, this may take some time, as I am really busy these days.


cu,
Johannes

Re: [UFO-devel] Xv support using GLX in libUFO...

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

Am Donnerstag 01 Dezember 2005 04:48 schrieb joe...@op...:
> Firstly, excellent work on the libUFO library!

Thanks! :)

> I'm working on a project which displays digital TV on an Epia box using the
> mpeg acceleration (through XvMC). I previously used fltk as its OSD
> interface, but I'd like to use libUFO to allow me to get 3D objects
> overlayed on TV. I previously had a GLX program which had 3D objects over
> TV (which I still have working), but my efforts today with libUFO have hit
> a bit of a dead end.
>
> I have used the UXGLXDriver and taken the Window and Display * from it

You take the window from the GLX video device (UXGLXDevice or sth.) right?
The glx driver just knows of the root window.

> and 
> fed them to the XvMC startup program, but it doesn't seem to work ;

You pure GLX program did work?
I do not have experience with mixing GL with other drawing stuff.
How does XvMC draws its videos? Via Xlib?

> 1. In 
> windowed mode it thinks its putting each of the surfaces, but nothing is
> displayed (but audio is coming out fine). 2. In full screen mode it hangs
> on the first put surface. (the previous GLX demo I made was only windowed).

Well, I didn't even hope that the fullscreen support works :)
I do not use fullscreen modes and can't remember when I have used
them last time.
IIRC, the fullscreen support is done using the _NET extension of window 
managers, i.e. the UFO code stays the same.

> Am I missing something obvious ?
> Does this sound like it is doable ? (in fullscreen ?)

Hmm, do you have some sort of a minimal example?
How did you intialize your GLX window in your pure GLX environment?

Atm, I do not know what could be the problem ...


Regards,
Johannes

Re: [UFO-devel] UBoxLayout

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

Am Mittwoch 30 November 2005 23:05 schrieb Andreas Beckermann:
> Hi
> the attached patch implements "stretch" areas for UBoxLayout and makes
> widgets use remaining space.

Something like this is already implemented using the flex attribute
(I think since Feb 05) which corresponds to the XUL flex attribute.

[...]
> After that I am going to move this file into our "ufoext" library and make
> a "don't use UBoxLayout - use this instead" policy in BoUfo.

If the flex attribute (which truly is hardly documented outside of the XUL 
files) does not fit your needs, this will be the best way.


Regards,
Johannes

[UFO-devel] BoUfo widget deleter

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

Hi
the attached patch is pretty controversial, but I decided to give it a try 
anyway.

In Boson we cannot use libufo directly, due to
a) conflicting toolkits
b) different APIs

Therefore I have written a BoUfo library that provides the required widgets in 
wrapper classes. However this solution has one major problem: destruction. A 
statement such as
  ufoWidget->removeAll();
would delete all ufo widgets, however not the corresponding wrapper objects. 
Therefore I have patched our libufo copy to introduce a "widget deleter".
This is simply an object that is deleted at the beginning of the ufo::UWidget 
d'tor. Any class deriving from this class can do cleanup tasks that may be 
necessary before the widget actually is deleted.

A normal ufo::UObject that is added to the widget using trackPointer() is 
_not_ sufficient, as this is deleted by the ufo::UObject d'tor only and at 
this point the ufo::UWidget has already been destroyed.

Of course this patch does not introduce any direct functionality for libufo, 
however it does provide an important feature for projects that need to 
implement wrapper classes.

CU
Andi