Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On MacOS in particular, views and windows are entirely different concepts, so
confusing them... confuses things. This was the last holdover in the API that
used the old "native window".
|
|
This makes the internal header structure match the "kinds" of definition inside
Pugl: common implementations of public API, things available internally to
platform implementations, and things the platform must define.
|
|
|
|
|
|
This implements a more powerful protocol for working with clipboards, which
supports datatype negotiation, and fixes various issues by mapping more
directly to how things work on X11.
|
|
|
|
|
|
These are redundant with puglSetFrame in a sense, but allow setting the size of
a view without the position, or vice-versa. This API also maps more nicely to
Wayland, where applications can not position themselves (but can resize).
|
|
Actual window sizes and positions fit easily in a 16-bit integer. So, we use
that in "representation contexts" like events. This makes structures smaller,
and allows the values to be converted to float, double, or integer without
casting (since any int16_t or uint16_t value can fit in them without loss).
Setter APIs use native integers for convenience, to avoid casting hassles when
doing arithmetic. Ranges are checked at runtime.
|
|
This collapses many functions into one, which makes the API more easily
extensible and reduces code size.
|
|
|
|
This avoids potential clashes between multiple copies of Pugl statically
compiled into several modules.
|
|
|
|
|
|
|
|
|
|
See https://reuse.software/ for details.
|
|
|
|
There's no universal consensus on how buttons are numbered. Left, right,
middle as 0, 1, 2 seems to be the most common convention on modern vaguely
similar libraries, so I've gone with that.
The switch to zero-based indices will obviously break all current client code.
Particularly since now is the time to finish any breaking changes before a
stable release, I think that is better than only changing the middle and right
numbers, which would likely go unnoticed.
|
|
|
|
This prevents plugins from changing global host state, which causes serious
problems in hosts that are not DPI aware.
|
|
This avoids a warning, and makes more sense in this situation anyway because
negatives are also a bad configuration.
|
|
Aside from reading more naturally, this avoids clashes with types that are not
events, like PuglEventFlags. This is also more consistent with the C++
bindings, where "EventExpose" would be quite strange, for example.
Apologies for the noise. Aliases to the old names will be preserved in the
deprecated API like other things for a short while.
|
|
Avoids narrowing warnings when building as C++, and uses unsigned operands with
bitwise operators in various places.
|
|
|
|
Stub backends were a dependency of other backends to allow some code reuse.
However, that can cause conflicting symbols if multiple backends are linked
into the same binary, which should be possible.
To avoid this, move the shared code into the platform implementation, and
export those symbols so that backends can use them. This adds some semi-public
platform-specific API that can only be used by backends included with pugl.
They are undocumented, subject to change at any time without a corresponding
version change, and may not be used by third parties (for example by custom
backends in an application).
|
|
X11 Window managers set WM_STATE to notify about minimization, often without
sending core X visibility events (which seems odd to me, but that's what Gnome
does anyway). So, implement this protocol and send map/unmap events to the
view, and adjust the Windows implementation to do the same for consistency
across all platforms.
|
|
I don't think there is any UB actually happening here, but some of these were
casting to a pointer of a larger type, which is problematic. Unfortunately, it
makes for quite a bit of tedious verbosity, but I don't see a decent way around
that in C99.
|
|
|
|
|
|
|
|
These will not be used in the Sphinx documentation, and most were
self-explanatory and only there to make the Doxygen index look nice anyway.
Where there was actually useful information, it has been preserved as regular
comments.
|
|
These names were confusing because a view is not necessarily a window. Since
there's no room for ambiguity here, simply drop the superfluous word.
|
|
|
|
I think this attempt to be optionally header-only was misguided, particularly
installing source code to the system include path. Typically anyone vendoring
code just includes the repository and builds from there anyway.
This commit moves all the implementation code to a typical src directory (Don't
Be Weird).
I still think there is some value in simple "inline" deployment, but that would
be better achieved another way, like producing a single-file amalgamation that
builds anywhere, ala sqlite.
|