Re: can't use meson for 'freetype-demos'

[Werner LEMBERG]

> I'm currently working on non-outline glyphs support.  I'll post the
> roadmap later on the GitLab Issue (after taking consideration of
> points mentioned in your feedback).

Thanks.

>> * I use a dark KDE theme; `ftinspect` looks as shown in the
>>   attached image.  As you can see, the selected colours are
>>   suboptimal.  I think that a 'dark' theme must be ignored for the
>>   grid background.
>
> Err... Will look into this further.

Thanks.  Of course, this is a problem *I* introduced, not you :-)

>> * It would be nice, however, to have an 'invert' option or radio
>>   button to invert the colours: black background, white pixels,
>>   etc.
>
> Got it, but may be not trivial or clean to implement.  I will list
> it as a further plan.

Interesting.  Why is that?  FreeType only produces 256 levels of
opacity; I thought it would be straightforward to map them inversely.

>> * I very much dislike the big 'help' screen explaining the scroll
>>   functionality.  Instead, based on KDE's 'dolphin' file manager, I
>>   suggest a small '?' button at the top right (directly left of the
>>   'minimize' and 'maximize' window icons); if pressed, the cursor
>>   changes to a cursor with a question mark, and the user can then
>>   click on interesting objects to get contextual help.  Of course,
>>   a similar, different solution would be fine, too.
>
> I see. You mean what's called "What's this" button on Windows I
> assume, but it had been phased out long before, in Windows Vista.

Hehe :-)

> And the Qt solution for this is non-trivial on Windows (pretty easy
> on Linux though). Need to come up with a better approach later IMHO.

OK.

>> * Ctrl+Scroll and Shift+Scroll doesn't work – I assume this isn't
>>    implemented yet?
>
> They're factually implemented (as shown in the GIF).  I will give it
> a test once I prepared a desktop Ubuntu environment.  I would be
> glad if you could place some breakpoints around
> `src/ftinspect/rendering/glyphcontinuous.cpp:71` and have a look at
> the value of `numSteps` and `event->modifiers()`, so I can firstly
> have a idea about the bug.

Hmm.  I use a laptop with a pad, not a mouse with a wheel.  I set a
breakpoint as asked, but function `wheelEvent` is never hit.  Just to
be sure: Alt + Wheel (or rather its pad equivalent) for horizontal
scrolling works fine for me.

>> * (Maybe a KDE thing, I don't know the conventions used on
>>   Windows): Right now, using the arrow keys change the grid
>>   viewport in relatively small steps, and Ctrl/Alt have no
>>   influence.  What about making Ctrl/Alt plus arrow keys change
>>   that?  For example, under KDE I can move a window pixel-wise by
>>   adding the Ctrl key, and adding the Alt key yields much larger
>>   steps than the arrow keys without a modifier.
>
> I have no idea about this behaviour, but it's doable anyway. Will
> put it onto the list with a lower priority.

I was a bit unclear: You first hit Alt+F5 to activate the 'move window
mode', then the abovementioned key combinations work.  If you are done
with positioning the window, you press enter to confirm the current
position or ESC to abort the positioning.

>> * What exactly does the 'Count:' field mean?  It isn't obvious.
>>    Perhaps a better name is needed.
>
> It means the numbers of glyph being rendered onto the canvas, and
> the name is adopt from `ftview` tool. As of a better name, what
> about "Viewport Glyph Count" or "Visible Count"?

Hmm.  Do we need this info at all?  I actually don't see a value in
it.  I suggest you remove it – or you convince me that it is
essential :-)


    Werner