changing the shape of a text layer
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| changing the shape of a text layer | saulgoode@flashingtwelve.brickfilms.com | 01 Dec 21:48 |
| changing the shape of a text layer | Joao S. O. Bueno | 02 Dec 15:03 |
| changing the shape of a text layer | peter sikking | 06 Dec 14:10 |
| changing the shape of a text layer | Tobias Jakobs | 06 Dec 17:42 |
| changing the shape of a text layer | peter sikking | 06 Dec 19:42 |
| changing the shape of a text layer | Sven Neumann | 06 Dec 23:23 |
| changing the shape of a text layer | Sven Neumann | 06 Dec 19:18 |
| changing the shape of a text layer | Sven Neumann | 07 Dec 08:36 |
| changing the shape of a text layer | Sven Neumann | 07 Dec 21:33 |
changing the shape of a text layer
I like the idea of having this functionality available. I have tried the patch and it seems very capable. There appears to be bug which presented itself when I did the following:
Create a "blue" text layer.
Create a "red" text layer positioned above the blue layer.
Resize the red text layer.
Activate the blue layer.
OR
Create a "blue" text layer.
Create a "red" text layer positioned above the blue layer.
Resize the blue layer.
Activate the red layer.
Activate the blue layer.
In both cases, the top-left of the blue layer's rectangle frame gets set to the bottom-right of the red layer's resized frame. This change does not occur unless one of the layers is resized.
--------
As a general comment, I would point out that this interface might present a problem in the future when "in-place" text editing is implemented. Since the primary function of the tool is text input, perhaps it would be better to require a modal key (ALT?) when adjusting the frame so that, in the future, unmodified mouse clicks could be used to specify cursor location and text selections.
I've been working on using the new "rectangle tool" interface to allow changing the shape of a text layer by moving edges around. (Sven set up the infrastructure for this years ago, but it has lacked a UI.) I have attached a patch with a trial implementation to the relevant enhancement request in Bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=122707 Sven suggests, and I agree, that it would be good to have input from the UI team before making changes to SVN trunk, hence this email. Here is a summary of how the trial implementation handles things:1) If the user clicks on an existing text layer, and no rectangle
yet exists there, we create a rectangle to frame the layer, 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 active layer is not a text layer, or if it is but the user has clicked outside it, and the rectangle that has been swept out is too small, we want to use dynamic text, so we halt the rectangle interface. 4) Otherwise, we use the new rectangle that the user has swept out as our text box, keeping the rectangle interface alive so that the user can modify it.
The rectangle interface is exactly identical to the one in the rectangle select tool, except that I have tentatively assumed that modifier keys aren't going to come into play. However, everything should be considered open to change right now. So, I am hoping to get some feedback from the UI team about this stuff.
If you want to experiment with the trial implementation, you can find an updated patch in the above-mentioned bug report. To the best of my knowledge, everything works as intended except Undo, which is a bit glitchy. Â
changing the shape of a text layer
On Sunday 02 December 2007 01:29:39 am William Skaggs wrote:
From:
I like the idea of having this functionality available. I have tried the patch and it seems very capable. There appears to be bug which presented itself when I did the following: ...
Thanks for the "bug report". I'll take a look at it.> As a general comment, I would point out that this interface might present
a problem in the future when "in-place" text editing is implemented. Since the primary function of the tool is text input, perhaps it would be better to require a modal key (ALT?) when adjusting the frame so that, in the future, unmodified mouse clicks could be used to specify cursor location and text selections.
I hadn't thought about this, but it seems to me that it would be simpler to distinguish between clicking (used in in-place editing) and click-and-drag (used for modifying shape).
I actually dislike the idea of having "clicking modes" - We might have "clicking locations" - ike, clicking in the handlers always do resize, and just draw the handlers so that no text falls inside them.
Certain programs that do use the "two modes" for editing and dragging the text container are an absolute PITA to use exactly due to this. (OOo anyone?)
js
->
But
in general I am absolutely delighted to leave that sort of question to the wisdom of Peter and his cohorts. -- Bill
changing the shape of a text layer
William Skaggs wrote:
I've been working on using the new "rectangle tool" interface to allow changing the shape of a text layer by moving edges around.
Sven suggests, and I agree, that it would be good to have input from the UI team before making changes to SVN trunk, hence this email.
When 2.4 came out, I made a statement that that day was also the end of fire brigade mode for the UI team. So can we do this in the right order please:
1) we decide that this issue is worth our limited resources and has higher precedence than other issues (that will remain unsolved); 2) we therefore put it on the road map, stating what we will tackle, leaving out the ambitious stuff; 3) UI team creates a UI solution and writes spec; meanwhile a technical proof of concept (feasibility) can be lashed up; 4) real code gets written and tested; 5) user manual gets updated.
So right now for this issue only the second part of point 3 (the lash-up) has been done. I am not sure this issue will pass point 1, at this moment.
One of the biggest crimes in user interaction is to let a piece of existing code inform the shape of new interaction solutions.
--ps
founder + principal interaction architect man + machine interface works
http://mmiworks.net/blog : on interaction architecture
changing the shape of a text layer
Hello!
On Dec 6, 2007 2:10 PM, peter sikking wrote:
When 2.4 came out, I made a statement that that day was also the end of fire brigade mode for the UI team. So can we do this in the right order please:
That is only fair and I think the results will be better this way.
1) we decide that this issue is worth our limited resources and has higher precedence than other issues (that will remain unsolved);
Who do you mean with "our limited resources", the UI team, the programmers or the complete team?
2) we therefore put it on the road map, stating what we will tackle, leaving out the ambitious stuff;
Do we/you have a list with the impotents of the different issues? Can we use the road map for this or do we need a second list?
3) UI team creates a UI solution and writes spec; meanwhile a technical proof of concept (feasibility) can be lashed up; 4) real code gets written and tested; 5) user manual gets updated.
So right now for this issue only the second part of point 3 (the lash-up) has been done. I am not sure this issue will pass point 1, at this moment.
And now my question to the list is, what should we do with code,
that doesn't pass point one but is already written (like here) and
improves Gimp?
Of cause this question only affects tools or functions, where we
don't have any UI specs.
Regards, Tobias
changing the shape of a text layer
Hi,
On Thu, 2007-12-06 at 14:10 +0100, peter sikking wrote:
So right now for this issue only the second part of point 3 (the lash-up) has been done. I am not sure this issue will pass point 1, at this moment.
IMO it is definitely worth our limited resources. This has been on the roadmap for five years or longer and most of the code is already written. Bill's patch only connects the loose ends.
It would be very nice if we could get some input from the UI team on this soon so that Bill can continue to work on this.
Sven
changing the shape of a text layer
Tobias Jakobs wrote:
On Dec 6, 2007 2:10 PM, peter sikking wrote:
When 2.4 came out, I made a statement that that day was also the end of fire brigade mode for the UI team. So can we do this in the right order please:
That is only fair and I think the results will be better this way.
1) we decide that this issue is worth our limited resources and has higher precedence than other issues (that will remain unsolved);
Who do you mean with "our limited resources", the UI team, the programmers or the complete team?
All involved in development: UI team, developers, documenters.
2) we therefore put it on the road map, stating what we will tackle, leaving out the ambitious stuff;
Do we/you have a list with the impotents of the different issues?
I think that is a consensus thing. Also everything is connected with the phased introduction of GEGL, which we have seen recently makes working on some urgent issues a waste of time, because a lot of code will be scrapped.
And yes, I understand and support that 2.6 is going to be 'light' on UI changes, to get the phase-one GEGL work done.
Can we use the road map for this or do we need a second list?
Let's see: a roadmap is new for GIMP, as is a structural UI renovation project, as is a new engine. We need to get experienced with this and better integration of all big ideas out there.
From my side I need to contribute by doing the analysis part of our UI process and make that accessible as blog entries (a GIMP issue a day?).
I am really looking forward to a roadmap...
--ps
founder + principal interaction architect man + machine interface works
http://mmiworks.net/blog : on interaction architecture
changing the shape of a text layer
Hi,
On Thu, 2007-12-06 at 19:42 +0100, peter sikking wrote:
I think that is a consensus thing. Also everything is connected with the phased introduction of GEGL, which we have seen recently makes working on some urgent issues a waste of time, because a lot of code will be scrapped.
Uh, oh, not that fast. The issue that was brought up (the Color layer mode) isn't that urgent. We haven't even decided if it should be considered a bug and how to tackle it.
And yes, I understand and support that 2.6 is going to be 'light' on UI changes, to get the phase-one GEGL work done.
The plan, at least as far as I see it, is to release GIMP 2.6 in a few months. With whatever changes we manage to do until then. I don't really want to stop people to work on issues that are important and that they want to hack on. A roadmap is a great thing to show people what we consider important, but I don't see it as something that we absolutely have to stick to. As long as features have been discussed here beforehand, they can be added. If they are on the roadmap or not doesn't matter too much.
That said, we should really get the roadmap done and published...
Sven
changing the shape of a text layer
Hi,
On Thu, 2007-12-06 at 23:28 +0000, William Skaggs wrote:
In particular, I would be happy to work on the menu restructuring if you and Sven can agree to go ahead and make specific changes, and if Sven is comfortable with that.
I have no idea what menu restructuring you are talking about and I would strongly suggest that we don't do major menu changes for 2.6. The documenters will only just have caught up when 2.6 is supposed to be released.
Or is this just about merging the toolbox and image window menus?
Sven
changing the shape of a text layer
Hi,
On Fri, 2007-12-07 at 19:13 +0000, William Skaggs wrote:
Yes, that's what I meant. From a user's point of view, that's a pretty major restructuring.
But that code is all in SVN already. Just pass --disable-toolbox-menu to configure. Note that you need to do a full rebuild and a fresh install to make sure that the menu files are correctly updated.
The part that is not yet done is to have an image window that always exists. This depends a lot on the specification of the UI team so it probably doesn't make sense to work on that until that spec is done.
Sven
