#jogamp @ irc.freenode.net - 20130502 05:06:37 (UTC)
20130502 05:06:37 -CatOut- Previous @ http://jogamp.org/log/irc/jogamp_20130501050623.html
20130502 05:06:37 -CatOut- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130502050637.html
20130502 05:49:10 <sgothel> Good morning:
20130502 05:49:52 <sgothel> Discussion: Fullscreen in an multi monitor environment .. what do you expect ? Spanning all monitors ? Or just the monitor where the window position falls into (viewport) ?
20130502 05:50:02 <sgothel> maybe we need a flag for this ?
20130502 06:07:48 * [Mike] (~Mike]@anon) Quit ()
20130502 07:03:14 * hharrison (~chatzilla@anon) has joined #jogamp
20130502 07:03:57 <hharrison> sgothel: personally I prefer when things go fullscreen on just the monitor the window was in
20130502 07:07:36 <hharrison> And if you want to go multi-monitor, you usually are writing code in your application to treat that specially
20130502 07:08:33 <hharrison> Give people an API they can control which monitor they go fullscreen on and let them do what they want
20130502 07:08:38 <hharrison> IMHO
20130502 07:22:37 <sgothel> yup .. my opinion as well, will try to keep it that way
20130502 07:39:31 * hharrison (~chatzilla@anon) Quit (Remote host closed the connection)
20130502 08:19:05 * masterzen (~masterzen@anon) Quit (Ping timeout: 252 seconds)
20130502 08:21:39 * masterzen (~masterzen@anon) has joined #jogamp
20130502 09:17:38 <xranby> (07:51:06) sgothel: Discussion: Fullscreen in an multi monitor environment .. what do you expect ? Spanning all monitors ? Or just the monitor where the window position falls into (viewport) ? <--- i expect the screen to go fullscreen on the monitor the window overlaps the most
20130502 09:18:40 <xranby> of course it would be cool to have optional fullscreen on a specific monitor or covering the virtual screen if explicitly requested
20130502 09:18:42 <sgothel> right now we identify the monitor by the windows origin, i.e. w/o weight .. hmm :)
20130502 09:18:57 <sgothel> yup - may add this as well, since it also seems useful
20130502 09:19:28 <sgothel> linux / windows are currently testing in vbox .. hmm, osx .. nada
20130502 09:22:14 <xranby> sgothel: noticed that you have added some improvements to gluegen related to nio buffer handling, my initial thought was this looks usefull for mediaframe processing
20130502 09:22:57 <xranby> especially in situations where the audio sink consumes smaller or larger frames compared to the produced decoded frames
20130502 09:23:02 <sgothel> all those loose ends of tasks in my brain somehow materialize somewhere :)
20130502 09:23:25 <sgothel> (yes .. generalizing .. sure)
20130502 10:34:04 * gouessej (546051e4@anon) has joined #jogamp
20130502 10:34:29 <gouessej> hi
20130502 10:35:11 <xranby> gouessej: hi
20130502 10:40:01 <gouessej> In some cases, there is no way to make a distinction between a key of the numerical pad and a similar key not on the numpad
20130502 10:40:06 <gouessej> :(
20130502 10:42:03 <xranby> dont the modifiers differ?
20130502 10:42:18 <xranby> for example if numlock is on or not
20130502 10:43:33 <gouessej> I haven't tried to use the modofier
20130502 10:43:36 <gouessej> modifier
20130502 10:44:01 <xranby> the key code should stay the same for each button reguardless of the used modifier
20130502 10:44:26 <gouessej> some VK constants are declared for LEFT, RIGHT, UP and DOWN and some separated constants are declared for numpad keys
20130502 10:44:31 <gouessej> but they are not used :s
20130502 10:44:52 <gouessej> VK_LEFT is returned whatever the location
20130502 10:45:07 <xranby> gouessej: i thought your patch adressed this
20130502 10:45:15 <gouessej> In AWT, there is a separate field to indicate the location but not in NEWT
20130502 10:45:30 <xranby> https://github.com/sgothel/jogl/pull/64
20130502 10:45:31 <gouessej> yes but it doesn't address the whole problem
20130502 10:45:39 <gouessej> look at my comments
20130502 10:46:07 <gouessej> we can't add some VK constants any more
20130502 10:47:06 <xranby> we may add VK constants inside the UTF-16 ranges that do not define printable characters
20130502 10:47:27 <gouessej> ok
20130502 10:47:46 <xranby> let me look up the ranges, we discussed it on IRC some days ago
20130502 10:47:46 <gouessej> I have suggested several solutions here: https://jogamp.org/bugzilla/show_bug.cgi?id=723
20130502 10:48:11 <gouessej> I would like us to agree with a solution
20130502 10:48:25 <gouessej> something coherent
20130502 10:49:29 <gouessej> For example, should we use the VK_NUMPAD* constants and set the modifier when the num lock is on/off or should we use separate VK_KP* constants?
20130502 10:50:48 <xranby> gouessej: keyChar shoudl change according to used keymap and modifiers
20130502 10:50:52 <gouessej> AWT is not consistent
20130502 10:51:24 <gouessej> the key char is already correct now
20130502 10:52:02 <xranby> keyCode should be tied to the physical key to be the same across all platforms
20130502 10:52:59 <gouessej> ok but we have 2 keyCodes per keys for 4 numpad keys :s
20130502 10:54:13 <xranby> my thinking is that keyChar should send the for example VK_HOME if numlock is on while keyCode should send VK_NUMPAD_7
20130502 10:55:08 <xranby> isPrintable should return falso of course when sending VK_HOME for keyChar
20130502 10:56:05 <gouessej> On AZERTY keyboards, we usually expect to get the number as keychar only when the num lock is on
20130502 10:57:43 <xranby> right, fault in my thinking here, numlock on sends number VK for all keyChar while numlock off sends home ppgup end etc for keyChar
20130502 10:58:11 <xranby> keyCode should be the same reguardless of modifiers
20130502 10:58:19 <gouessej> ok but it already works very well now (the key code)
20130502 10:58:34 <gouessej> oups
20130502 10:58:42 <gouessej> I meant the key char is already correct
20130502 10:59:07 <gouessej> ok then we should use only VK_NUMPAD constants
20130502 11:00:32 <gouessej> how should we treat other keys in the numerical pad? + - * /
20130502 11:00:45 <xranby> keyCode should use constants acording to a US keymap, this allows the physical keys keyCode to stay put reguardless of keymap
20130502 11:01:08 <xranby> i think there is VK numbers for those as well
20130502 11:02:58 <xranby> https://jogamp.org/bugzilla/show_bug.cgi?id=641
20130502 11:02:59 <gouessej> ok but how can I make the distinction between KP + and +?
20130502 11:03:26 <xranby> Bug 641 - NEWT: Distinguish keyCode (kbd layout independent) and keySym (kbd layout dependent) (was: Invalid keyCodes returned with com.jogamp.newt.event.KeyEvent)
20130502 11:03:43 <xranby> this is the master bug dealing with this issue
20130502 11:04:18 <gouessej> ok
20130502 11:04:32 <xranby> if anything i said conflicts with this bug then this bug overrue what i said ;)
20130502 11:05:50 <gouessej> ok but I'm not sure this bug report covers the problem of numpad keys
20130502 11:06:29 <xranby> it should
20130502 11:07:01 <xranby> since each numpad key should be assigned a kbd layout independent VK
20130502 11:07:54 <xranby> thats the only way we can guarantee cross platform input interoerability
20130502 11:08:08 <gouessej> it isn't the case, both in AWT and NEWT
20130502 11:08:23 <xranby> AWT is a mess that we cant fix
20130502 11:08:46 <gouessej> then we should not use it as a source of inspiration
20130502 11:10:30 <xranby> we now excel AWT in NEWT by using a unified UTF-16 aligned VK numberspace
20130502 11:10:50 <xranby> this allows easy conversion from VK to printable character
20130502 11:11:23 <xranby> (its the same number)
20130502 11:12:46 <xranby> to my knowledge NEWT is the first input system to use this simplicity
20130502 11:14:19 <gouessej> Can we really reassign some unusued VK constants in the range of unprintable characters to VK_KP constants?
20130502 11:14:47 <gouessej> "unused" sorry
20130502 11:17:01 <xranby> let me look up the ranges, (i am now searchign the irc archive)
20130502 11:17:55 <xranby> http://jogamp.org/log/irc/jogamp_20130410050637.html
20130502 11:18:43 <xranby> http://www.utf8-chartable.de/ all <control> ranges are valid for use by sunch VK
20130502 11:22:38 <gouessej> ok
20130502 11:24:45 <gouessej> In this case, maybe you can speak about this problem to Sven so that we choose a solution. We seem to agree with removing 4 VK_KP constants (VK_KP_LEFT, ...) and creating 6 VK_KP constants (VK_KP_PLUS, VK_KP_MINUS, ...).
20130502 11:25:09 <gouessej> so that one numpapd key = one VK_KP constant
20130502 11:25:17 <gouessej> "numpad"
20130502 11:26:23 <xranby> there exist two large upper address ranges that we also may use if we run out of <control> http://en.wikipedia.org/wiki/Private_Use_%28Unicode%29
20130502 11:26:38 <gouessej> ok
20130502 11:27:57 <gouessej> nice suggestion, it is less risky
20130502 11:29:09 <gouessej> xranby, when Sven and you have made a decision, can you update the bug report 723 so that I know what I have to do please?
20130502 11:34:24 <xranby> gouessej: ok
20130502 11:46:38 * gouessej (546051e4@anon) Quit (Quit: Page closed)
20130502 11:54:08 <sgothel> reading ..
20130502 11:54:46 <sgothel> "a key of the numerical pad and a similar key" .. oh well ..
20130502 11:56:28 <sgothel> lets discuss this issue later after my MonitorMode stuff .. :)
20130502 11:57:11 <sgothel> however, if anybody is reviewing it - AFAIK we distinguish keypad value (non numlock) .. ADD != PLUS .. or similar
20130502 11:57:33 <sgothel> .. and ASTERISK != MULTIPLY
20130502 11:58:17 <sgothel> in short: keypad keys shall be unique AFAIK ..
20130502 11:58:36 <sgothel> (numbers might be excluded .. have to check impl.)
20130502 11:58:46 <sgothel> (i.e. our UTF keyCodes)
20130502 12:00:06 <sgothel> upper address: pls read 'collision exception' in KeyEvent .. it's important that we try to stay low in the value range, allowing to track key states as required for some features (autorepeat) on some platforms ..
20130502 12:35:44 * xranby (~xranby@anon) Quit (Quit: Leaving.)
20130502 13:13:39 * xranby (~xranby@anon) has joined #jogamp
20130502 13:47:45 * xranby (~xranby@anon) Quit (Remote host closed the connection)
20130502 15:59:38 * [Mike] (~Mike]@anon) has joined #jogamp
20130502 21:02:53 * void256 (~void@anon) has joined #jogamp
20130502 22:21:40 * void256 (~void@anon) Quit (Remote host closed the connection)
20130503 03:10:41 * ___m___ (~Mike]@anon) has joined #jogamp
20130503 03:11:26 * [Mike] (~Mike]@anon) Quit (Read error: Connection reset by peer)
20130503 03:14:15 * ___m___ is now known as [Mike]
20130503 03:15:31 * [Mike] (~Mike]@anon) Quit (Client Quit)
20130503 03:50:54 * [Mike] (~Mike]@anon) has joined #jogamp
20130503 04:59:16 <[Mike]> javafx & newt :'(
20130503 05:05:50 -CatOut- Continue @ http://jogamp.org/log/irc/jogamp_20130503050550.html