GNOME Bugzilla – Bug 122707
Text: can't make smaller boundary size of block
Last modified: 2008-09-23 07:56:41 UTC
It is not possible to confine a layer of text to a smaller boundary size than the image. At least not in an obvious fashion.
This is somehow implemented already but it lacks a GUI yet. Will happen before 2.0 but I think there's already a bug-report about the text tool being unfinished...
*** Bug 125145 has been marked as a duplicate of this bug. ***
Sven, Have you thought more about this? Do you still feel this can be implemented for 2.0? It would not be too bothersome to have some text tool features integrated in the stable series if they don't look like getting done now. IMHO, this feature could be bumped to 2.2 or even be introduced in a 2.0.1 or 2.0.2. What do you think? Dave.
I'd like to give this another try very soon now but it can be moved from the 1.3.x milestone to 2.0.
*** Bug 150447 has been marked as a duplicate of this bug. ***
*** Bug 307983 has been marked as a duplicate of this bug. ***
Upgrading target from Future to 2.6.
Created attachment 99948 [details] [review] patch against trunk to implement text box using rectangle tool I am attaching, for code review, a diff that implements the fixed-box functionality for the text tool (already set up by Sven for GimpText) using a rectangle tool interface. It also, as a free side effect, allows the text to be moved around within the text tool. Here is the concept: 1) If the user clicks on an existing text layer, and no rectangle yet exists there, we create a rectangle with the right shape, and allow the user to modify it. 2) If the user has modified the rectangle for an existing text layer, we change the layer shape or position accordingly. 3) If the rectangle that has been swept out is too small, we want to use dynamic text, so we halt the rectangle tool. 4) Otherwise, we use the new rectangle that the user has created as our text box. It isn't perfect -- there are a couple of nasty kludges that I didn't know how to handle correctly, and a couple of things that still don't work. One of them is undo: I can't find a signal I can connect to to tell me when an undo has caused the layer to move, and I need one. Another is that the "narrow" mode of the rectangle tool seems to be broken -- not clear if that's because of something I did, but probably. I had to make a few changes in GimpRectangleTool to get this to work. Most of it was adding a few convenience functions, but I also had to change the way the rectangle tool deals with tool->display -- it was making assumptions that are incompatible with the text tool. The rectangle tool changes are logically separate, and could be committed without altering the text tool. Also, I have completely ignored the issue of modifier keys. I don't think they should come into play in this tool, but something should probably be done to actively disable them. There is a little bit of debugging code left in the patch. I'll continue to work on the code in the meantime.
I very much welcome this but I think we should get a specification from Peter for this before the code is changed. This has worked nicely for the rectangle tools. Perhaps we can prepare the code for the changes until the spec is written. Bill, can you bring this up on the mailing-list?
Okay, I just sent an email. The text tool changes can hold indefinitely if nobody else starts modifying the tool -- the rectangle tool changes may be a different story. (They are purely internal, having no effect on the UI.) I'll coordinate with Enselic before doing anything there, though. In the meantime, I am attaching an update patch that fixes the narrow-mode issues.
Created attachment 99981 [details] [review] diff against trunk to give the text tool ability to change box shape Updated patch for the trial implementation, fixing the problems with narrow mode. As far as I know, "undo" is now the only thing that doesn't work as intended.
Created attachment 100548 [details] [review] update patch to address Enselic's concerns Updated patch to address Enselic's concerns about the changes to GimpRectangleTool. Note that I'm not to happy with the way "handle_rectangle_changed" is used in the text tool now, but can't see any cleaner way of dealing with this without making changes to the rectangle tool code.
Created attachment 100603 [details] [review] left out a file in previous patch
As I understand it, this bugfix, when completed, will implement the fix to Pango that enabled Fully Justified Text. Has there been any progress on this fix since the last post? When can GIMP users expect to see this function working?
Well, the target milestone is set to 2.6. If you want to make sure that this change will indeed be part of GIMP 2.6, then you could try the most recent patch attached to the bug.
(In reply to comment #15) > Well, the target milestone is set to 2.6. > > If you want to make sure that this change will indeed be part of GIMP 2.6, then > you could try the most recent patch attached to the bug. > Aha, I think that's a bit difficult on a Windows platform. Rather, I have no idea how I would go about testing that patch.
Created attachment 107944 [details] [review] patch for app/tools/gimprectangletool.[ch] This is a patch for the rectangle tool code, making changes needed for text-box functionality. I am attaching this for code review by Enselic.
Created attachment 107946 [details] [review] updated patch for text box interface Here, for convenience, is the full patch to current trunk, with changes to all files included.
I've reviewed that patch and asked bill to try to get rid of the `active' gboolean in GimpRectangleToolPriv.
I'm not sure how to proceed at this point. The basic problem is that, as currently written, the rectangle tool code "owns" tool->display, because it relies on that value to know whether it is active. This means that a tool that uses the rectangle interface cannot assign tool->display in any other way except by using gimp_rectangle_tool_start(), and must deal with the fact that tool->display will become NULL if the rectangle is hidden. I can work around this if absolutely necessary (I think), but it seems so broken that I feel there must be a better solution.
For me the best way to solve this is pretty clear (I've talked about the details on IRC) but this bug report is not the right place for discussing this.
Okay, I have made an initial commit for this. 2008-04-02 Bill Skaggs <weskaggs@primate.ucdavis.edu> * app/text/gimptextlayout.c * app/tools/gimptexttool.[ch] * app/tools/gimprectangletool.[ch] * app/tools/gimptextoptions.c: allow resizing of text box. This is work in progress, and needs some tweaks and fixes. See bug #122707. The only change in the rectangle tool code is to add gimp_rectangle_tool_rectangle_is_narrow(); I have worked around the other issues described above. There will need to be some fixes to the behavior of the rectangle interface in this code. The handles often look wrong, and the rectangle doesn't update properly for dynamic text. I would like to consult with Enselic on the right way to fix these issues. The interface as implemented is also not suitable for on-canvas text editing, and we should consult with Peter on how to get this right as soon as possible.
Created attachment 108726 [details] [review] patch for app/tools/gimprectangletool.[ch] another rectangle tool patch for Enselic to look at.
Created attachment 108733 [details] [review] Enselicified patch for app/tools/gimprectangletool.[ch] Conceptually it looked fine, but I did some changes to it. If it works please commit
Bill has commited a modified version of the patch.
We must decide if we like how this currently works in trunk, or if we need to do something about it. Raising priority to Urgent.
The current Text Tool code in GIMP is not finished, and since there is no one working on this any longer it to me makes most sense to revert the Text Tool to the state it was before it made use of the GimpRectangleTool functionality. I discussed this with bill on IRC and he didn't have any objections in doing this, and even thought it could be beneficial to have this done when the merge of the GSoC 2008 Text Tool project is to be done. I will in the coming week do the revert, and attach a patch here for reference that when applied to trunk restores the current GimpRectangleTool Text Tool behavior.
Please don't revert this (yet). We should have a discussion on the mailing-list and try to figure out what behavior we expect from the tool. Then we can decide if it is possible to implement this behavior or if we need to revert and postpone this to 2.8.
Figuring out what behavior we expect is a major project involving UI people, specs, and lots and lots of thinking, and then of course development time, and this is not something I think we can afford to do for 2.6. IMO the GimpRectangleTool approach feels wrong and I consider it a dead end. Especially when the person involved in it isn't interested in working on it any longer because of reasons he may elaborate on if he wishes. In addition to this, there is a Text Tool improvement GSoC project that looks very promising and the mentor has said that it would probably be benefitial to do the revert. Let's just revert it, release 2.6, and then start fresh with the GSoC Text Tool as the base.
If the thing involves a resizable and movable rectangle, how can the GimpRectangleTool approach be that wrong, especially given that it *already* works quite well with the patch?
I just think it feels like a hack, that's all.
To clarify; The user interaction doesn't feel natural at all to me. It might very well be improvable, for example by making the text update as you resize the rectangle, and not only when you're done.
Yes, but that is not a problem of using GimpRectangleTool. I don't see any reason why the text tool should implement the rectangle logic again.
I don't see any reason not to use GimpRectangleTool, especially since it was created with this usage in mind. The code has a few relatively minor problems, most importantly that it can leave empty layers behind if the user sweeps out a text layer but then doesn't type anything. The situation is this: back in April, I was busy working on this, fixing the remaining problems, and then, when I did an svn update prior to committing a set of fixes, I found that Sven had reverted my previous commit, without warning me or discussing it with me. That was the final frustration in a long series of frustrations, and I made a decision at that point that I was no longer going to commit any code to trunk, and I intend to stick to it. If you're going to feel free to alter the code while I am actively working on it without even telling me, I refuse to be responsible for it. So what you do with the code at this point -- fix, revert, whatever -- is up to you.
Bill, it is you who refused to talk about your changes on the mailing-list. You started to work on this without any prior discussion. But we absolutely need a discussion before such major changes are done. I should probably have reverted your very first change instead of waiting until things get out of hand.
*** Bug 547214 has been marked as a duplicate of this bug. ***
Looks like we are going to ship 2.6 with the current state. It has some usability issues, but there are no known severe problems with it. We would rather like to have this feature in than no progress at all in the text tool. Closing as FIXED. A new bug report should be opened to improve the usability. It should include a proposal of the user interaction which should be discussed on the gimp-developer list beforehand.
It will be very difficult to track this feature if this bug will be closed. This bug could be closed if and only if there will be ne bug, that will be opened about this feature. Please reopen this with NEED INFO or similar.
The feature is implemented, there is nothing left to track.
Sven, sorry. I was not able to guess it from your last comment. Will try to test this feature with 2.6. Keep up the good work