GNOME Bugzilla – Bug 99375
Empty Text, should not exist
Last modified: 2019-03-20 11:03:06 UTC
how to find and remove empty text objects? okay, you could step through every text element using the objects dialog but it is still not ideal. editing the source file is probably the easiest solution. Arguably totally empty text objects should not exist at all. I was going to make the summary a question but i find it hard to think when it might make sense to have an empty text object, especialy since the current text object is so hard to find. if empty text objects were automatically removed you would have to be very careful about dia shapes that would include a text object that needed to be filled in, but that could probalby be worked around by having the text object set to some default value such as 'Label N'.
But text objects are created empty. I suppose you could remove them when they become unselected, but they have no way to tell when they're unselected.
I guess i am just specifying one of the problems with the current text widget because i really want something that acts more like a Web TextArea. Perhaps i should close this and file a report instead requesting a better text widget?
Set to 0.92 (UI cleanup) milestone. This would mostly fall under a better text input method.
Is there a bug report for "Better Text Widget" yet? (i dont see one, should i create one?) /me dreams of RichText (i.e. bold italic underline) and MathML i was also thinking that when it comes to resizing we could resize a text area but leave the font size alone. i intend to take a careful look at what Visio does and then i will add detailed comments to the resize bugs.
Bugs should not target milestones we have already passed, mass retargetting to version 0.95.
Should be possible to do with the next start/end text edit code, as soon as we are sure it's used everywhere.
Unselected rather than unfocused is probably better. If you select several items, you can tab between them, wouldn't want to have it disappear in the middle of it. On the other hand, we have to be careful that it doesn't disappear just because we internally deselect and reselect. It's however probably only the standard textobj that needs to go, all other texts have other stuff and shouldn't just disappear. Probably not going to work on it for 0.95, as I want the text select/ highlight stuff to be stable and tested before doing this.
Not getting the start/end text edit code this upcoming version.
Just cross referencing this is also a Debian report at http://bugs.debian.org/405829
There's another good reason to remove empty text objects: they can enlarge the bounding box of your figure without being clear why. This can be very annoying, since you only discover such an unusual large bounding box when you export a figure to (for example) EPS.
*** Bug 439892 has been marked as a duplicate of this bug. ***
Rather than messing with automatic object deletion I have just commited a fix for the IMO most annoying issue: 2008-05-10 Hans Breuer <hans@breuer.org> * lib/diagramdata.c(layer_update_extents) : don't consider empty objects for the overall extents. Fixes bug #531687 and lowers priority of bug #99375. * plug-ins/wmf/wmf.cpp : don't assume pango_context_load_font() can not fail. It does for font descriptions pointing to fonts not available on the particular system. also there is a small plug-in to help the user remove empyt objects: * plug-ins/python/select_empty.py : allows to find objects with empty bounding boxes like empty text. See bug #99375. The main issue of this bug will remain until someone comes up with a good working pacth.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/68.