luapower / nw Goto Github PK

Windows: Wintab API, Ink API (we need both, sigh)
OSX: CGEventTapCreate ? see https://bitbucket.org/AnomalousUnderdog/pythonmactabletlib/src/dd0f93deaddaacbe58963d76a72bc3aba3b3d650/TabletLibC/tablet.c?at=master
X11: see https://github.com/serge-rgb/milton/blob/master/src/platform_unix.h

This doesn't seem possible with what X provides. Hacks accepted.

Why is this needed? Think toolbox windows: it's annoying as hell if they steal keyboard focus away from the main window and you have to click on it again to get it back.

SO Q: http://stackoverflow.com/questions/31433745/x11-non-activable-window

TODO

• X implementation
• cocoa implementation
• winapi implementation

Expose the window icon as a bgra8 bitmap to paint into.

win: XInput
osx: HID_Utilities
linux: God only knows...

Who wants to do this? :) X makes me want to stab my self in the eye.

Ability to set any argb8 bitmap as the standard cursor.

TODO:

• x11: ?
• winapi: ?
• osx: ?

This is mostly needed for freehand drawing but there might be other applications.

TODO
- x11 - query movement history?
- osx - disable coalescing (already done)
- winapi - ?
- make it a configurable option
- is it slow to have this always "on" ?
- OTOH it might not be needed while hovering)

Not sure if this is worth doing without doing #37 too...

Currently when the app is inactive, the active window is always nil (it is basically masked), so we don't really know which window will be activated when the app becomes active again. This is an orthogonality problem and a loss-of-information problem.

This masking was done on Windows to emulate OSX behavior but maybe we should have done it the other way around?

OTOH what does "active window" mean when the app is not active? and what use case could that have?

I don't see an API for this... emulating it is a pain, and it's a pretty useless feature (maybe we should remove this from the API altogether? I can't imagine a use case for this).

OSX: done (allows 3.2 or "legacy" whatever that means)
WGL: ?
GLX: ?

rationale: when in fullscreen mode in multi-monitor settings we don't want the cursor to go off-screen (or do we?); other use cases: games where mouse is used for movement

win: ClipCursor
osx: ?
linux: ?

When autoscaling is false, enable hi-dpi backbuffer.

In OSX this is just a function call.
In Windows this is ...?
In Linux this is ...?

Ability to invalidate a rectangle and repaint_rect() event which triggers for each invalid rectangle. The repaint() event still triggers for the whole screen (the user will choose to use repaint() or repaint_rect() but not both).

window:invalidate(x, y, w, h)
window:repaint_rect(x, y, w, h)

Frameless windows must be moveable too: they generally have a custom-drawn titlebar or you can drag them by the background. Let's help the user with this by implementing the mechanics ourselves and only ask the user where the designated "move area" is.

Done (hittest() can return 'move').

TODO OSX: prevent default resizing behavior on OSX when hittest() returns 'move' or false. If not possible, then implement resizing from scratch like in Windows and Linux.

bind GTK2 open and save dialogs

GTK2 because it's the most wildly available implementation, we don't want to ship QT or GTK3 or anything else.

TODO

• bind shm in xlib.lua
• use it in the rendering parts of nw_xlib.lua (check if it's available and use it automatically if it is)

Currently

• calling maximize() on a maximized window does nothing.
• calling restore() on a window in normal state does nothing.
• calling shownormal() on a window in normal state does activate the window.

Should we activate the window in cases 1 and 2 too?

this is a complete mess on all platforms... better look at glfw and/or sdl2 code on how to handle this... sigh

By default, OSX child windows are sticky and the sticky flag is not honored.

TODO: fixate (i.e. setMoving(false)) non-sticky children while moving parent.

We need the ability to have different threads wake up the GUI thread by posting a dummy message to it so that it can check on the thread's progress or whatever.

This API is too big, not functionality-wise (you need all that), but name-wise. Find more opportunities for API compression, like eg. the '#' arg.

Oh boy. This one is big.

The idea is to have keyboard events that give unicode code-points.

For Windows, WM_CHAR might even be enough (though we have to use WM_UNICHAR for 3rd party input method software).

For OSX it's not that easy (interpretKeyEvents and insertText are a joke -- they don't even work for french accents).

For Linux it's probably a complete horror show because X itself is a horror show (bears repeating).

OSX's animated fullscreen with 1s transitions that can't be turned off is a major usability blunter (many people are complaining on the net).

Make an alternative fast fullscreen mode that just removes the window's frame and stretches it fully on the current display, no BS animations. This mode should NOT be triggered by the standard fullscreen button (don't mess with users' expectations of what buttons do).

on Win7, toolboxes don't have a thin titlebar, even though the buttons are tiny as they should. WTF? (I swear they were thin on WinXP)

this also affects app:frame_extents() which returns the same extents for 'normal' and 'toolbox' frames.

• copy/paste text
• copy/paste files
• copy/paste bitmaps

For fixed-frame games (which is most of them) we need the ability to control the loop:

while app:poll() do
   ...render frame...
   time.sleep(time_left_till_next_frame)
end

win: done
osx: TODO
linux: TODO

API: app:mouse('pos', x, y)

Howto:

• x11: XWarpPointer
• OSX: ?
• windows: SetCursorPos() - done

an unmapped window on Unity has its coordinates wrong (looks like the client window is unframed and moved to where the frame was or something, god knows what these idiots are doing there)

Fixed: using XConfigureWindow() on show() and hide() to correct the coordinates. But who knows, on a differnet WM this might actually be a bad idea... we'll see.

I can't imagine a use case for this, but I'm sure there must be some because there's APIs for this.

Please add any use cases here if you know any.

Howto:
Windows: ?
OSX: objc.Event:mouseLocation()
Linux: ?

a window is modal when its parent is disabled and can't take focus away or put in front of the child (in Windows the parent can't even be moved and the modal's title bar flashes when that is attempted)

Bind the XCURSOR library/extension to set themed cursors.

Use the names and UIDs from defunct xcb_cursor https://github.com/capr/xcb_cursor/blob/master/xcb_cursor.lua

This flag indicates whether the window should be activated or not when showing it for the first time.
By default, a window is activated in normal and maximized states and not activated in minimized state.
This flag changes that for normal and maximized initial states.

TODO

• osx implementation
• winapi implementation
• x11 implementation
• check-* manual tests
• state-* automated tests

Honestly I don't have a use case for this (but I saw this feature in GLFW or SDL can't remember which).

This is needed in order to make close() a blocking operation.

Explanation:

On OSX, we need to exit fullscreen mode before closing a window because OSX takes one second to exit fullscreen and if in that second we put another window on screen, that window will have the fullscreen flag set (madness -- but the fullscreen flag it's actually a global in OSX disguised as a per-window flag). So currently, calling close() on a fullscreen window is deferred to when the window has exited fullscreen mode.

OTOH we want to make an API guarantee that the "closed" event is only fired on a window after all children are closed (because the "closed" event is usually used for resource clean-up). To implement that we need to call close() on all children before firing the "close" event and we can't do that with an async close().

The easiest way to solve horrors like this is to make the async operation which poisons everything else blocking. Currently in OSX that's only toggleFullscreen() and makeKeyAndOrderFront() but we don't care about the second.

VK_* codes are layout-dependent. For layout-independent keyboard mapping we need to use scan-codes.

NOTE: Linux and OSX key codes are already layout-independent (but also hardware-independent, so they're good), so there's nothing to do there.

NOTE: look at USB HID table -- there are useful comments in there about certain keys/keyboards.

Bind GTK2 menus

Child windows that follow parent when parent is moved.

This seems impossible to do correctly with what X makes available. Hacks accepted.

Story: http://stackoverflow.com/questions/32247059/x11-how-to-make-a-window-move-after-another

OSX on hi-dpi screens reports screen and window positions and sizes in so-called "points" instead of pixels. Remove that so that we can work only in pixels like in Windows.

This touches a lot of functions:
- frame rect / client rect / size / to_screen / to_client, etc.
- display rect
- icons rect
- resizing events
- mouse pos

NOTE: you don't need a Retina screen to test these. Any full-hd external monitor can be turned into hi-dpi mode for testing.

Currently most state-changing commands, i.e. hide, minimize, maximize, shownormal are ignored when the window is in fullscreen mode (all you can do is exit fullscreen).

TODO exit fullscreen mode before:
- hide
- minimize
- maximize
- shownormal
so that these commands can work properly at any time.

NOTE: blocked by #7

Is there any way to enable vsync on Windows for normal WM_PAINT-based painting?

If tear-free rendering is only available to OpenGL or DirectX surfaces, that makes cairo-based GUIs a dead-end.

Update: Using Aero enables desktop composition which enables VSYNC for every window, solving the problem entirely. For users who insist on having the old school Win95 look, they also get the old school tearing.

WS_EX_LAYERED doesn't work with Remote Desktop. This is signaled by UpdateLayeredWindow() returning false, in which case WS_EX_LAYERED should be disabled, the transparent flag should be switched to false, and invalidate() should be called so that the window can be repainted through WM_PAINT.

This bug makes transparent windows basically invisible under Remote Desktop.

affected APIs: client_size(), client_rect(), frame_rect(), to_client(), to_screen(), minsize(), maxsize()

Solution 0 (simple, fast): document undefined behavior

• document that the OS will return stupid inconsistent values for hidden and minimized cases
• document that the OS will do stupid inconsistent things when trying to set the client_rect(), frame_rect(), minsize() or maxsize() while the window is hidden, minimized or maximized.

Solution 1 (simple, preferred): mask off undefined behavior

• when the window is hidden or minimized these should return nil.
• trying to set client_rect(), frame_rect(), minsize(), maxsize() when the window is hidden, minimized, maximized or fullscreen should be ignored.
• setting minsize() and maxsize() at runtime is too restricted to be useful - consider removing the API altogether (the resizeable flag is not changeable either).
• normal_frame_rect() should always return the correct value (the whole point of it is to allow saving the normal frame rect when the window is closing from any state)
• document that *_moved() and *_resized() events can come with nil args (and fix tests) meaning that the client/frame area is invalid

Solution 2 (complicated with no real added value):

• have client_rect() and frame_rect() return normal_rect() when hidden or minimized
  • what about when minimized and maximized at the same time?
• allow setting frame_rect() when hidden or minimized, which affects the normal_rect
  • what about when hidden and maximized?

OSX frameless windows respect the resizeable flag by default.

Windows can be made to respect it with WM_NCHITTEST (but we have to come up with a border width - maybe using app:frame_extents'normal' would be a good default).

In X11 we need to resize these windows ourselves. This means:

• hit test the margins and corners
• set the appropriate cursor
• fixate a drag point
• resize the window on mouse move based on the initial drag point and current mouse position
• stop on mouse up

Make sure magnets still work through all this.

Note that in Linux we can only have magnets with frameless windows where we move and resize them ourselves.

In fact in Linux you have to bring your own WM to get anything done, maybe even your own X server. And graphics drivers. And a kernel. Or just screw the whole thing.

refactor to_client(), to_screen(), client_rect(), client_size() based on get_client_pos() and get_client_size()

have backends only implement app:frame_extents() and implement app:frame_to_client() and app:client_to_frame() in the frontend based on that

There's two types of events: passive events and queries. Queries are events that can respond by returning a value. Eg. "closed" is an event but "closing" is a query (returning false prevents the closing). Currently there's a mechanism for registering more than one handler to an event but it doesn't work for queries. Also, jquery-like off(event) and once(event) would be nice and a way to stop further event processing.

TODO:

• remove distinction between queries and events
• first handler which returns a non-nil first value stops the handler call chain

• add a "mode" arg to app:activate() which can be:
  • 'alert' (default; Windows and OSX only; on Linux it does nothing)
  • 'force' (OSX and Linux only; on Windows it's the same as 'alert')
  • 'info' (OSX only; on Windows it's the same as 'alert'; on Linux it does nothing)
• implement 'alert' and 'info' modes on OSX in terms of requestUserAttention()
• on Linux, activate on 'force' and do nothing on 'alert' and 'info'