GNOME Bugzilla – Bug 576548
Editing text in Antialias mode (with cairo renderer)
Last modified: 2011-01-09 18:21:56 UTC
On Windows Vista Business x64 the user does not have the proper feedback (yellow highlight) to start editing text in objects when the antialias mode is on. The text background remains white and the behaviour of the editing is simply unusable.
When using the new cairo renderer this is the same on all platforms. The old libart based renderer still does the highlithning as before. Although I like the feature from the users point of view, I highly dislike how it is implemented. So either the whole highlighting mechanics need to be redone in a clean way, or - more likely - Dia 0.97 will ship without this feature. After all the work-around is simple: don't use the antialiased renderer for text editing and connection work. An alternative would be to default to the old libart renderer for the interactive case.
Lowering priority given the change below: 2009-03-29 Hans Breuer <hans@breuer.org> * app/display.c : the interactive cairo renderer has highlighting issues (bug #576548). For now default to the libart renderer for the antialiased display renderer (only fall back to cairo if the libart plug.in is not loaded) * plug-ins/libart/dialibartrenderer : initialize DiaRenderer::is_interactive to allow entering text edit mode
Ok, there actually was a bug in the cairo renderer making text editing with it unusable: the cursor position was not updated. Now it is: 2009-04-04 Hans Breuer <hans@breuer.org> * lib/diarenderer.c(get_text_width) : complain if the derived renderer does not implment the method and does not maintian DiaRenderer::font. * plug-ins/cairo/diacairo-renderer.c : actually maintain the font field to make text cursor position calculation work, part of bug #576548 Still no highligthing for the reason given above.
Do you have any plan how the highlighting should be done in mind?
I have not thought it through completely but here is what I dislike: The current implmentation is keeping the state in every object (DiaObject::highlight_color) and in the renderer to support it: e.g. DiaGdkRenderer::highlight_color. But the real highlighting state is managed by the diagram (where it needs to be). So I think we could get rid of the object knowing about highlight state; may be able to provide methods in the InteractiveRenderer interface to perform highlighted rendering and have something like a "highlighting selection" (similar to standard selection) to manage which object should be rendered highlighted. Additional it may be possible to make it optional if the highlighting implementation really uses a color at all. At least with the cairo renderer it could be possible to have a different reflection of the state e.g. dimming the other objects. Look e.g. at GIMPs crop tool to get an idea of one possible effect.
Created attachment 135703 [details] [review] Refactor highlight Adding these patches to this bug to track progress
Created attachment 135704 [details] [review] Highlighting cleanup second iteration
Created attachment 135705 [details] [review] Give control of object update rectangle to interactive renderer
As already said the first two patches look ready to commit. But for the third I'm still uncertain (to much change for too little gain). Maybe I need to see some renderer actually needing this indirection to do some more fancy highlighting.
Comment on attachment 135704 [details] [review] Highlighting cleanup second iteration The first two patches are now merged and pushed (sorry for the delay). Any chance to have cairo-renderer specific highlighting?
Created attachment 148953 [details] [review] Cairo highlighting Here is first try of (hopefully working) cairo highlight support. It uses similar highlight style as gdk renderer. I had to do some changes (hacks?) to font.[c|h] and display.c because text rendered with cairo has different width (because of hinting I think). Maybe there is better way to accomplish this, because this way is not very pretty. Also when changing from gdk renderer to cairo cached text width values should be re-calculated. Is there a simple way to force that?
Bug 558350 seems to block use of cairo (at least with pango) for now.
The must be a better than again increasing the coupling between renderers and global font measuring. I don't quite understand you bug #558350 - never hace seen this effect with stock Dia. Is there a relation to bug #341481 (Dia bug #573261)?
Created attachment 174197 [details] [review] Cairo highlighting Here's cairo highlighting patch updated to current master. Since bug 558350 has been fixed this seems to work reasonably well (tested briefly with Pango 1.28.0 on Ubuntu 10.04)
The better way from comment #13 seems to be the implementation of DiaRender::get_text_width, see: http://git.gnome.org/browse/dia/commit/?id=76b2db88c74ae4fbce28a1ad649a1068033fb64f For highlighting I've choosen a different approach as outlined in this commit: http://git.gnome.org/browse/dia/commit/?id=2aecb70084d0a2f31cf99d3e5dd2224a30858a45 Heikki: Hope it works for you, too. And thanks for the patches anyway.