RejectedSoftware Forums

Am 04.01.2016 um 18:10 schrieb Robert M. Münch:

Hi, I have two questions (x-post from digitalmars.D.learn) regarding the
following, IMO very cool, vibe feature:

"Contrary to most other frameworks supporting asynchronous I/O, vibe.d
fully integrates with the UI event loop, so that it can be used to power
applications with a graphical user interface."

1. Am I right, that there is no GUI event handling for OSX support yet?

If, are there are any technical limitations in vibe that it couldn't be
added?

Yes, I never had the change to look deep enough into how Cocoa exactly
interacts with the low level event loop so far. I suspect that it will
require custom code instead of using libevent, though. You can of course
integrate manually by calling processEvents periodically (even if that
kind of defeats the purpose of event based I/O, but it's a decent
solution at least for games).

1. Are there are any examples WRT to using vibe with a GUI & network

event loop?

There will be a chapter in the upcoming "D Web Development" book:
https://www.packtpub.com/web-development/d-web-development

I have some internal code, but nothing publicly available. When I get
around to work on this some more to add full OS X support, I'll write up
an article.

1. Are GUI events for the different platforms are abstracted or native?

Native. For Windows, you basically just have to create your window as
usual. DispatchMessage is called internally to dispatch events to the
window procedure. On X11, you'll have to get the display file descriptor
and use createFileDescriptorEvent to wait for incoming messages. When
something is available for read, use the usual xlib functions to process
individual messages (XPending and XNextEvent).

On 2016-01-04 17:42:37 +0000, Snke Ludwig said:

1. Are GUI events for the different platforms are abstracted or native?

Native. For Windows, you basically just have to create your window as
usual. DispatchMessage is called internally to dispatch events to the
window procedure.

I skimed through the vide.d sources to get an idea how it's done. This
is my current understanding, please feel free to correct:

1. vibe uses an own window class

2. it creates a windows at position 0,0 with dimensions 0,0 as message
   only window (so not visible)

3. window messages are handled by Win32EventDriver.onMessage(...)

4. this handler handles manual and socket events but no GUI events.
   There is currently no way to register a "callback" like for file or
   network events through the vibe framework.

5. all messages not handled are forwarded to the default window
   procedure (I think it's the OS at this point)

Assuming I'm right so far, the following should be true as well:

1. to implement a GUI application I have to subcalls the vibe window
   class and provide my own window message handling function and later
   call the vibe window function to keep everything running. My own
   messages will be processed BEFORE vibe's messages in this case.

General questions:

a) What is this "filewriters" stuff about?

b) Do you plan to abstract away the GUI event handling like it's done
for files and network stuff?

Robert M. Münch
http://www.saphirion.com
smarter | better | faster