Help needed: label tool

[Pere Pujal i Carabantes-2]

Hi all!

This is a new attempt to merge gsoc2008 label whit tuxpaint.

It has been ported to a independent tool, instead of being a modifier
for the text tool.

As with a new tool, the button tools doesn´t fit in a 640x480 screen,
there is also code to add a scrollbar in the left.

It is merged to current cvs except the latest addition from Bill about
the default size for SVGs.

It is plenty of dirty code that I use(d) for debugging purposes, anyway
it seems working nearly right, so I put on the web to get some help and
feedback:
http://fornol.no-ip.org/linux/tuxpaint/dev/tuxpaint-label.tar.gz

Where is located the code that deals whit the animated popup dialogs?
  They currently start from were the button should be if there where not
scroll buttons.

What do you think about its current interface and how can it be
improved?

What can I do to improve its performance?  Currently it keeps in memory
all the  created SDL_Surfaces. Should it drop them and regenerate as
needed? Regenerating has a cost too. (It needs them when a user wants to
edit a text and he clicks where there are overlapping surfaces, then it
looks for the most upper one that has opacity at the point clicked)

Bugs and problems I don´t see?

Rotating text: I am not sure how it can be implemented, but there is a
free place at the side of the edit button that might be used for this.

Last but not least, I am open to receive some free programming lessons
if someone wants to read my code and comment on it :)

Thanks
Pere
--
Tired. Ready to take my hollidays after a very stressing summer.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sun, Oct 04, 2009 at 12:40:22AM +0200, Pere Pujal i Carabantes wrote:
> Hi all!
>
> This is a new attempt to merge gsoc2008 label whit tuxpaint.

Thanks!!!


> It has been ported to a independent tool, instead of being a modifier
> for the text tool.

Perfect, thanks.


> As with a new tool, the button tools doesn??t fit in a 640x480 screen,
> there is also code to add a scrollbar in the left.

I'll fix that, thanks.


> It is merged to current cvs except the latest addition from Bill about
> the default size for SVGs.

Great.  I can see about re-merging.

> It is plenty of dirty code that I use(d) for debugging purposes, anyway
> it seems working nearly right, so I put on the web to get some help and
> feedback:
> http://fornol.no-ip.org/linux/tuxpaint/dev/tuxpaint-label.tar.gz
>
> Where is located the code that deals whit the animated popup dialogs?
>   They currently start from were the button should be if there where not
> scroll buttons.
>
> What do you think about its current interface and how can it be
> improved?

It's ok so far.  I'm not sure I like how the 'Select' tool works.

I've also seen some bugs, but cannot immediately reproduce them:
  1. ability to select/move a label even when the 'select' button is disabled
  2. when editing an existing label (i changed the font size), I suddenly
     had two copies of the label (one in the original size)
  3. blitting issues (an old label would get 'whited out' when I tried
     typing an overlaqpping label... happened after #2)

Also, I'm unable to select the label I want if they overlap.
(They don't LOOK like they overlap, due to whitespace above characters,
and linespacing whitespace in the TTF.)  That will be quite frustrating.

> What can I do to improve its performance?  Currently it keeps in memory
> all the  created SDL_Surfaces. Should it drop them and regenerate as
> needed? Regenerating has a cost too. (It needs them when a user wants to
> edit a text and he clicks where there are overlapping surfaces, then it
> looks for the most upper one that has opacity at the point clicked)
>
> Bugs and problems I don??t see?
>
> Rotating text: I am not sure how it can be implemented, but there is a
> free place at the side of the edit button that might be used for this.
>
> Last but not least, I am open to receive some free programming lessons
> if someone wants to read my code and comment on it :)

I'll take a look and provide more comments if I think of any!
So far, though, I think I'm ready to add this to CVS.

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Sat, Oct 03, 2009 at 10:29:47PM -0700, Bill Kendrick wrote:
> Great.  I can see about re-merging.

It's in CVS.  I'm documenting what's in there so far, at the moment.

BTW, I noticed a bug regarding text entered using the Input Method feature.
If I go to edit a label, the text becomes corrupted.

Try this:

  * tuxpaint --lang japanese
  * Label tool, click somewhere on the canvas
  * Press [Right Alt] key to switch to the first Japanese IM
  * Type "abcdefg", you should see "#bc#fg", where "#" are japanese
    characters.  (You'll probably need to use a diff. font[*]
  * Hit [Enter] to place the label
  * Use the 'select' option of Label, click the label
  * The text is ok

Now:

  * Save the picture & quit
  * tuxpaint --lang japanese
  * Use the 'select' option of Label, click the label
  * The text is NOT ok

It looks like the label data (in ".labels/XYZ.dat" files) are being
saved as ASCII and not UTF-8.

(And the reason the text looks OK at FIRST is because you're seeing
the bitmapped version.  But once you edit it, the corrupted text is used
and the bitmap is re-rendered.)


[*] Hey!  I thought the font that's best for our locale should come first!
    Where are we at with this?  Maybe the Japanese PO needs updating?

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

Thinking out loud,

So my idea is to have two buttons, which are mutually exclusive.
They would be similar to the "Paint vs Full-image" buttons in Magic.

One would be to add a new label, the other would be to select one of
the existing labels.

Additionally, when the selection option is enabled, it would be good
if all of the current labels in the picture were to be outlined
(say, with black/yellow dashes), so that they're easy to spot in a
crowded picture.

I'm still unsure what the best thing to do is with regards to overlap. :(

Oh, and the selection option would be UNclickable if there are no
labels to select.


And that brings up a question.  If I hit [Backspace] a bunch of times
to delete text in the label, does the label go away?  Or do you end up
with a blank label?  (And if so, is there any way to click it!?)

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Pere Pujal i Carabantes-2]

El dg 04 de 10 de 2009 a les 00:34 -0700, en/na Bill Kendrick va
escriure:
> Thinking out loud,
>
> So my idea is to have two buttons, which are mutually exclusive.
> They would be similar to the "Paint vs Full-image" buttons in Magic.
>
> One would be to add a new label, the other would be to select one of
> the existing labels.

Looks more consistent whith the current interface.

>
> Additionally, when the selection option is enabled, it would be good
> if all of the current labels in the picture were to be outlined
> (say, with black/yellow dashes), so that they're easy to spot in a
> crowded picture.

This will help too with overlapping labels to allow select where they
don't overlap.

>
> I'm still unsure what the best thing to do is with regards to overlap. :(

function search_label_list()
Currently, when you are on select and click on the canvas, it preselects
the top label at the x/y position, then searchs down the labels for the
upper label thas has opacity at the x/y position and if any, returns it.
So you should click exactly on the "ink" of a letter if you want to
select a label that is not the top one.

Perhaps we can add code to look for closest opacity to x/y position.


> Oh, and the selection option would be UNclickable if there are no
> labels to select.

Good point.

>
>
> And that brings up a question.  If I hit [Backspace] a bunch of times
> to delete text in the label, does the label go away?

I had it this way for a time, then realized that one can't edit the
first letter withouth deleting a label and adding a new one.

>  Or do you end up
> with a blank label?  (And if so, is there any way to click it!?)

Currently seems broken. It should delete the label only when hitting
"return" or changing to a different tool after deleting all its text.
The intention was allow to continue editing after have removed the
initial letter.
A blank label should be avoided as it will save over sessions.
A "deleted" label is still here but has the field label_node->is_enabled
set to FALSE, then it can be recovered at undo/redo actions.


I will see if I can do something on some of theese.
Thanks
Pere


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Mon, Oct 05, 2009 at 12:09:42AM +0200, Pere Pujal i Carabantes wrote:
> > And that brings up a question.  If I hit [Backspace] a bunch of times
> > to delete text in the label, does the label go away?
>
> I had it this way for a time, then realized that one can't edit the
> first letter withouth deleting a label and adding a new one.

Oh, well I think it's fine to leave the _active_ label around and active,
so that you can type:

  "hello [backspace 5 times] world"

Instead of having to do:

  "hello [backspace 5 times] [w]"-- hey, where did my label go? :)


I'm suggesting NOT storing labels if they are empty (no text) and the user
hits [Enter] or [Tab] to 'complete' the label.


> Currently seems broken. It should delete the label only when hitting
> "return" or changing to a different tool after deleting all its text.
> The intention was allow to continue editing after have removed the
> initial letter.

Oops, I should have read further on. ;)  So we're in agreement.


> A blank label should be avoided as it will save over sessions.
> A "deleted" label is still here but has the field label_node->is_enabled
> set to FALSE, then it can be recovered at undo/redo actions.
>
> I will see if I can do something on some of theese.

Great, thanks!  You have CVS access, right?  Have at it!

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Pere Pujal i Carabantes-2]

El ds 03 de 10 de 2009 a les 23:29 -0700, en/na Bill Kendrick va
escriure:
> On Sat, Oct 03, 2009 at 10:29:47PM -0700, Bill Kendrick wrote:

> BTW, I noticed a bug regarding text entered using the Input Method feature.
> If I go to edit a label, the text becomes corrupted.
>
> Try this:
>
>   * tuxpaint --lang japanese
>   * Label tool, click somewhere on the canvas
>   * Press [Right Alt] key to switch to the first Japanese IM
>   * Type "abcdefg", you should see "#bc#fg", where "#" are japanese
>     characters.  (You'll probably need to use a diff. font[*]

Unable to write japanese chars. Is there any other trick to change to
Japanese IM?

Anyway, I've managed to reproduce the bug typing arabic chars, so a
first fix is in CVS. Can you try if it works for japanese IM too?


> It looks like the label data (in ".labels/XYZ.dat" files) are being
> saved as ASCII and not UTF-8.
>
Changed some %c to %lc and some char to wchar_t at save/load stages.
Seems to work, and to crash if opening any draw saved the old way.


> (And the reason the text looks OK at FIRST is because you're seeing
> the bitmapped version.  But once you edit it, the corrupted text is used
> and the bitmap is re-rendered.)

Yes, the bitmap is saved in the .dat file in order to get the most
approaching when sharing a draw to other computers that don't have the
same fonts.



pere


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Mon, Oct 05, 2009 at 11:23:21PM +0200, Pere Pujal i Carabantes wrote:
> Anyway, I've managed to reproduce the bug typing arabic chars, so a
> first fix is in CVS. Can you try if it works for japanese IM too?

Works, thanks! :)


However, I did notice a crash bug.  GDB shows that it's in "rec_undo_label()".

Here's what I do:

  1. Add a label to a drawing
  2. Click NEW, pick a color
  3. Change from the Label tool to the Paint tool
  4. Choose a color
  5. Try to paint... *crash!*

I guess it still thinks there's a label around, despite being a new drawing...?

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Mon, Oct 05, 2009 at 04:31:16PM -0700, Bill Kendrick wrote:
> However, I did notice a crash bug.  GDB shows that it's in "rec_undo_label()".

I changed this:

   if (have_to_rec_label_node)

to this:

   if (have_to_rec_label_node && current_label_node != NULL)

and it stopped crashing.


Now, I'm not sure that's the appropriate fix.  (i.e., is the bug elsewhere,
and crashing here was just an artifact of that bug.)

In any case, without having much time to play with it thoroughly, this
at least _helps!_

Thanks Pere!  Good luck!

-bill!

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Mon, Oct 05, 2009 at 11:23:21PM +0200, Pere Pujal i Carabantes wrote:
> Yes, the bitmap is saved in the .dat file in order to get the most
> approaching when sharing a draw to other computers that don't have the
> same fonts.

I saw that you just committed a change to remove an empty label when
hitting Print or a different Tool.  Of course, the first thing I tested
was hitting Save, which DOESN'T work. :)

Try this:

  * New image
  * Use label tool, type "This is my label", hit [Enter]
  * Save
  * Use label tool, select that label and hit [Backspace] to delete all of it
  * DO NOT HIT [ENTER] or click any other tool
  * Save again
  * "Save a new file"

Notice that both files have .label entries that are the same size.

Now quit and re-start Tux Paint.  When it re-loads the last picture,
it will have "This is my label" on it, even though it was deleted
(though apparently the deletion was not 'commited', since I didn't hit
[Enter] or [Tab]) when I had hit the 'Save' button the 2nd time. :)

Gotta run,

--
-bill!
Sent from my computer

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Pere Pujal i Carabantes-2]

El dt 06 de 10 de 2009 a les 15:05 -0700, en/na Bill Kendrick va
escriure:

> On Mon, Oct 05, 2009 at 11:23:21PM +0200, Pere Pujal i Carabantes wrote:
> > Yes, the bitmap is saved in the .dat file in order to get the most
> > approaching when sharing a draw to other computers that don't have the
> > same fonts.
>
> I saw that you just committed a change to remove an empty label when
> hitting Print or a different Tool.  Of course, the first thing I tested
> was hitting Save, which DOESN'T work. :)
>
> Try this:
>
>   * New image
>   * Use label tool, type "This is my label", hit [Enter]
>   * Save
>   * Use label tool, select that label and hit [Backspace] to delete all of it
>   * DO NOT HIT [ENTER] or click any other tool

So the editing is not commited and you click on save or type CTRL + S.
This has been there for a while in the text tool, I don't understand its
logic, but it is explicitely disabled to render the currently unfinished
edited text when saving.

            /* Render any current text, if switching to a different
               drawing tool: */

            if ((cur_tool == TOOL_TEXT && which != TOOL_TEXT &&
                which != TOOL_NEW && which != TOOL_OPEN &&
                which != TOOL_SAVE && which != TOOL_PRINT &&
                which != TOOL_QUIT) ||
               (cur_tool == TOOL_LABEL && which != TOOL_LABEL.....
[snip]
do_render_cur_text(1)

>   * Save again
>   * "Save a new file"
>
> Notice that both files have .label entries that are the same size.
>
> Now quit and re-start Tux Paint.  When it re-loads the last picture,
> it will have "This is my label" on it, even though it was deleted
> (though apparently the deletion was not 'commited', since I didn't hit
> [Enter] or [Tab]) when I had hit the 'Save' button the 2nd time. :)
>
> Gotta run,
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Bill Kendrick]

On Wed, Oct 07, 2009 at 12:45:40AM +0200, Pere Pujal i Carabantes wrote:
> So the editing is not commited and you click on save or type CTRL + S.
> This has been there for a while in the text tool, I don't understand its
> logic, but it is explicitely disabled to render the currently unfinished
> edited text when saving.

Hrm that's a bug.  I think it's similar to one we fixed a while back
regarding printing.  Kids would type some text, then hit [Print], but
their text would not be on the printout.  Turns out it hadn't been
applied to the drawing yet!  (That was fixed in 0.9.18; see CHANGES.txt)

And, obviously, I think Label should do the same.  If I add a label,
but forget to hit [Enter] or [Tab], and then I hit "Save" or [Ctrl+S],
the label should be saved.  And if I hit "Print" or [Ctrl+P], the label
should appear on my printout. :)

Now, the hack I did for Printing causes the text entry to end.
(And it appears that the insertion cursor ends up at the beginning of
the text that had been entered.)  It's not ideal, but better than
a bogus print, or losing data when you save and then quit.

  |            [type "hello"]
   hello|      [press Ctrl+P]
  |hello       [cursor in a weird place, and I cannot edit[*]]

where "|" is the blinking insertion pointer.

[*] I'm not SUPER worried about not being able to edit, esp. with the Text
tool.  Once you change tools, text gets applied.  Should be the same with
printing or saving.

I'm rambling, sorry :)  Thanks!

--
-bill!
Sent from my computer

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Pere Pujal i Carabantes-2]

El dt 06 de 10 de 2009 a les 18:06 -0700, en/na Bill Kendrick va
escriure:

> On Wed, Oct 07, 2009 at 12:45:40AM +0200, Pere Pujal i Carabantes wrote:
> > So the editing is not commited and you click on save or type CTRL + S.
> > This has been there for a while in the text tool, I don't understand its
> > logic, but it is explicitely disabled to render the currently unfinished
> > edited text when saving.
>
> Hrm that's a bug.  I think it's similar to one we fixed a while back
> regarding printing.  Kids would type some text, then hit [Print], but
> their text would not be on the printout.  Turns out it hadn't been
> applied to the drawing yet!  (That was fixed in 0.9.18; see CHANGES.txt)
>
> And, obviously, I think Label should do the same.  If I add a label,
> but forget to hit [Enter] or [Tab], and then I hit "Save" or [Ctrl+S],
> the label should be saved.  And if I hit "Print" or [Ctrl+P], the label
> should appear on my printout. :)
>
> Now, the hack I did for Printing causes the text entry to end.
> (And it appears that the insertion cursor ends up at the beginning of
> the text that had been entered.)  It's not ideal, but better than
> a bogus print, or losing data when you save and then quit.
>
>   |            [type "hello"]
>    hello|      [press Ctrl+P]
>   |hello       [cursor in a weird place, and I cannot edit[*]]
>
> where "|" is the blinking insertion pointer.
>
> [*] I'm not SUPER worried about not being able to edit, esp. with the Text
> tool.  Once you change tools, text gets applied.  Should be the same with
> printing or saving.
>

I will not have time to check carefully for side issues, but commenting
out the lines 2360 2361 seems to fix the blinking pointer for CTRL+P, of
course you have to find the corresponding lines for click on print. I
currently don't have the time.

Also copying/adapting the block of code where thoose lines leave to the
corresponding place at the saving code should fix the losing of data
when saving and quitting.


Going on hollidays NOW :)
See you at the end of next week.
Pere


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Tuxpaint-devel mailing list
Tuxpaint-devel@...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel