Age | Commit message (Collapse) | Author | Files | Lines |
|
This allows retrieving properties of the view that may be needed, such as the
actual bit depth (which may vary from the suggested depth provided as a hint).
|
|
|
|
I don't have any particular future use case in mind, but I think the concept
makes sense for general events and it seems it could be useful for things like
gestures as well. Also fixes another padding warning in the API.
|
|
|
|
This was never particularly useful, and it makes no sense with the new drawing
model, even on X11, so its presence just adds confusion. So, remove it, which
also conveniently fixes a padding warning in PuglEventExpose.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not really sure why I used a web link here (maybe because it's more stable),
but this is more conventional.
|
|
|
|
|
|
The sloppy use of "window" caused quite a bit of confusion, since views only
correspond to top-level windows in some cases, and on MacOS, a non-top-level
view is not a "window" at all.
|
|
|
|
These old "notify" names are a smell from X11 which is a bit strange and
inconsistent here, since nearly everything is a "notification" of sorts. I
think the new names here are much more clear since they are consistent with the
keyboard focus events.
|
|
Now that timers are exposed, applications can repeatedly nag for attention
themselves if they really want to.
|
|
|
|
|
|
The previous separation between polling and dispatching was a lie, especially
on MacOS where it is impossible to only poll for events without dispatching
anything. Providing such an API is misleading, and problematic in various
other ways.
So, merge them into a single puglUpdate() function which can do the right thing
on all platforms. This also adds the behaviour of actually processing all
events in the given time interval, which is almost always what clients actually
want to do when using a positive timeout (naively doing this before caused
terrible input lag).
|
|
Unfortunately this is an API break, but there's no reasonable way to deprecate
the old function and this is required for things to work correctly. The type
will be used in following commits to tick the main loop and dispatch events
correctly for either case.
|
|
|
|
|
|
|
|
|
|
This event makes it possible to send an arbitrary event to a view, which is
useful for many things. In particular, this method of communication with views
will wake up the event loop, unlike hacks in applications that share data in
some other way.
|
|
These can be used to do things when a view is created or destroyed, in
particular set up the GL context in a more controlled way. Map and unmap
events are also added for when views are shown and hidden so application can
react to this as well.
Towards the deprecation of puglEnterContext() and puglLeaveContext(), which are
prone to abuse.
squash! Remove client event stuff
|
|
|
|
|
|
|
|
This dispatches events on a per-window basic instead of globally, using the
same mark trick as before to bound the number of events dispatched.
After the events are dispatched, all the windows are updated if they have an
invalid region. This ensures that all windows get drawn every iteration if
necessary, since Windows itself does not send WM_PAINT messages if there is
lots of input activity.
|
|
This is identical to PuglEventAny.
|
|
|
|
|
|
|
|
This is needed for clipping. Unfortunately, the puglEnterContext() and
puglLeaveContext() API was not suitable for this, but this shouldn't matter in
user code because it is only used for setup, and is slated for removal anyway.
Instead, just call the backend functions directly in the implementation.
|
|
This avoids resizing the backend when the window is only moved, which fixes
flicker with Cairo where resizing is expensive.
|
|
Working on Vulkan clarified what has always been slightly smelly about the
design and organization here: not everything that is API specific is really in
a "backend" (a PuglBackend). The concrete example is puglGetProcAddress(),
which only makes sense for GL and is actually implemented in the "backend"
files. Arguably puglGetContext() is also such a thing.
So, rename the headers so they can be the place where API-specific things go in
general, which happens to include a backend most of the time. The stub is a
bit of an exception to this, but whatever. The includes look tidier this way.
In place of the old headers are compatibility stubs that just emit a warning
and include the new version, which will be maintained for a while.
|
|
|
|
|
|
This was just leftover cruft from before error handling was cleaned up, any
failure to configure must now be reported by the backend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prepares the API for proper error handling, even though there isn't any for
these functions yet.
|
|
|