showing a "not built with spellchecker enabled" message?

[Scott Kostyshak]

If LyX is not built explicitly enabling a spellchecker, some fields
are greyed out. This comes up from time to time on the list. Would it
be more or less confusing to have a message explaining that LyX needs
to have the option set at compile time?

Scott

[Jean-Marc Lasgouttes]

Post by Scott Kostyshak
If LyX is not built explicitly enabling a spellchecker, some fields
are greyed out. This comes up from time to time on the list. Would it
be more or less confusing to have a message explaining that LyX needs
to have the option set at compile time?

What kind of message do you have in mind?

Maybe the list that allows to choose the spellchecker could read "none
available"?

JMarc

[Stephan Witt]

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak
If LyX is not built explicitly enabling a spellchecker, some fields
are greyed out. This comes up from time to time on the list. Would it
be more or less confusing to have a message explaining that LyX needs
to have the option set at compile time?

There is a message send to console when building with Cmake and no spell checker is configured.

Stephan

Post by Jean-Marc Lasgouttes
What kind of message do you have in mind?
Maybe the list that allows to choose the spellchecker could read "none available"?
JMarc

[Scott Kostyshak]

Post by Stephan Witt

Post by Scott Kostyshak
If LyX is not built explicitly enabling a spellchecker, some fields
are greyed out. This comes up from time to time on the list. Would it
be more or less confusing to have a message explaining that LyX needs
to have the option set at compile time?

There is a message send to console when building with Cmake and no spell checker is configured.

I just took a look and if I do "cmake -DLYX_USE_QT=QT5" I see

-- Could NOT find ASPELL (missing: ASPELL_LIBRARY ASPELL_INCLUDE_DIR)
-- ASPELL not found, building without ASPELL support
-- Found ENCHANT: /usr/lib/x86_64-linux-gnu/libenchant.so
-- Building with USE_ENCHANT
-- Found HUNSPELL: /usr/lib/x86_64-linux-gnu/libhunspell.so
-- Building with USE_HUNSPELL

but then at the end where it lists the flags I see
-- LYX_ASPELL = OFF : Require aspell
-- LYX_ENCHANT = OFF : Require Enchant
-- LYX_HUNSPELL = OFF : Require Hunspell

But then when I open LyX it seems they are enabled. Ah, now I see
where I misunderstood. The flags just show what I set (and what was
default), not what actually happened.

Scott

[Scott Kostyshak]

On Thu, Jul 17, 2014 at 11:10 AM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak
If LyX is not built explicitly enabling a spellchecker, some fields
are greyed out. This comes up from time to time on the list. Would it
be more or less confusing to have a message explaining that LyX needs
to have the option set at compile time?

What kind of message do you have in mind?
Maybe the list that allows to choose the spellchecker could read "none
available"?

I wanted to come up with something that would signal to the user that
it is a build issue and not a "can't find hunspell" issue (i.e. it's a
"didn't tell me to look for hunspell" issue).

Scott

[Jean-Marc Lasgouttes]

Post by Scott Kostyshak

Post by Jean-Marc Lasgouttes
Maybe the list that allows to choose the spellchecker could read "none
available"?

I wanted to come up with something that would signal to the user that
it is a build issue and not a "can't find hunspell" issue (i.e. it's a
"didn't tell me to look for hunspell" issue).

"none compiled in"? "not supported"?

JMarc

[Scott Kostyshak]

On Thu, Jul 17, 2014 at 11:42 AM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak

Post by Jean-Marc Lasgouttes
Maybe the list that allows to choose the spellchecker could read "none
available"?

I wanted to come up with something that would signal to the user that
it is a build issue and not a "can't find hunspell" issue (i.e. it's a
"didn't tell me to look for hunspell" issue).

"none compiled in"? "not supported"?

Yes I like "none compiled in" but have mixed feelings. If it is
someone who compiled LyX themselves, then it is good because it is a
strong signal of how to fix the problem. But if it is someone using a
package on their distro compiled by the packager then maybe that would
be a scary/confusing message?

What do others think?

Scott

[Jean-Marc Lasgouttes]

Post by Scott Kostyshak
Yes I like "none compiled in" but have mixed feelings. If it is
someone who compiled LyX themselves, then it is good because it is a
strong signal of how to fix the problem. But if it is someone using a
package on their distro compiled by the packager then maybe that would
be a scary/confusing message?

Well they _should_ be scared if their distro provides this.

JMarc

[Scott Kostyshak]

On Thu, Jul 17, 2014 at 12:02 PM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak
Yes I like "none compiled in" but have mixed feelings. If it is
someone who compiled LyX themselves, then it is good because it is a
strong signal of how to fix the problem. But if it is someone using a
package on their distro compiled by the packager then maybe that would
be a scary/confusing message?

Well they _should_ be scared if their distro provides this.

Good point.

Scott

[Kornel Benko]

Post by Scott Kostyshak
On Thu, Jul 17, 2014 at 12:02 PM, Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes

Post by Scott Kostyshak
Yes I like "none compiled in" but have mixed feelings. If it is
someone who compiled LyX themselves, then it is good because it is a
strong signal of how to fix the problem. But if it is someone using a
package on their distro compiled by the packager then maybe that would
be a scary/confusing message?

Well they _should_ be scared if their distro provides this.

Good point.
Scott

So nothing to change? OK.

Kornel