Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
For consistency with event types (since "obscure" is opposite "expose") and the
upcoming puglObscureRegion().
|
|
In general, it's more convenient to have full-width integers as parameters,
since C will promote any arithmetic on smaller types to them anyway. Using
narrow types here, then, doesn't really make anything stricter, just forces an
annoying cast when lots of warnings are enabled, which is likely unchecked.
Better to handle it here, since it's more convenient, and the integer range
checks the compiler can do aren't correct anyway (the max width/height is
intentionally smaller than the max PuglSpan, so it can fit in a signed 16-bit
integer).
|
|
These could be combined into a hint-like general get/set mechanism, but
currently there's only two window relationships and no immediate plans to add
more, so that feels a bit over-engineered. So, just rename for consistency
with puglSetTransientParent().
|
|
Sigh. Doxygen is the worst.
|
|
I don't know if vendoring the Vulkan library is appropriate, but regardless,
this allows applications to set the name to whatever they want, or specify an
absolute path, just in case the standard value baked into Pugl isn't the right
one in some situation.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Towards a more direct and explicit mapping to platform hints, and more
consistent behaviour across platforms. OpenGL applications are generally
expected to be explicit about hints like this.
|
|
|
|
|
|
|
|
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.
|
|
This becomes important when the documentation is included in larger projects.
|
|
|
|
Support for deleted method syntax has improved in clang-format 14.
|
|
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 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.
|
|
This collapses many functions into one, which makes the API more easily
extensible and reduces code size.
|
|
|
|
I suspect that using the same configuration across both C and C++ is starting
to wear a bit thin, but this will do for now.
|
|
|
|
|
|
See https://reuse.software/ for details.
|
|
|
|
|
|
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.
|
|
|
|
|