nanogui: Thread: mouse acceleration, and portrait mode

- is there a public api for controlling mouse acceleration?  i didn't
    find one in my ramblings.

- i did find the control for portrait mode (GrSetPortrait()), but it
    needs to be added to the function reference on the web.  is gary james
    still maintaining that?

    regarding "down" mode.  it seems to be a literal upside-down
    mode, rather than a 180 degree rotation.  is this intended?

    regarding "left" and "right" modes, they only seems to
    correctly modify the original x direction, but leaves the
    original y (now x) unchanged.

    looking at fbportrait_left/right/down.c, all three of these
    problems seem fairly obvious, making me think that there's
    either a problem if you do it right, or else portrait mode isn't
    intended for what i think it is...


paul
=---------------------
 paul fox, ####@####.#### (arlington, ma, where it's 60.4 degrees)

Paul Fox wrote:
> - is there a public api for controlling mouse acceleration?  i didn't
>     find one in my ramblings.

There's a GdSetAccelMouse() function but as far as a I can see nothing 
calls it from anywhere, and hence there's no way to get to it from the 
user level API. It would probably be best to enhance GrCalibrateMouse() 
to support setting the acceleration as well, and make it a configurable 
parameter in launcher.cnf or something.

> - i did find the control for portrait mode (GrSetPortrait()),

Changing the portrait mode whilst the server is running doesn't seem to 
work very well. In particular if there are any pixmaps at all the server 
will crash because it can't cope with rotating them (I discovered this 
after I wrote a little command line program to change it).

>     needs to be added to the function reference on the web.  is gary james
>     still maintaining that?

If you mean the gtkdoc generated stuff, I wrote almost all of that. 
microwin-aph definitely has documentation for all of the API functions.

>     regarding "down" mode.  it seems to be a literal upside-down
>     mode, rather than a 180 degree rotation.  is this intended?

Down mode definitely seems to be totally broken to me too. There are 
some more minor problems with Left and Right, such as the launcher panel 
getting put in the wrong place.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

: Changing the portrait mode whilst the server is running doesn't seem to 
: work very well. 

I've only know of one known problem here, the server won't
rotate pixmaps, since currently they're stored in hw framebuffer 
format only. (this will be fixed in the future, when I add the rotation
and conversion blits).  Are there any more known issues with
portrait mode changes while running?

: In particular if there are any pixmaps at all the server 
: will crash because it can't cope with rotating them (I discovered this 
: after I wrote a little command line program to change it).

Yep


: 
: >     needs to be added to the function reference on the web.  is gary james
: >     still maintaining that?
: 
: If you mean the gtkdoc generated stuff, I wrote almost all of that. 
: microwin-aph definitely has documentation for all of the API functions.

Gary wrote his own, I think.  Alex - what would it take for me
to get setup using the gtkdoc stuff, so I can keep the docs updated
automatically?


: 
: >     regarding "down" mode.  it seems to be a literal upside-down
: >     mode, rather than a 180 degree rotation.  is this intended?
: 
: Down mode definitely seems to be totally broken to me too. There are 
: some more minor problems with Left and Right, such as the launcher panel 
: getting put in the wrong place.

I'm not aware of any problems in left or right mode.  This has been
in use for the iPAQ port for some time.  What's the problem
with the launcher panel?  The left/right modes scale the x and y axes
properly.

WRT down mode, yes, it's broken, as it needs to flip the X axis, and
doesn't.  I tried figuring it out once, but got completely confused when
trying to swap the portrait_blit parameters...  Anybody willing to
take a hack at this?  (may require rotation blit)

Regards,

Greg

Greg Haerr wrote:
> Gary wrote his own, I think.  Alex - what would it take for me
> to get setup using the gtkdoc stuff, so I can keep the docs updated
> automatically?

You need to install gtk-doc and whatever it depends on, as well as 
either docbook2pdf, ps2pdf, or pdftex (each has its own problems), then 
debug it all until it works. Each time I've done it I've spent anywhere 
between 2 days and 2 hours persuading it all to work (different reasons 
each time, but Jade seems to cause the most problems). Since I recently 
reinstalled my system I haven't got around to getting it working again 
yet. To be honest I'd like to move to another automatic documentation 
system that has similar capabilities but without all the hassle (I'd 
want to be able to convert the existing function descriptions to the new 
format rather than rewrite them of course). A nice bonus would be if the 
same system provided an easy way to document data structures (in 
particular the event structures) as well as the API functions.

Anyone have any suggestions as to a better system?

> I'm not aware of any problems in left or right mode.  This has been
> in use for the iPAQ port for some time.  What's the problem
> with the launcher panel?  The left/right modes scale the x and y axes
> properly.

Oops, you're right. I was mis-remembering the fact that I don't like the 
way launcher handles portrait format screens as a Nano-X bug. That 
reminds me though, attached is a patch which fixes an out-by-one-pixel 
bug in the portrait mode of the launcher. The panel part of the launcher 
wants rewriting at some point anyway to use drawers or something so it 
doesn't take up so much space.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

diff -u -r1.9 launcher.c
--- launcher.c	2002/04/07 08:53:00	1.9
+++ launcher.c	2002/07/26 17:11:29
@@ -578,7 +578,7 @@
 	GR_SCREEN_INFO si;
 	GR_IMAGE_ID back_image;
 	GR_IMAGE_INFO imageinfo;
-	int rows = 1, columns = 1, width, height, x = 0, y = 1;
+	int rows = 1, columns = 1, width, height, x = 0, y = 0;
 	GR_WM_PROPERTIES props;
 	litem *i;
 

 > .... That 
 > reminds me though, attached is a patch which fixes an out-by-one-pixel 
 > bug in the portrait mode of the launcher. The panel part of the launcher 

oh -- and that reminds _me_ that i'm seeing an off-by-one in
portrait mode of rectangular block moves (i'm guessing) when vnc
wants to scroll an xterm, for instance.  the bottom border of the
xterm gets included in the data that gets "scrolled up", so you
end up with multiple thin bars across the xterm pane as you
successively hit <CR>.  this doesn't happen in normal landscape
mode -- and since none of the vnc code knows anything about portait
mode, i have to assume the problem is in the fb code somewhere.  i'm
using the vgaplan4 sub-driver -- i'd imagine it doesn't get much
exercise, so it may well be in there.

i'll take a look for it, but thought i'd mention it.

paul
=---------------------
 paul fox, ####@####.#### (arlington, ma, where it's 68.5 degrees)

Hi,

(My earlier message bounced - resending)

Alex Holden wrote:
> Greg Haerr wrote:
> > Gary wrote his own, I think.  Alex - what would it take for me
> > to get setup using the gtkdoc stuff, so I can keep the docs updated
> > automatically?
>
> You need to install gtk-doc and whatever it depends on, as well as
> either docbook2pdf, ps2pdf, or pdftex (each has its own problems), then
> debug it all until it works. Each time I've done it I've spent anywhere
> between 2 days and 2 hours persuading it all to work (different reasons
> each time, but Jade seems to cause the most problems). Since I recently
> reinstalled my system I haven't got around to getting it working again
> yet. To be honest I'd like to move to another automatic documentation
> system that has similar capabilities but without all the hassle (I'd
> want to be able to convert the existing function descriptions to the new
> format rather than rewrite them of course). A nice bonus would be if the
> same system provided an easy way to document data structures (in
> particular the event structures) as well as the API functions.
>
> Anyone have any suggestions as to a better system?

I use Doxygen (www.doxygen.org).

The main reason I like Doxygen is that it just works - it produces HTML
natively, no need to mess around with XML or TeX.  Of course, it can
output to LaTeX if you want PostScript or PDF output, for printing.  It's
GPL'd, and binaries are available for Linux, Windows, and many other
platforms.

Doxygen also lets you document structs and variables.  e.g.:


/**
 * @file This file contains some Doxygen examples.
 */

/**
 * Holds the co-ordinates of a point, and a color.
 */
struct point_t {
   int x; /**< X co-ordinate on screen. */
   int y; /**< Y co-ordinate on screen. */

   /**
    * Color to draw.  This comment style is better for
    * longer descriptions.
    *
    * -1 for default color.
    */
   color_t color;
};

/**
 * Default color.
 */
extern color_t  default_color;

/**
 * Draws a point.  Paramaters are specified as a point_t.
 * (point_t will automatically become a hyperlink in the
 * HTML documentation.)
 *
 * @param myPoint The point to draw.
 * @return nonzero on success, zero on error.
 */
extern int drawPoint(point_t *myPoint);


I prefer the JavaDoc style of formatting, which is consistent with
Java.  Doxygen also supports a LaTeX style of formatting using
\command rather than @command.

Kind regards,

Jon Foster

####@####.#### wrote:

>I use Doxygen (www.doxygen.org).
>  
>
Thanks, I'll take a look at it.

> * Draws a point.  Paramaters are specified as a point_t.
>
"Parameters" ;)

>I prefer the JavaDoc style of formatting, which is consistent with
>Java.  Doxygen also supports a LaTeX style of formatting using
>\command rather than @command.
>  
>
It looks pretty similar to gtkdoc, I suppose perhaps they're both 
inspired by the javadoc format.

On Wed, 2002-07-31 at 17:15, Alex Holden wrote:
> >I prefer the JavaDoc style of formatting, which is consistent with
> >Java.  Doxygen also supports a LaTeX style of formatting using
> >\command rather than @command.
> >  
> >
> It looks pretty similar to gtkdoc, I suppose perhaps they're both 
> inspired by the javadoc format.

Most of them seem to have come from the same kind of root. kernel-doc is
based on gnome-doc which is a relative of gtk-doc without all the class
heirarchy magic, and with a convenient way to drop clear readable
paragraphs. 

Alan