Hi all,

After a while (and Fred's well-timed prod), after a time-wasting summer camp, 
after getting over nasty headaches and cold, I've decided to (for now) give up 
on looking at avoiding having an OpalGState class. It seems to me that it'll be 
easier to query Opal for its state when appropriate, and have OpalGState do the 
right thing when -copyWIthZone: is called. (Again, this is the original 
approach and multiple times suggested by Fred, who is not to be doubted :-))

I still believe that long-term Opal and the Opal-based backend should be able 
to cooperate enough to avoid implementing GState in the backend as a class. 
But, for now, since Fred kindly pointed out to me (a long time ago) that GState 
means quite a different thing in AppKit than it does in Core Graphics (for 
example, I was unaware it can be copied, that the GState stacks can be switched 
independently of the context, etc) -- it makes little sense to use the little 
remaining time for playing with this when any work required to implement this 
quickly has to be done anyway in trunk, and can later be somewhat reused.

So to do something that'll be useful, I've first managed to figure out what's 
the minimum that needs to be implemented for the layout system to even pick up 
on information returned by -advancementForGlyph:, and size menu items 
accordingly in the Opal backend.

Happy with that, I moved on to doing the next necessary thing to get fonts do 
the right thing in Opal backend: figuring out the fonts on the system, et al.

In order to make this code shared with Cairo, I moved it to separate classes in 
"fontconfig/" directory. These are now base classes for Cairo backend's 
CairoFaceInfo, CairoFontInfo and CairoFontEnumerator.

Since this means I messed with a big, core part of GNUstep that's in active 
use, please test my changes in revision 37066 and yell at me accordingly.

My testing involved starting SystemPreferences and clicking around. Then I 
started Ink and played with the fonts panel. I did not see issues, which is why 
the code is now in trunk of gnustep-back.
--
Ivan Vučica
[email protected] - http://ivan.vucica.net/

_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Reply via email to