Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
This allows dark applications to visually integrate more nicely in Windows 10.
A little thing, but it really goes a long way to make programs not look out of
place and half-baked.
|
|
This replaces the window title and class name APIs with a more general one that
can be easily extended to other things, like icon names, more detailed
application hints, and so on.
|
|
|
|
This was just a source of ambiguity and bugs, since it represented different
things at different times and could become stale. Redundant data is always
trouble, so eliminate it, leaving just two positions/sizes: the defaults (used
when the view is not yet realized), and the last configuration.
|
|
|
|
This is only really relevant in practice on MacOS and Windows. On X11, the
window manager places new windows where it pleases.
|
|
|
|
This guesses the likely scale factor when the view hasn't been realized (and so
there's no real window to get information for). It may still be wrong for
multiple display systems, but will always return some scale factor that
"exists" on the system, and should always be correct when there's only one
display.
|
|
|
|
|
|
|
|
|
|
|
|
As evidence that this was confusing, the documentation for these was an
outright lie, and I've burned quite a bit of time in the past few days trying
to rework things based around that flawed understanding.
These names make it clear what these events actually are. If we need actual
create/destroy events with a broader scope, they'll have to be added, but I
suspect those aren't actually useful anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|