LÖVE

airstruck wrote:It would have been possible with addListener, of course.

slime wrote:

airstruck wrote:It would have been possible with addListener, of course.

addListener only handled events pushed through love.event – so love.draw, love.update, love.load, and love.errhand could not be 'listened to' with addListener.

airstruck wrote:I think it is. Doesn't mean it's a great standard. Consider this code:

Code: Select all

function love.draw (...)
    somelibrary.handledraw(...)
end
function love.resize (...)
    somelibrary.handleresize(...)
end
function love.mousepressed (...)
    somelibrary.handlemousepressed(...)
end
function love.mousereleased (...)
    somelibrary.handlemousereleased(...)
end
function love.mousemoved (...)
    somelibrary.handlemousemoved(...)
end
function love.keypressed (...)
    somelibrary.handlekeypressed(...)
end
function love.keyreleased (...)
    somelibrary.handlekeyreleased(...)
end
function love.textinput (...)
    somelibrary.handletextinput(...)
end
-- and so on

StandardHandler = {}

function StandardHandler.AddLibrary(lib)
  local wrapper = {}
  for _, v in ipairs { 'update', 'draw', 'keypressed' } do -- you can fill in the rest
    wrapper[v] = lib[v] or function() end
  end
  StandardHandler[#StandardHandler+1] = wrapper
end

function StandardHandler.call(event, ...)
  for _, wrapper in ipairs(StandardHandler) do
    wrapper[event](...)
  end
end

airstruck wrote:Consider this code:

Code: Select all

function love.draw (...)
    somelibrary.handledraw(...)
end
function love.resize (...)
    somelibrary.handleresize(...)
end
...
-- and so on

In my view that's annoying and borderline unacceptable. The point of library code is to encapsulate functionality. When you have to wire up a shit ton of events by hand like this, that's the opposite of encapsulating functionality.

Inny wrote:I would probably ask that they standardized on the names to match the event they are intended to be called from, and take the parameters that the event is provided. At the very least this would make it so we could write a standard wrapper

kikito wrote:Consider that if a library needs to be wired to many different subsystems, the problem might be that the library is trying to do too many things.

airstruck wrote:some code in a UI library I'm working on. It does need to use all of those events; it also uses wheelmoved which I forgot to add to that example, and will likely use one or two more window-related events in the future.

kikito wrote:My opinion is that your library seems to be doing more stuff than it should (as a single library).

airstruck wrote:Are you suggesting that the stuff that captures user input (from mouse, keyboard, window manager) should be moved into a separate library?

• 4 directional inputs related to the "currently highlighted control" (move the selection up, down, left, right). These are usually the arrow keys in the keyboard and the d-pad in a joystick. But a GUI library should not know that. It just needs someone to tell it "move the highlighted item up". Maybe the programmer wants to simulate that the player is drunk, and changes the inputs on purpose. The GUI can't know that.
• If there is a pointing devise (like a mouse), then the library needs to interact with it. But there might be screen transformations at play (cameras, resolution changes, retina display corrections, etc). So the GUI should not "take over the mouse". It needs someone to tell it "for you, the mouse is here". Maybe in the current game state the GUI does not need to know about the mouse, even if it's there. Maybe the programmer is simulating a software mouse in a tutorial. It is not up to the gui to know that.
• The library needs a way to tell when the currently highlighted control is activated. This could be the "enter key", or the "joystick A button", or the mouse button, or a touch in a touch screen. But again, the library does not need to know this. It just needs someone to tell it "activate the highlighted control now".
• In some particular cases, when dealing with text fields, it also needs to know the keys the user presses. Even in that case, it is not ok that it simply "takes control of the global keyboard". There are scenarios for this: maybe the programmer using the library wants to simulate an NPC using the GUI to perform some action. Maybe there is some sort of "macro" in place by which pressing a button, several controls change, and some input fields are automatically filled up. The point again is that the gui should "present the input for key presses" and allow the programmer to use it, as opposed to "grabbing the global keyboard".

• The first thing is changing game state. This can be done with Lua functions, and I think is not relevant for this particular conversation.
• The second one is drawing itself. But this does not mean that all that love.draw needs to do is drawing the GUI. In games GUIs are quite often drawn along something else. Maybe the gui is a minimap with buttons on the side, like the bottom of a Starcraft game. Maybe the user wants to apply filters to the whole screen (i.e. a screenshake) before drawing the GUI. The GUI must not know about this. It just needs to draw itself when it is told to.

airstruck wrote:If it were, would that solve the problem with the user having to wire up events or the library having to hook them?

You might even provide "default hooking mechanisms for the most obvious options"; but these should be opt-in and easily deactivable.