libufo-devel — Discussion forum for users and developers

Re: [UFO-devel] UTextEdit reacting strangely

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

Hi Elie,

On Friday 28 April 2006 18:16, Elie `woe` BLETON wrote:
[...]
> Offset should be adjusted on the displayed text start instead of the
> absolute text start, but isn't for some reason. I wasn't able to find the
> displayed text start (should be a "line offset"). If I knew where to find
> it, I think I could probably patch this in order to get the mouse selection
> work probably.
> Please note that the (only) way I change the displayed text start is to add
> enough text in the TextEdit, then move the caret down using arrow keys.

This is entirely done in src/ui/ubasicstyle.cpp
line 873 to 881.
Here, the required offset is computed. But so far, you don't have a way to 
retrieve that value.
I'd really like to remove this piece of code as it's really messy.
Probably a scroll pane should work.
Otherwise an entirely new solution should be considered.

> I don't understand how the text manages to scroll correctly when the caret
> moves. I'm looking for some more insight, since I spent already most of the
> day crawling in the code without much success.
>
> Side note: In utextlayout.hpp, line 50, shouldn't "public" be "private".
> Writing "public" twice doesn't issue a warning, but what's the point in
> writing property-like methods if the members are publicly available.

Thanks.
Well, historically issues (as always). This used to be a struct ...

The text API is still a subject to change ...


Regards,
Johannes

Re: [UFO-devel] UTextEdit reacting strangely

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

Hello there,

Relating to the "mouse click selects crap" problem:
I tried to focus a bit on this problem, and provide some fix. I'm strugglin=
g
to find the problem. The position returned when clicking the mouse is
perfectly correct, but the line is wrong.

I think the problem is in utextlayout.cpp, in method
UTextLayout::viewToModel(pos), since it's iterating on lines from the
beginning of the text.

Offset should be adjusted on the displayed text start instead of the
absolute text start, but isn't for some reason. I wasn't able to find the
displayed text start (should be a "line offset"). If I knew where to find
it, I think I could probably patch this in order to get the mouse selection
work probably.
Please note that the (only) way I change the displayed text start is to add
enough text in the TextEdit, then move the caret down using arrow keys.

I don't understand how the text manages to scroll correctly when the caret
moves. I'm looking for some more insight, since I spent already most of the
day crawling in the code without much success.

Side note: In utextlayout.hpp, line 50, shouldn't "public" be "private".
Writing "public" twice doesn't issue a warning, but what's the point in
writing property-like methods if the members are publicly available.

As always, thanks in advance ...

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

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

Am Montag, 24. April 2006 20:36 schrieb Elie `woe` BLETON:
> Now that cursor keys are corrected, I noticed another error in the
> UTextEdit.
>
> If you create a UTextEdit filled with text large enough to fill the box a
> few times. Now move the cursor using the key, and change "page". Now select
> a position using the mouse. Kablam, the cursor is now at the position under
> the mouse, but the text around it is on the first page. It's like cursor
> coordinates are calculated with values that are not updated when the cursor
> moves.
> I'm still using GLUT, but this is reproductible in the "text" test program,
> so I guess it's pretty much the same for everyone for that matter.

The whole text moving for text widgets is borkened (the problem here is 
probably incorrect focusing with mouse, i.e. the wrong position in the text 
widget is returned when clicking with the mouse ...?).
Perhaps it should be removed in favor of a simple scroll pane ...


Regards,
Johannes

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

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

Hi Andreas,

Am Sonntag, 23. April 2006 12:28 schrieb Andreas Beckermann:
> On Tuesday 11 April 2006 18:43, Johannes Schmidt wrote:
> > You really should set up your own projection matrix when using that.
> > The current ugl_graphics code adds 0.375f to coordinates according to
> > OpenGL red book Appendix H.
>
> Indeed, that explains a lot.
> Why is that not documented at all? Neither in any API docs, nor in the
> actual source code..

It's specific to OpenGL and the graphics object was made to hide details from 
OpenGL.
It is documented above the call to glOrtho (line 116). In the beginning, the 
translation was directly in the call to glOrtho.

> I find it very unintuitive, that a projection matrix of size (width+1,
> height+1) is set up. It makes obviously sense, but if such things happen
> without letting the user know, it has some pretty unuseful effects (as my
> patches show).
>
> Ok, so a (width+1,height+1) projection is of course correct, as ufo always
> adds an offset to the specified (integer) coordinates, i.e. my patches are
> broken.
[...]
> I haven't checked the other references, but since the redbook is the
> primary source for most informations, I'd expect that most of them discuss
> exactly the same issue.
> The thing that you lacked to quote was the important part of this code, as
> it justifies, why a "wrong" projection matrix is used:
>   glMatrixMode(GL_MODELVIEW);
>   glLoadIdentity();
>   glTranslatef(0.375, 0.375, 0.0);
> So you setup a projection matrix on a 2d area with size (width+1, height+1)

I wouldn't call it size as this is somewhat misleading.
The glOrtho call specifies the clipping planes.

> and then add an offset of 0.375 to all coordinates. It makes sense when you
> think about the fact that (in order to achieve pixel exact operations)

OpenGL doesn't guarantee pixel perfect rendering (but this way,
it works with most of the drivers).

> for 
> some operations you need to use 0.0, and for some operations you need to
> use 0.5 as coordinates for pixel 0 (or the center of it).
>
> The idea of the larger projection along with the offset is, that it is a
> good compromise, i.e. you can always use 0.0, no matter which operation you
> currently use.

Is it larger? I'd disagree.
Everything right of "left" is rendered, everything to the right of "right" is 
clipped.

> That makes indeed sense, however I still don't understand the way you use
> it. You setup a projection matrix of size (width+1, height+1) (btw: I'd add
> a comment about this here!) but then you do NOT add the translation to the
> modelview matrix.
> Instead you add that translation in every operation that might need the
> translation. Why do you do that?

If you look at resetDeviceViewMatrix, you'll see that there is a commented 
call to glTranslatef() which was used before.
I tried to make a work-around for some broken ATI drivers (and play a bit with 
the translation variables), but I didn't get a solution which worked for all 
drivers, so I just use 0.375 as it works with most set-ups.

> If you modify every operation anyway, then you could simply use the normal
> projection matrix and add the correct offset (instead of the 0.375
> compromise) to every operation.
> So why do you add the 0.375 to every separate operation?
>
> Other than that I can now agree that both of my patches are broken and that
> ufo cvs _does_ behave correctly.
>
> > > > And I have seen that the width should be right - left which leads to:
> > >
> > > Where have you seen that?
> >
> > Can't remember where it was used in this case, but this is also the usual
> > definition when using the RECT structure on windows.
> > Just search MSDN.
>
> I find that pretty hard to believe, it would be _very_ unusual. Two
> examples: * file:///usr/share/qt3/doc/html/qrect.html#width
> * your own code: includes/ufo/util/urectangle.hpp: from contains() you can
> see that points with pos.x=x+w are not inside of the rect anymore, i.e.
> right:=x+w-1

I said MSDN, not QT or UFO (UFO doesn't use left, right parameters at all; it 
uses location and size).

[...]
> If you create a projection matrix of size (w,h) on a window with (w,h) then
> I think it's pretty obvious, how positions inside the projection matrix are
> supposed to be projected onto the window :-)

I should really take a pencil and check how vertex data is projected to screen 
coordinates ...

> And indeed they will be!
> -> The problem discussed above comes only from the fact that in OpenGL some
> operations require e.g. glRect(0, 0, 1, 1) to fill pixel (0,0) but some
> (e.g. points) require (0.5,0.5) to hit exactl pixel (0,0). The offset of
> 0.375 solves this problem, but it of course requires to have a larger width
> and height.

No, the width and height are correct (clipping planes!).
If you don't y-flip the projection matrix, it actually works without the 
translation for many drivers and cards.
0.375 translation just ensures for most operations to do the right thing [TM].


Regards,
Johannes

Re: [UFO-devel] UTextEdit reacting strangely

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

Now that cursor keys are corrected, I noticed another error in the
UTextEdit.

If you create a UTextEdit filled with text large enough to fill the box a
few times. Now move the cursor using the key, and change "page". Now select
a position using the mouse. Kablam, the cursor is now at the position under
the mouse, but the text around it is on the first page. It's like cursor
coordinates are calculated with values that are not updated when the cursor
moves.
I'm still using GLUT, but this is reproductible in the "text" test program,
so I guess it's pretty much the same for everyone for that matter.

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

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

>
> The bug is in the GLUT-to-UFO conversion of keys.
> The third parameter of pushKey{Up,Down} should be 0, e.g.:
> void
> specialUpFunc(int key, int, int) {
>         display->pushKeyUp(context, mapGlutSpecialKey(key), 0);
>         if (context->needsRepaint()) {
>                 glutPostRedisplay();
>         }
> }
> otherwise the key is echoed as char key event.


Note that specialFunc(int key, int, int) AND specialUpFunc(int key, int,
int) have to get patched in the same way in order to correctly solve the
bug.
HOME/END keys are not handled as it seems, but I didn't really looked close=
r
than simply testing the keystrokes.


Thanks for reporting the bug. The developer CVS is already fixed and
> it should soon be available via anonymous CVS.
>
>
Well, thanks for resolving it :)

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] UTextEdit reacting strangely

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

On Sunday 23 April 2006 15:38, Elie `woe` BLETON wrote:
> This is probably my tenth problem submitted here, and I'd like to thanks
> Johannes for the previous nine solutions to most of my problems. Before
> submitting the problem, I'd like to thank him for his work that allowed us
> to create something that looks fine and works in a fine way.

Thanks!

> My current problem is that the cursor keys (or any other "special" key that
> is supposed to act on the cursor) are inserting text characters in the
> text, making it impossible to correctly move in the edited text. I'm using
> libufo in a GLUT context, and I simply pasted my key handling code from the
> GLUT sample.

The bug is in the GLUT-to-UFO conversion of keys.
The third parameter of pushKey{Up,Down} should be 0, e.g.:
void
specialUpFunc(int key, int, int) {
	display->pushKeyUp(context, mapGlutSpecialKey(key), 0);
	if (context->needsRepaint()) {
		glutPostRedisplay();
	}
}
otherwise the key is echoed as char key event.

Thanks for reporting the bug. The developer CVS is already fixed and
it should soon be available via anonymous CVS.


Regards,
Johannes

[UFO-devel] UTextEdit reacting strangely

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

Hello again fellow UFO users,

This is probably my tenth problem submitted here, and I'd like to thanks
Johannes for the previous nine solutions to most of my problems. Before
submitting the problem, I'd like to thank him for his work that allowed us
to create something that looks fine and works in a fine way.

My current problem is that the cursor keys (or any other "special" key that
is supposed to act on the cursor) are inserting text characters in the text=
,
making it impossible to correctly move in the edited text. I'm using libufo
in a GLUT context, and I simply pasted my key handling code from the GLUT
sample.

I put a few screenshots online showing both our shiny interface (there are
five of them), and four showing the UTextEdit with cursor problems. These
are available on http://www.lwo-lab.net/nawart.

Code source is available via svn (information is specified on the same
page), and HEAD revision (should be 59) exhibits the problem for sure. I ca=
n
paste specific parts of the sourcecode that may seem relevant to one of you
if requested (either on the list or in private).

Thanks in advance !

--
{ drozofil -- www.lwo-lab.net }

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

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

Hi again

On Tuesday 11 April 2006 18:43, Johannes Schmidt wrote:
> You really should set up your own projection matrix when using that.
> The current ugl_graphics code adds 0.375f to coordinates according to
> OpenGL red book Appendix H.

Indeed, that explains a lot.
Why is that not documented at all? Neither in any API docs, nor in the actual 
source code..
I find it very unintuitive, that a projection matrix of size (width+1, 
height+1) is set up. It makes obviously sense, but if such things happen 
without letting the user know, it has some pretty unuseful effects (as my 
patches show).

Ok, so a (width+1,height+1) projection is of course correct, as ufo always 
adds an offset to the specified (integer) coordinates, i.e. my patches are 
broken.

> > > This sounds very reasonable, too.
> > >
> > > On the other side, every 2D setup I have seen so far uses this approach
> > > with 0, 0 and width, height (well, they could be wrong, too).
> >
> > Every? Examples?
>
> Just a few:
>
> OpenGL FAQ on opengl.org:
>  gluOrtho2D (0, windowWidth, 0, windowHeight);

You have taken this line out of context (see below).

> OpenGL red book Appendix H

btw: in my copy it's still Appendix G. This is about the appendix "Programming 
Tips".

> gluOrtho2D(0, width, 0, height);

Again out of context.

[...]

I haven't checked the other references, but since the redbook is the primary 
source for most informations, I'd expect that most of them discuss exactly 
the same issue.
The thing that you lacked to quote was the important part of this code, as it 
justifies, why a "wrong" projection matrix is used:
  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity();
  glTranslatef(0.375, 0.375, 0.0);
So you setup a projection matrix on a 2d area with size (width+1, height+1) 
and then add an offset of 0.375 to all coordinates. It makes sense when you 
think about the fact that (in order to achieve pixel exact operations) for 
some operations you need to use 0.0, and for some operations you need to use 
0.5 as coordinates for pixel 0 (or the center of it).

The idea of the larger projection along with the offset is, that it is a good 
compromise, i.e. you can always use 0.0, no matter which operation you 
currently use.

That makes indeed sense, however I still don't understand the way you use it.
You setup a projection matrix of size (width+1, height+1) (btw: I'd add a 
comment about this here!) but then you do NOT add the translation to the 
modelview matrix.
Instead you add that translation in every operation that might need the 
translation. Why do you do that?
If you modify every operation anyway, then you could simply use the normal 
projection matrix and add the correct offset (instead of the 0.375 
compromise) to every operation.
So why do you add the 0.375 to every separate operation?

Other than that I can now agree that both of my patches are broken and that 
ufo cvs _does_ behave correctly.

> > > And I have seen that the width should be right - left which leads to:
> >
> > Where have you seen that?
>
> Can't remember where it was used in this case, but this is also the usual
> definition when using the RECT structure on windows.
> Just search MSDN.

I find that pretty hard to believe, it would be _very_ unusual. Two examples:
* file:///usr/share/qt3/doc/html/qrect.html#width
* your own code: includes/ufo/util/urectangle.hpp: from contains() you can see 
that points with pos.x=x+w are not inside of the rect anymore, i.e. 
right:=x+w-1

> > It would be _possible_ to use such a definition, but very unlikely. This
> > could mean two things only:
> > a) width := (number of pixels in between right and left) - 1
> > -> this is imho a very unusual definition. In particular that means that
> > if right==left (i.e. exactly one pixel), then width==0, which is pretty
> > inintuitive.
> > --> I am pretty sure OpenGL doesn't use that. If it does, your
> > glViewport() call before the glOrtho() call is broken :-)
> > b) right := leftmost pixel to the right of the rect that is _not_
> > visible. -> again, possible, but unintuitive definition. In particular
> > this means that right is completely different to left, as left is clearly
> > defined as the first pixel that is _inside_ the rect.
>
> Remember: We talk about a projection matrix.
> OpenGL doesn't know what pixels are in this state of processing vertex
> data. Left, right, etc. define clipping planes.

If you create a projection matrix of size (w,h) on a window with (w,h) then I 
think it's pretty obvious, how positions inside the projection matrix are 
supposed to be projected onto the window :-)
And indeed they will be!
-> The problem discussed above comes only from the fact that in OpenGL some 
operations require e.g. glRect(0, 0, 1, 1) to fill pixel (0,0) but some (e.g. 
points) require (0.5,0.5) to hit exactl pixel (0,0). The offset of 0.375 
solves this problem, but it of course requires to have a larger width and 
height.

> Regards,
> Johannes

CU
Andi

Re: [UFO-devel] Overriding processKeyEvent

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

On Monday 17 April 2006 23:38, Elie `woe` BLETON wrote:
> I'm currently trying to slightly enhance/customize ULineEdit to provide
> some basic "shell like" features, which supposes I can grab some of the
> keys that processKeyEvent() doesn't handle the way I want it to. I tried to
> create some inherited class of ULineEdit providing another implementation
> of processKeyEvent, filtering on keys that are of some interest to me, and
> sending the others to the regular ULineEdit processKeyEvent.
>
> My new object correctly receives key signals, but fails to propagate the
> "message" to its ancestor. I tried to add a "ULineEdit::processKeyEvent(e)"
> in my code in order to propagate the key event, but it fails do anything
> useful : content of the ULineEdit isn't updated properly.

Hmm, this should theoretically work.
I've attached a minimal example (modified base.cpp) which works for me[TM].
Perhaps you've forgotten to mark the event consumed so that it is not 
processed again ... ?

> I'm quite a bit 
> puzzled on this matter, so perhaps one of you guys can give me some hints
> on how I can achieve such a thing as "handling some specific keys". I'm not
> sure this was the right approach, and I'm completely open to brand new
> solutions if they provide results.

There are two ways to handle events in libUFO:
* Signals & Slots: Mainly used to catch events from built-in widgets or for 
simple event processing
* Overriding process*Event methods: If you want to change the whole behaviour 
of the event handling.


Regards,
Johannes

[UFO-devel] Overriding processKeyEvent

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

Hello everyone,

I'm currently trying to slightly enhance/customize ULineEdit to provide som=
e
basic "shell like" features, which supposes I can grab some of the keys tha=
t
processKeyEvent() doesn't handle the way I want it to. I tried to create
some inherited class of ULineEdit providing another implementation of
processKeyEvent, filtering on keys that are of some interest to me, and
sending the others to the regular ULineEdit processKeyEvent.

My new object correctly receives key signals, but fails to propagate the
"message" to its ancestor. I tried to add a "ULineEdit::processKeyEvent(e)"
in my code in order to propagate the key event, but it fails do anything
useful : content of the ULineEdit isn't updated properly. I'm quite a bit
puzzled on this matter, so perhaps one of you guys can give me some hints o=
n
how I can achieve such a thing as "handling some specific keys". I'm not
sure this was the right approach, and I'm completely open to brand new
solutions if they provide results.

Thanks in advance !

--
{ drozofil -- www.lwo-lab.net }

Re: [UFO-devel] Re: modal filedialog - waiting for a decision

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

Am Mittwoch, 12. April 2006 11:09 schrieb Thomas Franken:
> Hi,
> thank you for your answer. Together with the command
> rootpane->setModalWidget(..) your solution works fine.

If your frame is already visible, you have to call that, too.
Probably this should be done automatically ...

> But I think, as long as the application  is single threaded the program
> flow cannot be hold on.
> So I will look for another solution.

OTOH, you can run the event dispatching and repainting in every other method 
and return from that method as soon as your desired event was captured.
I think this is the Java way (at least in 1.2).


> If everything works I will send a message. So if you are interested, it
> could be integrated into the library.

Thanks.

Regards,
Johannes

[UFO-devel] Re: modal filedialog - waiting for a decision

[Thomas F. <tom...@gm...>]

Hi,
thank you for your answer. Together with the command 
rootpane->setModalWidget(..) your solution works fine.
But I think, as long as the application  is single threaded the program 
flow cannot be hold on.
So I will look for another solution.
If everything works I will send a message. So if you are interested, it 
could be integrated into the library.

Regards,
Tommy

>Am Dienstag, 11. April 2006 13:56 schrieb Johannes Schmidt:
>  
>
>>Hi Tommy,
>>
>>Am Dienstag, 11. April 2006 13:17 schrieb Thomas Franken:
>>    
>>
>>>I created a filedialog based on the ufo lib, - works fine.
>>>The user can select a file and confirm his selection by clicking a
>>>button. But - is there a way to hold on the programm flow, until a
>>>decision of an userinteraction is done?
>>>Some kind of redirection of the callback routines or something... i have
>>>no idea.
>>>      
>>>
>>There might be some issues with that, but you could try setting the frame
>>state, i.e.:
>>UInternalFrame * iframe = ...;
>>iframe->setFrameState(iframe->getFrameState() | FrameModal);
>>    
>>
>[...]
>
>Is this file dialog open source?
>Perhaps we could integrate it in libUFO ...
>
>
>Regards,
>Johannes
>  
>

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

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

Am Dienstag, 11. April 2006 16:50 schrieb Andreas Beckermann:
[...]
> > > Okok, so back to the start. The error is not here, but there definitely
> > > is one, as you can see if you draw a (not filled) rect in a
> > > paintWidget() method with vertices (0,0), (0,h-1), (w-1,h-1), (w-1, 0).
> > > Not all lines are shown.
> >
> > Hmm, I cannot reproduce that (using Linux/XOrg, Nvidia and software
> > driver, resp. Windows).
>
> Modified test/base.cpp attached.
> The problem does NOT appear
> a) with current anonymous CVS (as it hasn't catched the latest (r1.20)
> patch to ugl_graphics.cpp yet
> b) when glOrtho() is patched as described

Your test application uses custom GL code.
You really should set up your own projection matrix when using that.
The current ugl_graphics code adds 0.375f to coordinates according to OpenGL 
red book Appendix H.

It works like a charme when using the graphics object.

> The test application simply draws a frame inside (!) the widget:
> 0 <= x <= getWidth() - 1
> and
> 0 <= y <= getHeight() - 1
>
> I think we agree that all these coordinates lie inside the widget and thus
> should be visible when painting, right?
> If so, then you should see a red rectangle on the screen, i.e. 4 lines.
>
> > I have some minimal test cases at home (I'll send it to you at weekend).
> > Perhaps you can try them and check whether you still get the same errors.
> >
> > Btw, which graphics card and driver do you use? ATI, fglrx?
>
> NVidia proprietary drivers, but I heavily doubt that this makes any
> difference.

Hah, believe me, this does really matter!

> > Perhaps there is some issue with that ...
> >
> > > -> this can be easily traced back to the clipping rect.
> >
> > [...]
> >
> > > glOrtho() docs say it takes left, right, bottom, top parameters.
> > > However you give it left, right+1, bottom+1, top, as contextBounds.w is
> > > already outside of the context bounds.
> > > So the correct fix should be to replace the above call to
> > >         ugl_driver->glOrtho(
> > >                 0,
> > >                 contextBounds.w - 1,
> > >                 contextBounds.h - 1,
> > >                 0,
> > >                 -100,
> > >                 100
> > >         );
> > >
> > > Ok, so hopefully I am not already too tired this time :-)
> >
> > This sounds very reasonable, too.
> >
> > On the other side, every 2D setup I have seen so far uses this approach
> > with 0, 0 and width, height (well, they could be wrong, too).
>
> Every? Examples?

Just a few:

OpenGL FAQ on opengl.org:
 gluOrtho2D (0, windowWidth, 0, windowHeight);

OpenGL red book Appendix H
gluOrtho2D(0, width, 0, height);

NeHe lesson #17:
 glOrtho(0.0f,width,height,0.0f,-1.0f,1.0f);

NeHe lesson #21:
 glOrtho(0.0f,width,height,0.0f,-1.0f,1.0f);
 
Apple's BoingX:
 glOrtho(0,[self bounds].size.width,0,[self bounds].size.height, 0.0f, 
2000.0);
 
Apple's CGImage Loader:
 gluOrtho2D(0.0f, size.width, 0.0, size.height);
 
Apple's GLChildWindowDemo:
 glOrtho(0,bounds.size.width,0,bounds.size.height,-1,1);
 
Apple's Stencil Shadows:
 gluOrtho2D(0.0f, size.width, size.height, 0.0f);
 

> > And I have seen that the width should be right - left which leads to:
>
> Where have you seen that?

Can't remember where it was used in this case, but this is also the usual 
definition when using the RECT structure on windows.
Just search MSDN.

> It would be _possible_ to use such a definition, but very unlikely. This
> could mean two things only:
> a) width := (number of pixels in between right and left) - 1
> -> this is imho a very unusual definition. In particular that means that if
> right==left (i.e. exactly one pixel), then width==0, which is pretty
> inintuitive.
> --> I am pretty sure OpenGL doesn't use that. If it does, your glViewport()
> call before the glOrtho() call is broken :-)
> b) right := leftmost pixel to the right of the rect that is _not_ visible.
> -> again, possible, but unintuitive definition. In particular this means
> that right is completely different to left, as left is clearly defined as
> the first pixel that is _inside_ the rect.

Remember: We talk about a projection matrix.
OpenGL doesn't know what pixels are in this state of processing vertex data.
Left, right, etc. define clipping planes.


Regards,
Johannes

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

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

On Tuesday 11 April 2006 14:21, Johannes Schmidt wrote:
> Hi Andreas,

Hi

> Am Freitag, 31. März 2006 03:44 schrieb Andreas Beckermann:
> [...]
>
> > Okok, so back to the start. The error is not here, but there definitely
> > is one, as you can see if you draw a (not filled) rect in a paintWidget()
> > method with vertices (0,0), (0,h-1), (w-1,h-1), (w-1, 0). Not all lines
> > are shown.
>
> Hmm, I cannot reproduce that (using Linux/XOrg, Nvidia and software driver,
> resp. Windows).

Modified test/base.cpp attached.
The problem does NOT appear
a) with current anonymous CVS (as it hasn't catched the latest (r1.20) patch 
to ugl_graphics.cpp yet
b) when glOrtho() is patched as described

The test application simply draws a frame inside (!) the widget:
0 <= x <= getWidth() - 1
and
0 <= y <= getHeight() - 1

I think we agree that all these coordinates lie inside the widget and thus 
should be visible when painting, right?
If so, then you should see a red rectangle on the screen, i.e. 4 lines.

> I have some minimal test cases at home (I'll send it to you at weekend).
> Perhaps you can try them and check whether you still get the same errors.
>
> Btw, which graphics card and driver do you use? ATI, fglrx?

NVidia proprietary drivers, but I heavily doubt that this makes any 
difference.

> Perhaps there is some issue with that ...
>
> > -> this can be easily traced back to the clipping rect.
>
> [...]
>
> > glOrtho() docs say it takes left, right, bottom, top parameters. However
> > you give it left, right+1, bottom+1, top, as contextBounds.w is already
> > outside of the context bounds.
> > So the correct fix should be to replace the above call to
> >         ugl_driver->glOrtho(
> >                 0,
> >                 contextBounds.w - 1,
> >                 contextBounds.h - 1,
> >                 0,
> >                 -100,
> >                 100
> >         );
> >
> > Ok, so hopefully I am not already too tired this time :-)
>
> This sounds very reasonable, too.
>
> On the other side, every 2D setup I have seen so far uses this approach
> with 0, 0 and width, height (well, they could be wrong, too).

Every? Examples?

> And I have seen that the width should be right - left which leads to:

Where have you seen that?
It would be _possible_ to use such a definition, but very unlikely. This could 
mean two things only:
a) width := (number of pixels in between right and left) - 1
-> this is imho a very unusual definition. In particular that means that if 
right==left (i.e. exactly one pixel), then width==0, which is pretty 
inintuitive.
--> I am pretty sure OpenGL doesn't use that. If it does, your glViewport() 
call before the glOrtho() call is broken :-)
b) right := leftmost pixel to the right of the rect that is _not_ visible.
-> again, possible, but unintuitive definition. In particular this means that 
right is completely different to left, as left is clearly defined as the 
first pixel that is _inside_ the rect.

I don't see any other way, how you could define width as right-left.

(btw: whenever I talked about the position of a pixel in the above, I of 
course meant the x coordinate of the pixel - I assume the y coordinate is 
fixed in the above)

> I hope I can get more insight in projection mathematics on weekend,
> but others on this list might enlighten me, too :)
>
> As long as there is no exact answer to this problem,
> I'll revert CVS to the old solution.
>
>
> Regards,
> Johannes

CU
Andi

Re: [UFO-devel] modal filedialog - waiting for a decision

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

Am Dienstag, 11. April 2006 13:56 schrieb Johannes Schmidt:
> Hi Tommy,
>
> Am Dienstag, 11. April 2006 13:17 schrieb Thomas Franken:
> > I created a filedialog based on the ufo lib, - works fine.
> > The user can select a file and confirm his selection by clicking a
> > button. But - is there a way to hold on the programm flow, until a
> > decision of an userinteraction is done?
> > Some kind of redirection of the callback routines or something... i have
> > no idea.
>
> There might be some issues with that, but you could try setting the frame
> state, i.e.:
> UInternalFrame * iframe = ...;
> iframe->setFrameState(iframe->getFrameState() | FrameModal);
[...]

Is this file dialog open source?
Perhaps we could integrate it in libUFO ...


Regards,
Johannes

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

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

Hi Andreas,

Am Freitag, 31. M=C3=A4rz 2006 03:44 schrieb Andreas Beckermann:
[...]
> Okok, so back to the start. The error is not here, but there definitely is
> one, as you can see if you draw a (not filled) rect in a paintWidget()
> method with vertices (0,0), (0,h-1), (w-1,h-1), (w-1, 0). Not all lines a=
re
> shown.=20

Hmm, I cannot reproduce that (using Linux/XOrg, Nvidia and software driver,=
=20
resp. Windows).
I have some minimal test cases at home (I'll send it to you at weekend).=20
Perhaps you can try them and check whether you still get the same errors.

Btw, which graphics card and driver do you use? ATI, fglrx?
Perhaps there is some issue with that ...

> -> this can be easily traced back to the clipping rect.=20
[...]
> glOrtho() docs say it takes left, right, bottom, top parameters. However
> you give it left, right+1, bottom+1, top, as contextBounds.w is already
> outside of the context bounds.
> So the correct fix should be to replace the above call to
>         ugl_driver->glOrtho(
>                 0,
>                 contextBounds.w - 1,
>                 contextBounds.h - 1,
>                 0,
>                 -100,
>                 100
>         );
>
> Ok, so hopefully I am not already too tired this time :-)

This sounds very reasonable, too.

On the other side, every 2D setup I have seen so far uses this approach wit=
h=20
0, 0 and width, height (well, they could be wrong, too).
And I have seen that the width should be right - left which leads to:
right =3D width + left

I hope I can get more insight in projection mathematics on weekend,
but others on this list might enlighten me, too :)

As long as there is no exact answer to this problem,
I'll revert CVS to the old solution.


Regards,
Johannes

Re: [UFO-devel] modal filedialog - waiting for a decision

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

Hi Tommy,

Am Dienstag, 11. April 2006 13:17 schrieb Thomas Franken:
> I created a filedialog based on the ufo lib, - works fine.
> The user can select a file and confirm his selection by clicking a button.
> But - is there a way to hold on the programm flow, until a decision of
> an userinteraction is done?
> Some kind of redirection of the callback routines or something... i have
> no idea.

There might be some issues with that, but you could try setting the frame 
state, i.e.:
UInternalFrame * iframe = ...;
iframe->setFrameState(iframe->getFrameState() | FrameModal);

This is an untested feature, but it should theoretically work.


Regards,
Johannes

[UFO-devel] modal filedialog - waiting for a decision

[Thomas F. <tom...@gm...>]

Hi

I created a filedialog based on the ufo lib, - works fine.
The user can select a file and confirm his selection by clicking a button.
But - is there a way to hold on the programm flow, until a decision of 
an userinteraction is done?
Some kind of redirection of the callback routines or something... i have 
no idea.

thanks in advance
Tommy

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

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

On Thursday 30 March 2006 23:04, Johannes Schmidt wrote:
> On Saturday 25 March 2006 16:53, Johannes Schmidt wrote:
> > On Friday 10 March 2006 21:44, Andreas Beckermann wrote:
> > > 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).
> >
> > Thanks, applied to CVS.
>
> Err, the statement above is right, but in that case it is reverted, e.g. in
> mapToDevice:

Indeed. I guess I have worked a little too much with the code and got confused 
by my own equations in the end :-(

Okok, so back to the start. The error is not here, but there definitely is 
one, as you can see if you draw a (not filled) rect in a paintWidget() method 
with vertices (0,0), (0,h-1), (w-1,h-1), (w-1, 0). Not all lines are shown.
-> this can be easily traced back to the clipping rect.

Well, it took me quite some time to find another possible error source for 
this problem (in fact it already took quite some time to find why the patch 
was necessary for me..), but I think I found it:
in resetDeviceViewMatrix():
        ugl_driver->glOrtho(
                0,
                contextBounds.w,
                contextBounds.h,
                0,
                -100,
                100
        );
glOrtho() docs say it takes left, right, bottom, top parameters. However you 
give it left, right+1, bottom+1, top, as contextBounds.w is already outside 
of the context bounds.
So the correct fix should be to replace the above call to
        ugl_driver->glOrtho(
                0,
                contextBounds.w - 1,
                contextBounds.h - 1,
                0,
                -100,
                100
        );

Ok, so hopefully I am not already too tired this time :-)

CU
Andi

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

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

On Saturday 25 March 2006 16:53, Johannes Schmidt wrote:
> On Friday 10 March 2006 21:44, Andreas Beckermann wrote:
> > 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).
>
> Thanks, applied to CVS.

Err, the statement above is right, but in that case it is reverted, e.g. in 
mapToDevice:
URectangle(vport[0] + rect.x, vport[1] + vport[3] - rect.y - rect.h, rect.w, 
rect.h);

vport[3] is the height.

The correct y value would be
vport[1] + vport[3] - 1 - (rect.y + rect.h - 1)
which equals the former solution.


Regards,
Johannes

Re: [UFO-devel] Fullsize textedit

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

Hi,

On Monday 27 March 2006 20:12, Elie `woe` BLETON wrote:
> I'm currently in the process of adding some kind of editor into my
> application. For this purpose, I thought I could make some use of the
> UTextEdit control (and possibly inherit from it in order to add some
> syntax highlighting of some kind), but I'm currently unable to resize
> the control properly. I noticed the .Rows and .Cols (or was it
> .Columns ?), and I tried to compute the adequate size from the font
> size, since this was more or less illustrated in the sourcecode.
> Unfortunately, I didn't manage to get it right, and the result is
> pretty random currently.
>
> So I'm looking for a way to have a UTextEdit to cover a whole region,
> one of those that are provided by UBorderLayout, if that's possible.

I'm not sure if I got it right, but if you just want to set the size of the 
text edit in a given layout, you can use:
UWidget::setPreferredSize(UDimension)
and the widget will get that size in the layout.


Regards,
Johannes

[UFO-devel] Fullsize textedit

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

Hello there,
I'm currently in the process of adding some kind of editor into my
application. For this purpose, I thought I could make some use of the
UTextEdit control (and possibly inherit from it in order to add some
syntax highlighting of some kind), but I'm currently unable to resize
the control properly. I noticed the .Rows and .Cols (or was it
.Columns ?), and I tried to compute the adequate size from the font
size, since this was more or less illustrated in the sourcecode.
Unfortunately, I didn't manage to get it right, and the result is
pretty random currently.

So I'm looking for a way to have a UTextEdit to cover a whole region,
one of those that are provided by UBorderLayout, if that's possible.

Thanks in advance for your help,

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

Re: [UFO-devel] Popup Menus

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

Hi Casper,

sorry, I'm still busy with exams.

On Friday 17 March 2006 19:28, Casper Beyer wrote:
> 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?

Well, theoretically it should work.
Unfortunately the whole popup handling is a bit messy.
It is tested to work with popup menus from menu bars.
I haven't tested it yet with context menus, so it is surely a bug.

> 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.

Definitely.

> 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?

It's a bug. The whole logic is in umenumanager.cpp
I'll take a look as soon as I have the time (hopefully next week).

> 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! :)

Sorry, but it works for me [TM] in menu bar cases :)
Thanks for the detailed bug description.
I fear that I have to rewrite the whole selection code.

Regards,
Johannes

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

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

On Friday 10 March 2006 21:44, Andreas Beckermann wrote:
> 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).

Thanks, applied to CVS.

Regards,
Johannes