Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
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 mainly used to allow the window manager to close locked or otherwise
misbehaving windows. The PID and hostname properties are both required to
properly support this, but may also be used for other things.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I'm not really sure about directly updating the frame like this - or whether
these fields should even exist in the first place (it's questionable whether
the view is "really" the new size until the configure process is complete) -
but regardless, the same pattern should probably be used for both size and
position.
"Probably", because touching anything like this tends to break some situation
or another somewhere, but such is life.
|
|
|
|
|
|
|
|
This must be called before any other Xrm functions are used.
|
|
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.
|
|
|
|
According to clang-tidy anyway, I'm not seeing it.
|
|
|
|
|
|
This avoids bugs in plugins, because otherwise it's possible that size hints
are not available when the host embeds the UI.
|
|
Calling X*ICFocus on NULL segfaults. This can happen if XCreateIC failed, for
example due to missing locales on minimal Docker images.
|
|
This avoids a Wunused-const-variable warning with GCC.
|
|
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 changes to getting cursors by name from the cursor theme, which makes the
cursor match the ones used in modern desktop environments. As far as I can
tell, there is no real standard for names, these ones seem to work for me in
GNOME, KDE, and Xfce.
I am not sure about the compatibility concerns here, but X11 without Xcursor
themes strikes me as either too esoteric or too ancient to worry about,
especially since cursor switching isn't critical functionality anyway.
|
|
This avoids issues when the default X11 cursor isn't the expected "default" of
the environment, for example with Plasma.
A real application that changes the cursor needs to do so consistently on mouse
enter and leave events anyway.
|
|
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.
|
|
Numerous things warn about this, and it's generally a bad idea to put these in
the code since it can result in incompatibly compiled code being linked
together. Unfortunately this makes building manually (without the build
system) more fiddly, but such is life.
|
|
|
|
|
|
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.
|
|
|