WYSIWYG space and CR in user-defined description for GrowlTunes

[GoogleCodeExporter]

Currently the description field in the preferences could be a bit more WYSIWYG.
As an example, currently, there seems to be extra spaces added in the 
notification display to surround the selected tags for description, whereas 
they are not present in the user-defined description area.

What steps will reproduce the problem?
1. add PlayTime tag to the description field
2. enter ( and ) around the tag, without any spaces
3. view the resulting notification

What is the expected output?
(PlayTime)

What do you see instead?
( PlayTime ) => there are two more spaces surround the play time.

Please provide any additional information below.

I guess that those additional spaces are forced to be sure to get spaces when 
the user add several tags. But it's not totally clear for the user building his 
preferred description field.

Same not very clear handling are for the carriage returns:
there seems to be a carriage return added when displaying certain tags in the 
notifications, but they don't appear in the description field, so there is no 
visual difference in the description field between tags separated by a simple 
space, and tags separated by a carriage return in the displayed notification.

I suggest a smarter handling (quite WYSIWYG):

1- don't add any extra space from the preference setting to the notification 
display.
=> automatic addition of extra spaces to separate tags in the definition field 
is a good idea: it should simply be really added, as a real and visible space 
character, in the description field when the user adds one more tag just after 
another tag.

2- the carriage return should also be explicit: either a special visible 
character, or a real visible carriage return in the lines of the description 
field.

Original issue reported on code.google.com by yann.ric...@gmail.com on 22 Jun 2013 at 9:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

So you're saying that there is space added around the different tokens and you 
don't want the space? That's the main issue here, and then you came up with a 
solution?

Original comment by ch...@growl.info on 23 Jun 2013 at 6:22

[GoogleCodeExporter]

No I don't say that, I say that it would be better if ALL the characters 
displayed in the notifications would come from what you see in the description 
setting field.
Then it concerns both spaces and CR (and maybe other characters I didn't remark 
for now) that are not clearly visible in the user field, but can exist in the 
resulting display.

For the solution, I proposed one that works if implemented, just read my 
proposal.

Point #1 give a solution to avoid spaces currently added in the notification 
display.
=> don't automatically add any spaces most of the time. And add it ONLY when 
the user adds a tag just after another existing tag without character already 
existing between the two tags
(in other words, add this forced separator only if needed, and if you add it, 
add it really in the input field and not only during the notification display)

Point #2 addresses, same way, a solution to understand when CR will happen in 
the resulting notification. Currently, when launching GrowlTunes you have CR in 
the default music notification. If you edit and add tags, you can loose those 
CR, without any way to rewrite them. My proposal is the make those CR also 
visible (and then editable) in the input field.

That's why I called it a sort of WYSIWYG.

Original comment by yann.ric...@gmail.com on 23 Jun 2013 at 6:43

[GoogleCodeExporter]

My mistake for #2: the CR (that I thought resulting from the CR present in the 
default description setting for Music notifications) were just a chance of 
word-wrapping with my notification style...

Then it's even worse concerning the "not WYSIWYG" carriage-returns:
- the default description setting is
(Album Artist or Artist)
(Album)
(Play Time)

- and it has no difference with
(Album Artist or Artist)(Album)(Play Time)

Really, to make sense for the user, the description field layout should be 
closer to the visual display: if CR is in the setting, then CR is in the 
notification.

Original comment by yann.ric...@gmail.com on 23 Jun 2013 at 8:32

[GoogleCodeExporter]

So, turns out there was in fact a bug here with regards to spaces, we were 
separating components by spaces by mistake.  Resolved in [3c593b9b6dee]

As for new lines, token fields behave a bit weird.  A simple press of the 
return key results in the system trying to tokenize the strings that have been 
entered.  Ctrl-return results in a new line being added to that string, both 
visually and that we store in our tokens for use.  This is default system 
behavior, and while it might be able to be changed, we wont be.  And even if 
fields that aren't growing height wise properly, the new lines from a 
ctrl-return are there, just wasn't enough height to show them (On 
retokenization in the source, this should grow height properly at least on 
10.8).

Closing as fixed in source.

Original comment by dan...@growl.info on 25 Jun 2013 at 3:49

• Changed state: FixedInSource
• Added labels: Milestone-2.2, Product-GrowlTunes

[GoogleCodeExporter]

Great!

Original comment by yann.ric...@gmail.com on 25 Jun 2013 at 6:57