If the surface gets unmapped and mapped again we have another GDK window
so we have to reconfigure the layers surface on map and destroy it on
unmap.
This will be merged back into phosh if it works out.
The later would invaliate the drawn area again and again in a ::draw()
handler. This caused infinite redraws when e.g. a key was locked. To
reproduce break e.g. on `eek_gtk_keyboard_real_draw()` and see how it is
invoked again and again.
We're only keeping the signal ids around for disconnect but that only
happens in dispose so it's o.k.to just disconnect all keyboard signals
we listen to.
The original eekboard code scaled icons by a factor. That was simplified
in c529e9ed9c but we can do away with it
completely and fetch the icons at the right size making them not blurry.
Instead of doing scale guessing we know that we get a properly
sized image from GTK+ so just scale it down a bit so it gets
some border within the drawing area.
Use existing concepts of levels and modifier latches and locks to
implement the three view design of issue #38.
The use of a lock to switch from letter to numbers and a latch to
handle upper and lower case has side effects, but these can be
addressed in a future commit.
- use G_DECLARE_ and G_DEFINE_ macros
- move all data into ClassNamePrivate
- use _get_instance_private()
This should not introduce any functional changes or breakage.
Skipped two classes (EekKeyboard and EekboardContextService) for now in
order not to break the build.
These two classes are used in some very funky WIP code that tries to
circumvent encapsulation.
(Funky code is in eekboard/key-emitter.c and eekboard/eekboard-context-service.c)
- Replace two calls to deprecated gdk_cairo_create()
- Alleviate asymmetry between rendering pressed and released keys
by consistenly clipping the same area up front to avoid
artefacts
- make sure pressed and released keys are shown immediately by
calling gdk_window_invalidate_rect()
- improve consistency between render_(pressed|locked|released)_key
- improve code flow
