Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
It turns out that this is flaky for reasons that aren't terribly clear from the
documentation. So, just ignore it, it's not the end of the world if raising
doesn't happen anyway.
|
|
|
|
The internal puglPollWinEvents() abstraction was doing more harm than good.
|
|
|
|
|
|
For consistency with event types (since "obscure" is opposite "expose") and the
upcoming puglObscureRegion().
|
|
The code to find the initial size and position for a view had a lot of
duplication, and was inconsistent between platforms. Flaky positioning and
attempting to center embedded children has historically caused a bunch of
problems in general, particularly since windows can be resized.
So, factor out all the initial size and position code so that the logic is in
one centralized place used by all platforms, and always position embedded
children within their parent at the top/left origin. For top-level windows,
the view is centered on its transient parent or the screen (as before). A new
platform function puglGetAncestorCenter() is used to do this in general code.
Also towards a total separation of position and size, towards support for
Wayland, where applications don't dictate their own positions.
|
|
|
|
|
|
|
|
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).
|
|
There is API to access the minimum timer resolution, but it seems to always be
1 millisecond, which is also the unit of the MsgWaitForMultipleObjects
parameter, so just avoid the fuss and hardcode this as the minimum.
This should slightly reduce overhead when the main loop is running without much
of a margin until the frame needs to be drawn.
|
|
|
|
This isn't a strict enumeration anyway, so a sentinel value does no harm, and
using it avoids warnings about testing an enum with no zero value.
|
|
|
|
|
|
|
|
|
|
Platforms differ here, but it's meaningless to ask about the state of a
modifier that's currently being pressed or released, so simply mask this out in
general so it's easy for platform implementations to clean events up before
dispatching them.
|
|
|
|
|
|
|
|
|
|
|
|
The documentation explains that the PAINTSTRUCT returned by BeginPaint() should
be passed to the corresponding call to EndPaint(). I'm not sure what
real-world effects not doing this had, but this commit fixes things to use the
API as intended.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|