[sip-comm-dev] Re: JOrtho for Spell Checker?


#1

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin but
it's looking like it's gonna take a couple days. Before I dig in any further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If not,
I'll begin making the changes against the trunk so there's a fresh patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're already there. In my opinion there are still some issues to resolve in order to make the existing implementation more stable, before going with adding a new implementation.

I was playing with the spellchecker today and I find it great!! Really well done with the configuration form and all dictionaries. However I have encountered a problem when I tried to delete what I have typed. Just press backspace and you'll see the following exception : java.lang.IllegalArgumentException: offset out of bounds. If you don't experience the same problem, I'll have a look and will give you more information on the exception.

The "Add word" functionality is awesome! And you could even add words through the configuration form, which is great. I was just wondering if we really need to manage the personal dictionary in a different window. The spell check configuration form contains only a combobox, so we have enough space to add directly there the table with added words. In the bottom we could add the text field and the "Add to dictionary" button. In this configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I think that it could be a good idea to allow users to see what dictionaries they have installed, to update or remove dictionaries. At this moment when you select a dictionary in the configuration form it's downloaded in the home directory, but we could neither update it, nor remove it or may be I have missed it. I was also looking at the parameters.xml you use to store configuration parameters, does this xml do something special or we could use instead the ConfigurationService?

Some other things we should think of is allow user to change the dictionary while typing and also allow user to disable/enable the spellchecking while typing. Like for example in any text area in Firefox you have "Spell checking" and "Languages" items in the right button menu. You could even add a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:
Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we have left more space for the configuration forms, but we could think of returning it, we're playing a lot with the gui these days and try to find more user friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality is
added. Are there any plans to come up with an alternative means of listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting (bold,
italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols which does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev mailing list, so that we could continue discussing the spellchecker there. You could even send some screenshots, so that the others get an idea of what we're talking about :wink:

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Yana. I just committed a revision with the following changes:
- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some locales,
allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian (Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

However, the bug you mentioned is eluding me. I'm not surprised you got that
exception- it's caused by the DocUnderliner, which was the trickiest part
and took a couple weeks to flush out all the little off-by-one errors that
caused IllegalArgumentExceptions. Could you please provide the step-by-step
use case to reproduce it? I tried just opening a chat and hitting the
backspace but no luck...

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

···

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva <yana@sip-communicator.org>wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If
not,
I'll begin making the changes against the trunk so there's a fresh patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're already
there. In my opinion there are still some issues to resolve in order to make
the existing implementation more stable, before going with adding a new
implementation.

I was playing with the spellchecker today and I find it great!! Really well
done with the configuration form and all dictionaries. However I have
encountered a problem when I tried to delete what I have typed. Just press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering if we
really need to manage the personal dictionary in a different window. The
spell check configuration form contains only a combobox, so we have enough
space to add directly there the table with added words. In the bottom we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I
think that it could be a good idea to allow users to see what dictionaries
they have installed, to update or remove dictionaries. At this moment when
you select a dictionary in the configuration form it's downloaded in the
home directory, but we could neither update it, nor remove it or may be I
have missed it. I was also looking at the parameters.xml you use to store
configuration parameters, does this xml do something special or we could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the dictionary
while typing and also allow user to disable/enable the spellchecking while
typing. Like for example in any text area in Firefox you have "Spell
checking" and "Languages" items in the right button menu. You could even add
a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:
Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we have
left more space for the configuration forms, but we could think of returning
it, we're playing a lot with the gui these days and try to find more user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality is

added. Are there any plans to come up with an alternative means of listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting (bold,

italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev
mailing list, so that we could continue discussing the spellchecker there.
You could even send some screenshots, so that the others get an idea of what
we're talking about :wink:


#3

Hi Yana. The spell checker's been applied against the trunk. I thought it'd
be done tonight but I've ran into a couple of rather nasty, unexpected
issues:

1. The chat panel now composes messages as html which is throwing off the
indices. For instance with the basic text "hello world" getMessage()
returns:
<html>
  <head>

  </head>
  <body>
    <p style="margin-top: 0">
      hello world
    </p>
  </body>
</html>

We discussed using html to underline text a while back but I decided against
it since it's unnecessary for formatting, tends to hurt performance and
since I was concerned about this issue. With a bit of work I think I'll be
able to come up with a hack to get the plain text message but between tag
detection, escape characters (such as '&amp;') and stripped white space
it'll probably be far from trivial (and really hurt the spell checker's
look-up time). Why is it being used now and do you have any suggestions for
how to tackle this?

2. Evidently you modified the ResourceManagementService on Sunday removing
the getCurrentSettings() method. I was using this to access
defaults.properties- is there another means of getting all the defaults?
Without it the Keybindings patch won't be able to be applied either...

I hope these issues (especially the first) won't be as problematic as I
think... -Damian

···

On Wed, Aug 6, 2008 at 10:25 PM, Damian Johnson <atagar1@gmail.com> wrote:

Hi Yana. I just committed a revision with the following changes:
- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some
locales, allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian (Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

However, the bug you mentioned is eluding me. I'm not surprised you got
that exception- it's caused by the DocUnderliner, which was the trickiest
part and took a couple weeks to flush out all the little off-by-one errors
that caused IllegalArgumentExceptions. Could you please provide the
step-by-step use case to reproduce it? I tried just opening a chat and
hitting the backspace but no luck...

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva <yana@sip-communicator.org > > wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If
not,
I'll begin making the changes against the trunk so there's a fresh patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're already
there. In my opinion there are still some issues to resolve in order to make
the existing implementation more stable, before going with adding a new
implementation.

I was playing with the spellchecker today and I find it great!! Really
well done with the configuration form and all dictionaries. However I have
encountered a problem when I tried to delete what I have typed. Just press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering if we
really need to manage the personal dictionary in a different window. The
spell check configuration form contains only a combobox, so we have enough
space to add directly there the table with added words. In the bottom we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I
think that it could be a good idea to allow users to see what dictionaries
they have installed, to update or remove dictionaries. At this moment when
you select a dictionary in the configuration form it's downloaded in the
home directory, but we could neither update it, nor remove it or may be I
have missed it. I was also looking at the parameters.xml you use to store
configuration parameters, does this xml do something special or we could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the
dictionary while typing and also allow user to disable/enable the
spellchecking while typing. Like for example in any text area in Firefox you
have "Spell checking" and "Languages" items in the right button menu. You
could even add a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:
Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we have
left more space for the configuration forms, but we could think of returning
it, we're playing a lot with the gui these days and try to find more user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality is

added. Are there any plans to come up with an alternative means of
listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting (bold,

italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev
mailing list, so that we could continue discussing the spellchecker there.
You could even send some screenshots, so that the others get an idea of what
we're talking about :wink:


#4

Hi Damian,

Damian Johnson wrote:

Hi Yana. I just committed a revision with the following changes:
- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some locales,
allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian (Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

Great news!

I have tried the new version and it looks good. I'm just wondering if it's not a better idea to remove the language selection box from the toolbar and put a menu item in the right button menu in the chat "write area". I think it would fit better there.

However, the bug you mentioned is eluding me. I'm not surprised you got that
exception- it's caused by the DocUnderliner, which was the trickiest part
and took a couple weeks to flush out all the little off-by-one errors that
caused IllegalArgumentExceptions. Could you please provide the step-by-step
use case to reproduce it? I tried just opening a chat and hitting the
backspace but no luck...

It happens quite often, but you should try to type some words and then press (continuously!) the backspace button. If it doesn't happen from the first time try to type again. The exception I get is the following:

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: offset out of bounds
      [java] at java.text.RuleBasedBreakIterator.checkOffset(RuleBasedBreakIterator.java:724)
      [java] at java.text.RuleBasedBreakIterator.following(RuleBasedBreakIterator.java:737)
      [java] at net.java.sip.communicator.plugin.spellchecker.Word.getWord(Word.java:45)
      [java] at net.java.sip.communicator.plugin.spellchecker.DocUnderliner.removeUpdate(DocUnderliner.java:276)
      [java] at javax.swing.text.AbstractDocument.fireRemoveUpdate(AbstractDocument.java:242)
      [java] at javax.swing.text.AbstractDocument.handleRemove(AbstractDocument.java:607)
      [java] at javax.swing.text.AbstractDocument.remove(AbstractDocument.java:575)
      [java] at javax.swing.text.DefaultEditorKit$DeletePrevCharAction.actionPerformed(DefaultEditorKit.java:1030)
      [java] at javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1576)
      [java] at javax.swing.JComponent.processKeyBinding(JComponent.java:2772)
      [java] at javax.swing.JComponent.processKeyBindings(JComponent.java:2807)
      [java] at javax.swing.JComponent.processKeyEvent(JComponent.java:2735)
      [java] at java.awt.Component.processEvent(Component.java:5379)
      [java] at java.awt.Container.processEvent(Container.java:2010)
      [java] at java.awt.Component.dispatchEventImpl(Component.java:4068)
      [java] at java.awt.Container.dispatchEventImpl(Container.java:2068)
      [java] at java.awt.Component.dispatchEvent(Component.java:3903)
      [java] at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1826)
      [java] at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:681)
      [java] at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:938)
      [java] at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:810)
      [java] at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:645)
      [java] at java.awt.Component.dispatchEventImpl(Component.java:3941)
      [java] at java.awt.Container.dispatchEventImpl(Container.java:2068)
      [java] at java.awt.Window.dispatchEventImpl(Window.java:1791)
      [java] at java.awt.Component.dispatchEvent(Component.java:3903)
      [java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
      [java] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
      [java] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
      [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
      [java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
      [java] at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Cheers,
Yana

···

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva > <yana@sip-communicator.org>wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If
not,
I'll begin making the changes against the trunk so there's a fresh patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're already
there. In my opinion there are still some issues to resolve in order to make
the existing implementation more stable, before going with adding a new
implementation.

I was playing with the spellchecker today and I find it great!! Really well
done with the configuration form and all dictionaries. However I have
encountered a problem when I tried to delete what I have typed. Just press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering if we
really need to manage the personal dictionary in a different window. The
spell check configuration form contains only a combobox, so we have enough
space to add directly there the table with added words. In the bottom we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I
think that it could be a good idea to allow users to see what dictionaries
they have installed, to update or remove dictionaries. At this moment when
you select a dictionary in the configuration form it's downloaded in the
home directory, but we could neither update it, nor remove it or may be I
have missed it. I was also looking at the parameters.xml you use to store
configuration parameters, does this xml do something special or we could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the dictionary
while typing and also allow user to disable/enable the spellchecking while
typing. Like for example in any text area in Firefox you have "Spell
checking" and "Languages" items in the right button menu. You could even add
a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:
Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we have
left more space for the configuration forms, but we could think of returning
it, we're playing a lot with the gui these days and try to find more user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality is

added. Are there any plans to come up with an alternative means of listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting (bold,

italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev
mailing list, so that we could continue discussing the spellchecker there.
You could even send some screenshots, so that the others get an idea of what
we're talking about :wink:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Damian,

Damian Johnson wrote:

Hi Yana. The spell checker's been applied against the trunk. I thought it'd
be done tonight but I've ran into a couple of rather nasty, unexpected
issues:

1. The chat panel now composes messages as html which is throwing off the
indices. For instance with the basic text "hello world" getMessage()
returns:
<html>
  <head>

  </head>
  <body>
    <p style="margin-top: 0">
      hello world
    </p>
  </body>
</html>

We discussed using html to underline text a while back but I decided against
it since it's unnecessary for formatting, tends to hurt performance and
since I was concerned about this issue. With a bit of work I think I'll be
able to come up with a hack to get the plain text message but between tag
detection, escape characters (such as '&amp;') and stripped white space
it'll probably be far from trivial (and really hurt the spell checker's
look-up time). Why is it being used now and do you have any suggestions for
how to tackle this?

Text formatting is a feature most of the IM clients have, so this is something we absolutely want to have. I personally prefer that we think of a clear solution for this problem and not a hack. There already exist a method, which returns the clear text without any html tags: ChatPanel.getTextFromWriteArea(String mimeType). Could you explain us more about how you make the underlying right now and we could think of merging the two functionalities?

2. Evidently you modified the ResourceManagementService on Sunday removing
the getCurrentSettings() method. I was using this to access
defaults.properties- is there another means of getting all the defaults?
Without it the Keybindings patch won't be able to be applied either...

Is it possible for you to use the getSettingString method instead? getCurrentSettings was returning all setting properties and you normally need only the spellcheck ones.

Cheers,
Yana

···

I hope these issues (especially the first) won't be as problematic as I
think... -Damian

On Wed, Aug 6, 2008 at 10:25 PM, Damian Johnson <atagar1@gmail.com> wrote:

Hi Yana. I just committed a revision with the following changes:
- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some
locales, allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian (Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

However, the bug you mentioned is eluding me. I'm not surprised you got
that exception- it's caused by the DocUnderliner, which was the trickiest
part and took a couple weeks to flush out all the little off-by-one errors
that caused IllegalArgumentExceptions. Could you please provide the
step-by-step use case to reproduce it? I tried just opening a chat and
hitting the backspace but no luck...

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva <yana@sip-communicator.org >>> wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If
not,
I'll begin making the changes against the trunk so there's a fresh patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're already
there. In my opinion there are still some issues to resolve in order to make
the existing implementation more stable, before going with adding a new
implementation.

I was playing with the spellchecker today and I find it great!! Really
well done with the configuration form and all dictionaries. However I have
encountered a problem when I tried to delete what I have typed. Just press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering if we
really need to manage the personal dictionary in a different window. The
spell check configuration form contains only a combobox, so we have enough
space to add directly there the table with added words. In the bottom we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I
think that it could be a good idea to allow users to see what dictionaries
they have installed, to update or remove dictionaries. At this moment when
you select a dictionary in the configuration form it's downloaded in the
home directory, but we could neither update it, nor remove it or may be I
have missed it. I was also looking at the parameters.xml you use to store
configuration parameters, does this xml do something special or we could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the
dictionary while typing and also allow user to disable/enable the
spellchecking while typing. Like for example in any text area in Firefox you
have "Spell checking" and "Languages" items in the right button menu. You
could even add a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:
Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we have
left more space for the configuration forms, but we could think of returning
it, we're playing a lot with the gui these days and try to find more user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality is

added. Are there any plans to come up with an alternative means of
listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting (bold,

italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev
mailing list, so that we could continue discussing the spellchecker there.
You could even send some screenshots, so that the others get an idea of what
we're talking about :wink:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Yana. Thanks for the reply! With those hints I've finished integrating
the spellchecker into the trunk.

I'm just wondering if it's not a better idea to remove the language

selection box from the toolbar and put a menu item in the right button menu
in the chat "write area".

With over seventy locales this would be far too large a list for a
right-click menu.

It happens quite often, but you should try to type some words and then press

(continuously!) the backspace button. If it doesn't happen from the first
time try to type again.

I've tried a few times under all the conditions I could think of but haven't
been able to reproduce this issue. The stack trace you provided says the
problem was when deleting a character at the start of the document or in
front of a non-letter. Is there a particular series of keystrokes on which
the error always manifests? Does it seem like a timing (concurrency) issue
to you? Unfortunately I'm at a loss for how to tackle this...

The one feature I didn't implement was a means of managing dictionaries
(updating and removing). After I started working on it I found that imposing
a dictionary versioning scheme so the plugin would understand that version
1.0 came from source X and 1.1 came from source Y really violates the KISS
principle. Currently we can simply update dictionaries by defining
dictionary URLs with different filenames (the plugin will figure out that
you don't have the necessary resources, then go out and get it). As for
dictionary removal, the best solution I've figured would be to assume
everything in '.sip-communicator/spellingDictionaries' is a dictionary and
provide a little dialog that allows those files to be deleted. However, on
average dictionaries are small (around 200kb) so I'm not really sure if this
would be a worthwhile addition...

If this patch is committed then I'll revise the keybindings patch to
retrieve defaults by the same means. Cheers! -Damian

spellchecker.patch (246 KB)

spellcheckerBinaries.tar (530 KB)

···

On Sun, Aug 10, 2008 at 10:51 PM, Yana Stamcheva <yana@sip-communicator.org>wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. The spell checker's been applied against the trunk. I thought
it'd
be done tonight but I've ran into a couple of rather nasty, unexpected
issues:

1. The chat panel now composes messages as html which is throwing off the
indices. For instance with the basic text "hello world" getMessage()
returns:
<html>
<head>

</head>
<body>
   <p style="margin-top: 0">
     hello world
   </p>
</body>
</html>

We discussed using html to underline text a while back but I decided
against
it since it's unnecessary for formatting, tends to hurt performance and
since I was concerned about this issue. With a bit of work I think I'll be
able to come up with a hack to get the plain text message but between tag
detection, escape characters (such as '&amp;') and stripped white space
it'll probably be far from trivial (and really hurt the spell checker's
look-up time). Why is it being used now and do you have any suggestions
for
how to tackle this?

Text formatting is a feature most of the IM clients have, so this is
something we absolutely want to have. I personally prefer that we think of a
clear solution for this problem and not a hack. There already exist a
method, which returns the clear text without any html tags:
ChatPanel.getTextFromWriteArea(String mimeType). Could you explain us more
about how you make the underlying right now and we could think of merging
the two functionalities?

2. Evidently you modified the ResourceManagementService on Sunday removing
the getCurrentSettings() method. I was using this to access
defaults.properties- is there another means of getting all the defaults?
Without it the Keybindings patch won't be able to be applied either...

Is it possible for you to use the getSettingString method instead?
getCurrentSettings was returning all setting properties and you normally
need only the spellcheck ones.

Cheers,
Yana

I hope these issues (especially the first) won't be as problematic as I
think... -Damian

On Wed, Aug 6, 2008 at 10:25 PM, Damian Johnson <atagar1@gmail.com> >> wrote:

Hi Yana. I just committed a revision with the following changes:

- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some
locales, allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian
(Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

However, the bug you mentioned is eluding me. I'm not surprised you got
that exception- it's caused by the DocUnderliner, which was the
trickiest
part and took a couple weeks to flush out all the little off-by-one
errors
that caused IllegalArgumentExceptions. Could you please provide the
step-by-step use case to reproduce it? I tried just opening a chat and
hitting the backspace but no luck...

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva < >>> yana@sip-communicator.org >>> >>>> wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin

but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If
not,
I'll begin making the changes against the trunk so there's a fresh
patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're

already
there. In my opinion there are still some issues to resolve in order to
make
the existing implementation more stable, before going with adding a new
implementation.

I was playing with the spellchecker today and I find it great!! Really
well done with the configuration form and all dictionaries. However I
have
encountered a problem when I tried to delete what I have typed. Just
press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering if
we
really need to manage the personal dictionary in a different window. The
spell check configuration form contains only a combobox, so we have
enough
space to add directly there the table with added words. In the bottom we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I
think that it could be a good idea to allow users to see what
dictionaries
they have installed, to update or remove dictionaries. At this moment
when
you select a dictionary in the configuration form it's downloaded in the
home directory, but we could neither update it, nor remove it or may be
I
have missed it. I was also looking at the parameters.xml you use to
store
configuration parameters, does this xml do something special or we
could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the
dictionary while typing and also allow user to disable/enable the
spellchecking while typing. Like for example in any text area in Firefox
you
have "Spell checking" and "Languages" items in the right button menu.
You
could even add a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:

Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we

have
left more space for the configuration forms, but we could think of
returning
it, we're playing a lot with the gui these days and try to find more
user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality
is

added. Are there any plans to come up with an alternative means of
listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting
(bold,

italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols

which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev
mailing list, so that we could continue discussing the spellchecker
there.
You could even send some screenshots, so that the others get an idea of
what
we're talking about :wink:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Damian,

Damian Johnson wrote:

Hi Yana. Thanks for the reply! With those hints I've finished integrating
the spellchecker into the trunk.

Great!

I'm just wondering if it's not a better idea to remove the language

selection box from the toolbar and put a menu item in the right button menu
in the chat "write area".

With over seventy locales this would be far too large a list for a
right-click menu.

I've imagined that we would be able to install some of our "favorite" languages and then in this right button menu we'll be able to choose one of them. This problem is related to the fact that at the moment we don't have a list of installed dictionaries.

It happens quite often, but you should try to type some words and then press

(continuously!) the backspace button. If it doesn't happen from the first
time try to type again.

I've tried a few times under all the conditions I could think of but haven't
been able to reproduce this issue. The stack trace you provided says the
problem was when deleting a character at the start of the document or in
front of a non-letter. Is there a particular series of keystrokes on which
the error always manifests? Does it seem like a timing (concurrency) issue
to you? Unfortunately I'm at a loss for how to tackle this...

I've made some more tests and the problem was appearing each time I deleted a letter, positioned after a space character. I've looked at the stack trace and found the bug on line 276 of the DocUnderliner.

changed = Word.getWord(text, event.getOffset(), false);

If I type: "test t" and I delete the character "t" the getOffset() would return 5 and in the Word.getWord method you would try to call WORD_ITR.following(index); and there's nothing following the 5 index, because it's already deleted. There you get the : java.lang.IllegalArgumentException: offset out of bounds. The fix here would be to call the getWord method with event.getOffset() - 1 and to separate the case when the getOffset is 0 and when you're after a non-letter character.

The one feature I didn't implement was a means of managing dictionaries
(updating and removing). After I started working on it I found that imposing
a dictionary versioning scheme so the plugin would understand that version
1.0 came from source X and 1.1 came from source Y really violates the KISS
principle. Currently we can simply update dictionaries by defining
dictionary URLs with different filenames (the plugin will figure out that
you don't have the necessary resources, then go out and get it). As for
dictionary removal, the best solution I've figured would be to assume
everything in '.sip-communicator/spellingDictionaries' is a dictionary and
provide a little dialog that allows those files to be deleted. However, on
average dictionaries are small (around 200kb) so I'm not really sure if this
would be a worthwhile addition...

I think that the most important feature here would be to have a list of all already installed dictionaries. The user should be aware of what dictionary he/she is using and this should be used as a list of "favorite" dictionaries from which the user would be able to switch when typing. You could use the ConfigurationService in order to store installed dictionaries. There you could also store the path and the URL for each dictionary.

I'm not sure I understand your idea about updating the dictionaries with different file names. Could you explain more?

When I'm thinking now we should also change the way a dictionary is installed, because the selection from a combo box doesn't suppose installation. Then I agree that 200kb is not important size, but it's not very fair to the user to let him install something he/she could not delete afterwards.

Cheers,
Yana

···

If this patch is committed then I'll revise the keybindings patch to
retrieve defaults by the same means. Cheers! -Damian

On Sun, Aug 10, 2008 at 10:51 PM, Yana Stamcheva > <yana@sip-communicator.org>wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. The spell checker's been applied against the trunk. I thought
it'd
be done tonight but I've ran into a couple of rather nasty, unexpected
issues:

1. The chat panel now composes messages as html which is throwing off the
indices. For instance with the basic text "hello world" getMessage()
returns:
<html>
<head>

</head>
<body>
   <p style="margin-top: 0">
     hello world
   </p>
</body>
</html>

We discussed using html to underline text a while back but I decided
against
it since it's unnecessary for formatting, tends to hurt performance and
since I was concerned about this issue. With a bit of work I think I'll be
able to come up with a hack to get the plain text message but between tag
detection, escape characters (such as '&amp;') and stripped white space
it'll probably be far from trivial (and really hurt the spell checker's
look-up time). Why is it being used now and do you have any suggestions
for
how to tackle this?

Text formatting is a feature most of the IM clients have, so this is
something we absolutely want to have. I personally prefer that we think of a
clear solution for this problem and not a hack. There already exist a
method, which returns the clear text without any html tags:
ChatPanel.getTextFromWriteArea(String mimeType). Could you explain us more
about how you make the underlying right now and we could think of merging
the two functionalities?

2. Evidently you modified the ResourceManagementService on Sunday removing
the getCurrentSettings() method. I was using this to access
defaults.properties- is there another means of getting all the defaults?
Without it the Keybindings patch won't be able to be applied either...

Is it possible for you to use the getSettingString method instead?
getCurrentSettings was returning all setting properties and you normally
need only the spellcheck ones.

Cheers,
Yana

I hope these issues (especially the first) won't be as problematic as I
think... -Damian

On Wed, Aug 6, 2008 at 10:25 PM, Damian Johnson <atagar1@gmail.com> >>> wrote:

Hi Yana. I just committed a revision with the following changes:

- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some
locales, allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian
(Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

However, the bug you mentioned is eluding me. I'm not surprised you got
that exception- it's caused by the DocUnderliner, which was the
trickiest
part and took a couple weeks to flush out all the little off-by-one
errors
that caused IllegalArgumentExceptions. Could you please provide the
step-by-step use case to reproduce it? I tried just opening a chat and
hitting the backspace but no luck...

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva < >>>> yana@sip-communicator.org >>>> >>>>> wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin

but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker desirable
functionality? I've mentioned this API's advantages on my blog but I've
never seen an application with multiple alternative spell checkers. If
not,
I'll begin making the changes against the trunk so there's a fresh
patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're

already
there. In my opinion there are still some issues to resolve in order to
make
the existing implementation more stable, before going with adding a new
implementation.

I was playing with the spellchecker today and I find it great!! Really
well done with the configuration form and all dictionaries. However I
have
encountered a problem when I tried to delete what I have typed. Just
press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering if
we
really need to manage the personal dictionary in a different window. The
spell check configuration form contains only a combobox, so we have
enough
space to add directly there the table with added words. In the bottom we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries. I
think that it could be a good idea to allow users to see what
dictionaries
they have installed, to update or remove dictionaries. At this moment
when
you select a dictionary in the configuration form it's downloaded in the
home directory, but we could neither update it, nor remove it or may be
I
have missed it. I was also looking at the parameters.xml you use to
store
configuration parameters, does this xml do something special or we
could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the
dictionary while typing and also allow user to disable/enable the
spellchecking while typing. Like for example in any text area in Firefox
you
have "Spell checking" and "Languages" items in the right button menu.
You
could even add a new Dictionary from there. I think that could be handy.

PS. A few unrelated UI questions:

Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we

have
left more space for the configuration forms, but we could think of
returning
it, we're playing a lot with the gui these days and try to find more
user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality
is

added. Are there any plans to come up with an alternative means of
listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting
(bold,

italic, and such) but can IM protocols handle the spiffy, fancier
functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols

which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the dev
mailing list, so that we could continue discussing the spellchecker
there.
You could even send some screenshots, so that the others get an idea of
what
we're talking about :wink:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Yana.

I've imagined that we would be able to install some of our "favorite"

languages and then in this right button menu we'll be able to choose one of
them. This problem is related to the fact that at the moment we don't have a
list of installed dictionaries.

The usability discussion made a good point that only exceedingly well-used
functionality should go on the toolbar so I agree. This patch replaces the
combo box with a submenu of currently installed locales (see screen shot).

I've made some more tests and the problem was appearing each time I deleted

a letter, positioned after a space character.

Ah, the mystery is revealed! This seems to be a Java bug- on mine your
example works just fine- the word is just an empty string. Also, according
to the Javadocs it should only bugger up if the offset's "greater than the
last text boundary", not equal to as in this case. This code is right- the
change you suggested would be an off-by-one error. I've added:
  if (event.getOffset() == text.length()) return;
to prevent this particular issue. However, I'm not sure if this problem will
manifest elsewhere.

I think that the most important feature here would be to have a list of all

already installed dictionaries. The user should be aware of what dictionary
he/she is using and this should be used as a list of "favorite" dictionaries
from which the user would be able to switch when typing. You could use the
ConfigurationService in order to store installed dictionaries. There you
could also store the path and the URL for each dictionary.

I'm not sure I understand your idea about updating the dictionaries with
different file names. Could you explain more?

When I'm thinking now we should also change the way a dictionary is
installed, because the selection from a combo box doesn't suppose
installation. Then I agree that 200kb is not important size, but it's not
very fair to the user to let him install something he/she could not delete
afterwards.

In an effort to keep the plugin simple I've been aiming to keep this a
strictly on-demand service with minimal metadata. As far as the plugin's
concerned if it can find "lt_LT.zip" then Latin's available. If not then it
gets it when requested. In the case of updates if we change the Latin
dictionary in defaults.properties to "lt_LT2.zip" then the plugin would
again think Latin isn't installed and get the new dictionary when it's
needed.

I think that simple internal bookkeeping is important since it makes the
plugin resilient in the face of manual changes (ie, editing the contents of
spellingDictionaries). Hence I'm against using the ConfigurationService to
store anything beyond the currently selected locale. However, this updating
scheme has a few drawbacks:
1. When updating dictionaries the old version isn't cleaned up. In the above
example "lt_LT.zip" would still be around (just unused).
2. Updated dictionaries need to be used again to be re-downloaded. In
general this is fine. The only wrinkle is that they'd disappear from the
right-click menu since it only lists currently installed dictionaries.

That said, I have an idea for a change that would allow clean updates as
well as keeping the simple internal bookkeeping. Rather than using
defaults.properties for the spellchecker parameters lets make a repository
with a copy of all the spellchecker dictionaries *and* a file called
"properties.xml" with those parameters. When the spell checker starts up it
checks to see if the repository's "properties.xml" differs from its local
copy. If so, then there's updates to make and it deletes any outdated
dictionaries and downloads the new copies (and replaces its local copy of
"properties.xml"). This way we could push updates without changing the
defaults.properties (which is really an inappropriate place for these
parameters anyway). We had discussed having our own repository to avoid
relying on third-party sites for the dictionaries anyway. If we went with
this then I'd prefer going back to xml since it's better suited for these
mappings and it'd no longer need to contend with the Sip convention of using
the '.properties' format.

If you like this idea than I'll start working on it (making the initial
version of the repository on my site). However, this'll take a while and I
don't think it's a blocking issue for getting this version committed.
Cheers! -Damian

spellchecker2.patch (250 KB)

···

On Sun, Aug 17, 2008 at 1:57 PM, Yana Stamcheva <yana@sip-communicator.org>wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. Thanks for the reply! With those hints I've finished integrating
the spellchecker into the trunk.

Great!

I'm just wondering if it's not a better idea to remove the language

selection box from the toolbar and put a menu item in the right button
menu
in the chat "write area".

With over seventy locales this would be far too large a list for a
right-click menu.

I've imagined that we would be able to install some of our "favorite"
languages and then in this right button menu we'll be able to choose one of
them. This problem is related to the fact that at the moment we don't have a
list of installed dictionaries.

It happens quite often, but you should try to type some words and then
press

(continuously!) the backspace button. If it doesn't happen from the first
time try to type again.

I've tried a few times under all the conditions I could think of but
haven't
been able to reproduce this issue. The stack trace you provided says the
problem was when deleting a character at the start of the document or in
front of a non-letter. Is there a particular series of keystrokes on which
the error always manifests? Does it seem like a timing (concurrency) issue
to you? Unfortunately I'm at a loss for how to tackle this...

I've made some more tests and the problem was appearing each time I deleted
a letter, positioned after a space character. I've looked at the stack trace
and found the bug on line 276 of the DocUnderliner.

changed = Word.getWord(text, event.getOffset(), false);

If I type: "test t" and I delete the character "t" the getOffset() would
return 5 and in the Word.getWord method you would try to call
WORD_ITR.following(index); and there's nothing following the 5 index,
because it's already deleted. There you get the :
java.lang.IllegalArgumentException: offset out of bounds. The fix here would
be to call the getWord method with event.getOffset() - 1 and to separate the
case when the getOffset is 0 and when you're after a non-letter character.

The one feature I didn't implement was a means of managing dictionaries
(updating and removing). After I started working on it I found that
imposing
a dictionary versioning scheme so the plugin would understand that version
1.0 came from source X and 1.1 came from source Y really violates the KISS
principle. Currently we can simply update dictionaries by defining
dictionary URLs with different filenames (the plugin will figure out that
you don't have the necessary resources, then go out and get it). As for
dictionary removal, the best solution I've figured would be to assume
everything in '.sip-communicator/spellingDictionaries' is a dictionary and
provide a little dialog that allows those files to be deleted. However, on
average dictionaries are small (around 200kb) so I'm not really sure if
this
would be a worthwhile addition...

I think that the most important feature here would be to have a list of all
already installed dictionaries. The user should be aware of what dictionary
he/she is using and this should be used as a list of "favorite" dictionaries
from which the user would be able to switch when typing. You could use the
ConfigurationService in order to store installed dictionaries. There you
could also store the path and the URL for each dictionary.

I'm not sure I understand your idea about updating the dictionaries with
different file names. Could you explain more?

When I'm thinking now we should also change the way a dictionary is
installed, because the selection from a combo box doesn't suppose
installation. Then I agree that 200kb is not important size, but it's not
very fair to the user to let him install something he/she could not delete
afterwards.

Cheers,
Yana

If this patch is committed then I'll revise the keybindings patch to
retrieve defaults by the same means. Cheers! -Damian

On Sun, Aug 10, 2008 at 10:51 PM, Yana Stamcheva >> <yana@sip-communicator.org>wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. The spell checker's been applied against the trunk. I thought

it'd
be done tonight but I've ran into a couple of rather nasty, unexpected
issues:

1. The chat panel now composes messages as html which is throwing off
the
indices. For instance with the basic text "hello world" getMessage()
returns:
<html>
<head>

</head>
<body>
  <p style="margin-top: 0">
    hello world
  </p>
</body>
</html>

We discussed using html to underline text a while back but I decided
against
it since it's unnecessary for formatting, tends to hurt performance and
since I was concerned about this issue. With a bit of work I think I'll
be
able to come up with a hack to get the plain text message but between
tag
detection, escape characters (such as '&amp;') and stripped white space
it'll probably be far from trivial (and really hurt the spell checker's
look-up time). Why is it being used now and do you have any suggestions
for
how to tackle this?

Text formatting is a feature most of the IM clients have, so this is

something we absolutely want to have. I personally prefer that we think
of a
clear solution for this problem and not a hack. There already exist a
method, which returns the clear text without any html tags:
ChatPanel.getTextFromWriteArea(String mimeType). Could you explain us
more
about how you make the underlying right now and we could think of merging
the two functionalities?

2. Evidently you modified the ResourceManagementService on Sunday

removing
the getCurrentSettings() method. I was using this to access
defaults.properties- is there another means of getting all the defaults?
Without it the Keybindings patch won't be able to be applied either...

Is it possible for you to use the getSettingString method instead?

getCurrentSettings was returning all setting properties and you normally
need only the spellcheck ones.

Cheers,
Yana

I hope these issues (especially the first) won't be as problematic as I

think... -Damian

On Wed, Aug 6, 2008 at 10:25 PM, Damian Johnson <atagar1@gmail.com> >>>> wrote:

Hi Yana. I just committed a revision with the following changes:

- Added a button to enable/disable spell checker
- Provided the ability to swap locales while composing messages
- The JMySpell developer provided a fix for the bug afflicting some
locales, allowing us to include:
Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian
(Italy),
Latvian (Latvia), and Nepali (Nepal)
bringing the number of supported locales to 72.

However, the bug you mentioned is eluding me. I'm not surprised you got
that exception- it's caused by the DocUnderliner, which was the
trickiest
part and took a couple weeks to flush out all the little off-by-one
errors
that caused IllegalArgumentExceptions. Could you please provide the
step-by-step use case to reproduce it? I tried just opening a chat and
hitting the backspace but no luck...

Besides that remaining issues include:
- Grey scale the flags of missing dictionaries
- Provide a means of updating/removing dictionaries
- Apply changes against the trunk
- Move configuration to defaults.properties

Cheers! -Damian

On Fri, Jul 25, 2008 at 6:20 AM, Yana Stamcheva < >>>>> yana@sip-communicator.org >>>>> >>>>> wrote:

Hi Damian,

Damian Johnson wrote:

Hi Yana. I've begun integrating JOrtho into the spell checker plugin

but
it's looking like it's gonna take a couple days. Before I dig in any
further
I'd like to make sure: is having an alternative spell checker
desirable
functionality? I've mentioned this API's advantages on my blog but
I've
never seen an application with multiple alternative spell checkers.
If
not,
I'll begin making the changes against the trunk so there's a fresh
patch.
Cheers! -Damian

I see what the advantages of JOrtho are, but I'm not sure we're

already
there. In my opinion there are still some issues to resolve in order
to
make
the existing implementation more stable, before going with adding a
new
implementation.

I was playing with the spellchecker today and I find it great!! Really
well done with the configuration form and all dictionaries. However I
have
encountered a problem when I tried to delete what I have typed. Just
press
backspace and you'll see the following exception :
java.lang.IllegalArgumentException: offset out of bounds. If you don't
experience the same problem, I'll have a look and will give you more
information on the exception.

The "Add word" functionality is awesome! And you could even add words
through the configuration form, which is great. I was just wondering
if
we
really need to manage the personal dictionary in a different window.
The
spell check configuration form contains only a combobox, so we have
enough
space to add directly there the table with added words. In the bottom
we
could add the text field and the "Add to dictionary" button. In this
configuration we won't need the apply button. What do you think?

Otherwise, I was looking at how you manage the different dictionaries.
I
think that it could be a good idea to allow users to see what
dictionaries
they have installed, to update or remove dictionaries. At this moment
when
you select a dictionary in the configuration form it's downloaded in
the
home directory, but we could neither update it, nor remove it or may
be
I
have missed it. I was also looking at the parameters.xml you use to
store
configuration parameters, does this xml do something special or we
could
use instead the ConfigurationService?

Some other things we should think of is allow user to change the
dictionary while typing and also allow user to disable/enable the
spellchecking while typing. Like for example in any text area in
Firefox
you
have "Spell checking" and "Languages" items in the right button menu.
You
could even add a new Dictionary from there. I think that could be
handy.

PS. A few unrelated UI questions:

Why was the setting dialog's "Close" button removed?

We thought that we have already the "x" button on the window and we

have
left more space for the configuration forms, but we could think of
returning
it, we're playing a lot with the gui these days and try to find more
user
friendly solutions.

The settings dialog is gonna get pretty crowded as more functionality
is

added. Are there any plans to come up with an alternative means of

listing
ConfigurationForms?

Agree. Do you have something in mind? We didn't think of this yet.

It's spiffy that the ChatWritePanel now supports basic formatting
(bold,

italic, and such) but can IM protocols handle the spiffy, fancier

functionality (fonts and coloring)?

We have now support for ICQ, MSN, Yahoo, Aim and Jabber. Protocols

which
does not support this functionality just send plain text.

Cheers,
Yana

P.S. Damian, hope you don't mind that I'm sending also a copy to the
dev
mailing list, so that we could continue discussing the spellchecker
there.
You could even send some screenshots, so that the others get an idea
of
what
we're talking about :wink:

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi,

I have only a only reasonable ISP connection with a speed of 800kbs upload and I am having trouble with an Asterisk server. Can someone suggest a good format to use?

Also, when I connect I get lots of these messages to standard output. It takes about 8 seconds just to print them all.

ant run
...lots of output like.
     [java] RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8 bits - ilbc/rtp, 8000.0 Hz, 16-bit, Mono, LittleEndian, Signed
     [java] RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8 bits - ALAW/rtp, 8000.0 Hz, 8-bit, Mono, Signed
     [java] RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono, FrameSize=8 bits - speex/rtp, 8000.0 Hz, 8-bit, Mono, Signed
     [java] RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8 bits - ilbc/rtp, 8000.0 Hz, 16-bit, Mono, LittleEndian, Signed
     [java] RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8 bits - ALAW/rtp, 8000.0 Hz, 8-bit, Mono, Signed
     [java] RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono, FrameSize=8 bits - speex/rtp, 8000.0 Hz, 8-bit, Mono, Signed

I believe this is coming from JMF.jar somewhere. Can anyone suggest how to turn them off without maintaining my own version of JMF.jar.

thanks, Kim.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hey Kim,

I have a similar setup at home and I am quite happy using PCMA/PCMU.

Hope this helps
Emil

Kim Michael Fairchild написа:

···

Hi,

I have only a only reasonable ISP connection with a speed of 800kbs
upload and I am having trouble with an Asterisk server. Can someone
suggest a good format to use?

Also, when I connect I get lots of these messages to standard output. It
takes about 8 seconds just to print them all.

ant run
...lots of output like.
     [java] RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono,
FrameSize=8 bits - ilbc/rtp, 8000.0 Hz, 16-bit, Mono, LittleEndian, Signed
     [java] RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono,
FrameSize=8 bits - ALAW/rtp, 8000.0 Hz, 8-bit, Mono, Signed
     [java] RTPSessMgr not match : ALAW/rtp, 32000.0 Hz, 8-bit, Mono,
FrameSize=8 bits - speex/rtp, 8000.0 Hz, 8-bit, Mono, Signed
     [java] RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono,
FrameSize=8 bits - ilbc/rtp, 8000.0 Hz, 16-bit, Mono, LittleEndian, Signed
     [java] RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono,
FrameSize=8 bits - ALAW/rtp, 8000.0 Hz, 8-bit, Mono, Signed
     [java] RTPSessMgr not match : ULAW/rtp, 48000.0 Hz, 8-bit, Mono,
FrameSize=8 bits - speex/rtp, 8000.0 Hz, 8-bit, Mono, Signed

I believe this is coming from JMF.jar somewhere. Can anyone suggest how
to turn them off without maintaining my own version of JMF.jar.

thanks, Kim.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net