[GEM-dev] Re: multiple_window: the questions begin!

[B. Bogart]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

I have two questions and one suggestion:

Q1: How far along are things for multiple windows? (time-wise)
Q2: Will multiple windows open the door to render to a texture as if it was just
another window? (I can think of many uses for this in relation to pixelTANGO)

Suggestion:

What if there is a gemwin outlet that deals with all input events, keyboard,
mouse etc.. The format could follow the HID format, which would mean that
abstractions made to work with HID would be fully compatible with Gem window
events... I think this would be very nice to share the same format to get the
data. I'm sure there are some ugly implications of saying this but I think it
would be nice to be able to use the same abstractions to parse/smooth and
genrally work with input data (tablet, mouse, keyboard etc..)

B.



IOhannes m zmoelnig wrote:
| james tittle wrote:
|
|> On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote:
|
|
|> ...also, as it is, the mouse coords are already converted to the
|> "local" coords of the window, but they don't have to be...
|
|
| so "local" means that 0/0 is in some (probably the upper/left) corner (?)
|
|> ...ok, an outlet would be sensible:  maybe we should output window
|> relative AND global coords?
|
|
| well, i am not sure whether global coordinates are really that
| important, it would be more important to get the window-position (aka
| "offset") when the window is moved.
|
| as for now, all implementations of [gemmouse] (or rather, the underlying
| callback-code) output the local coordinates.
|
|>
|>> as for outlets:
|>> personally i think by now(;-)) that it might be best to have just one
|>> outlet and prefix the outgoing messages, like
|>> [mouse <x> <y> <bt1> <bt2> <bt3>(
|>
|>
|>
|> ...so this is a message that is output by the window?
|
|
| yes, that's what i meant.
|
|>
|>> anyhow, we need several messages to query things like the dimension
|>> of the window (or whatever): [dimen <x> <y>(
|>
|>
|> ...again, should this be output by the window, or is it just received?
|
|
| both.
| here i was referring to the output of the window, but of course we
| setting the window-size with "dimen x y" should still be possible.
|
| i just took the same name because it was the first that came to my mind.
| i guess "dimen" (as output) is the choice to stay somewhat consistent
| ("size" never really made it for whatever reasons), but i see that it is
| somewhat confusing when talking about ideas.
|
|>
|> ...I thought we could already normalize with gemmouse?  It can take a
|> scale value for x & y, at
|
|
| yes, that is what i was talking about.
| and i think that that is the reason why there are those additional
| arguments. not sure without looking at the code; but i guess until now
| the window-dimension (needed for normalization) was just read from the
| GemMan variables. this will of course not work any more, if we have
| multiple windows with different sizes which would be stored as
| class-members within the GemWindow.
|
|
|> least...and there is already mousewheel support:  in the case of OSX,
|> it's just another event message that is installed at window creation...
|
|
| yes i know.
| but how is it handled, is there a 6th outlet to [gemmouse] ? or is it
| packed into the 4th outlet (middle button) somehow ?
|
| the question is how to do data-retrieval (big words) in a way that is
| easy to extend for future use.
| [gemmouse] was just an example, because you ran into some problems when
| you wanted to add the scroll-wheel without breaking things.
| messages are probably simpler to extend than object-APIs.
| and just to think about [gemtablet] (which i have never used because of
| lack of tablets) which has about 10 outlets and what happens if your
| brandnew tablets has 5 additional buttons ? add 5 other outlets ?
|
|
|> ...so maybe we need to look at the specifics on individual platforms?
|
|
| again i was not talking about the implementations but rather how to get
| it right before too much work is done (avoiding frustration)
|
|
| mfg.a.sdr
| IOhannes
|
| _______________________________________________
| GEM-dev mailing list
| GEM-dev at iem.at
| http://iem.at/cgi-bin/mailman/listinfo/gem-dev
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBrgrejbOsMZSA25cRAtChAJwJeJxEedCs95jKOIjZJgbagBJwuQCaAr8I
ojHeJazyDzDhlKczOnR20QI=
=bccA
-----END PGP SIGNATURE-----