and cheat around to trick CSS into believing it's a treeview with
a header that says "Preview". Setting its width so it won't jump
around is still broken.
"magnification-api-win32.h" was not included in the dist!
Note that I know that alphabetical order is wrong. I am planning to
actually change the name of the file (more in line with other filenames)
but I am waiting to finish a review of another patch from Gil before
doing so. So just let it as-is for now! ;-)
(cherry picked from commit a2902790cc)
by simply drawing the buffer with cairo_mask() and a stipple pattern
so we get the same effect as before, but without rendering the
widget's background color into the buffer ourselves.
and also be smarter about what devices we enable by default: enable
all tablet devices and disable all things mouse, they can still be
enabled in the device dialog.
We were keeping around a flag telling us if coordinates are extended or
not. In GTK+2, a device indeed had to be enabled. In GTK+3, I can see
that device with extended inputs are enabled by default (they always
have pressure, etc.). This flag is made useless.
This fixes a crash when we were looping until GDK_AXIS_LAST, but our
existing code was expecting less values.
Also I note that GTK+3 has an additional GDK_AXIS_ROTATION since version
3.22, even though we were told that some pens with rotation support
would report rotation values with same valuator as for the wheel (at
least, the Wacom Art Pen would apparently use the same 6th valuator).
For proper support, it would be really worth testing such pens.
we were not using a single GtkStatusBar features, it was only in the
way. Remove broken size allocation logic and simply set a minimum
height of 3em in CSS. Also ellipsize the label, long labels had funny
effects since changing the overall GimpDisplayShell packing to pure
GtkGrid.
This will in particular fix the whole DLL hell problem since various
plug-ins are now asked to install all their mess (and in particular
their embedded DLLs on Windows) inside their subfolder, hence not
disturbing the correct functionning of other plug-ins installed side by
side.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
Michael Natterer