Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We'll need identifiers for these to refer to them in the Sphinx documentation.
|
|
This will not be used in Sphinx.
|
|
|
|
|
|
|
|
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.
|
|
This causes some annoying typesetting issues it's simpler to just avoid.
|
|
Eventually we'll need an actual smart flags type here, but for now there's only
one flag anyway, so simply define an overload that takes one.
|
|
This was a bit weird since event dispatching can be handled by some other
object. Just remove them, and have clients use a catch-all template to handle
events that are not handled specially.
|
|
The old version had some weird Inkscape stuff in it that couldn't be displayed
by Firefox, or presumably other generic renderers.
|
|
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.
|
|
These only do anything for OpenGL, and it seems unlikely that they will ever be
used for anything else. So, move them to the GL headers to remove clutter from
the core API, and ensure that they are only used in GL applications that
include the appropriate headers and link with a GL backend.
Also add missing C++ bindings.
|
|
This allows puglCreateSurface() to be used with some other loader, or when
linking to Vulkan at compile time.
|
|
These libc-specific warnings are a new level, even for LLVM. Using an opt-out
style for this is probably not going to last.
|
|
This fixes an issue where the default frame position would be set based on the
screen size for child windows. This went unnoticed so far because most
plugins, like pugl_embed_demo, explicitly set the frame and so avoided this
code path.
Also generally tidy up puglRealize() along the way to make it a bit more
readable.
|
|
Fun with union punning. The different sizes mean that stuff on the stack could
be copied to the destination event. I don't think this would cause a concrete
issue (the contents of the event past the expose are irrelevant) but asan quite
reasonably has a problem with it.
|
|
|
|
|
|
It's a nightmare trying to get this thing to check everything.
|
|
|
|
|
|
|
|
This removes virtual function overhead, and the weird situation of having to
include pugl.ipp once (or worse, for pugl to provide a binary C++ library).
|
|
|
|
|
|
Losing assertions is unfortunate, but these slow down compile times, and in
this case the scope of error is small enough that the risk is minimal.
|
|
This avoids an include of <exception>, which is slow, and is better practice
anyway.
|
|
This is nice, but it bloats the header quite a bit for something that may not
be used and requires the C++ standard library.
|
|
Although it's generally a good idea to use known-solid std classes, in this
case the wrapper is very simple so it's not worth including <memory>.
|
|
|
|
|
|
|
|
This was missing from the C++ bindings and barely used anyway, so just remove
it for now in the interests of simplicity and finalizing a stable API.
The information previously logged in the X11 GL backend is now available
programatically, so applications can print the same information portably if
they like.
|
|
|
|
|
|
Include them in pugl_gl.h instead, to simplify things and unclutter the include
directory.
|
|
|
|
This seemed messy and potentially misleading for what is fundamentally a C++
library. It also makes it possible to set separate clang-tidy and clang-format
settings for each to avoid "tainting" the C settings, though currently the
headers use the same checks.
|
|
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.
|
|
|
|
|