date:20151006

> Le 06/10/2015 21:01, Pavel Sanda a écrit :
> I think you might be mixing issues. One thing is allowing to have
> UTF-8 string literals especially in translations, another one is
> deciding that we now use ? instead of ... in the interface to be
> consistent with Qt.

To clarify, I'm not against having ellipsis in the menu per se by whatever
mechanism you use to pass it to Qt routines. What I am not way too happy is
increasing % of utf8-based source code itself and following translations.

Pavel

Re: UTF-8 in string literals and translation strings in particular

2015-10-06 Thread Cyrille Artho





After more looking around, I see that Apple recommends the ellispsis
character:
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3


Gnome seems to prefer ellipsis character too:
https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses

Microsoft does not say anything, but their examples use ...:
https://msdn.microsoft.com/en-us/library/dn742392.aspx

I think for UI guidelines, if Apple and Gnome recommend A, and Microsoft 
recommends B, then A is definitely the right way. ;-)


I think it's important to consider that in many languages, three dots is 
just plain wrong, so we should do things the proper way.

>

Seriously, I think this is just going to annoy our translators. Seriously,
who knows how to get an ellipsis on his/her keyboard?


It's trivial. Character viewer -> Punctuation -> there it is right away.
If you type it often you can look up the keyboard shortcut.
>

I could propose to hack it into the menu code...

I general, our source code is already UTF8 (in particular author names in
.cpp files), but I am not sure that adding weird characters in the source
is always helpful. I would not swear that there only one character looking
like an ellipsis in unicode standard.

 > Properly formatted text in general, not just proper ellipses…
 > A revamped IPA toolbar?
 > The math toolbar?
 > See also src/frontends/qt4/ui/HSpaceUi.ui in the patch.

Please note that we have to be very careful with unicode characters. At
some times I advocated using the proper unicode visible space character in
our documentation, but it turned out that several windows font did not have
that. You do not want to force users to use such or such font in their text
editor.

>
Then maybe we can try to prevent a user configuration LyX with such strange 
fonts. Fonts without important characters are a relic of the past, and 
sooner or later even Windows will adapt.



Of all programs, if LyX does not need an Unicode interface, which
program does? I am sure you will be able to come up with creative uses.


LyX needs an interface that blends well with the environment where it runs.



Unicode characters in some menus (math panel etc.) would indeed look much 
better than pixelated bitmaps.

--
Regards,
Cyrille Artho - http://artho.com/
Solitude is an illusion, for every silence is filled
by a clamorous search for meaning.
-- Steven Erikson, "House of Chains"

Some buttons on Maths palette don't work!

2015-10-06 Thread Oliver Frolovs

Hello everyone,

I am testing LyX suitability for my thesis write-up, 
and I've come across an odd problem: 
the buttons in submenus on the maths toolbar
are _mostly_ unclickable. By that I mean 
that the first row of the buttons in any given 
submenu on that palette does not work. 
It's hard to explain in words, so I have
 recorded a short video showing what works 
and what does not: https://vimeo.com/141471729

I'm running LyX Version 2.1.4 (24 July 2015) 
on OS X 10.11 (El Capitan).

Please let me know if I am missing something 
obvious here. I've read the Tutorial and
 if I understood it correctly, all of these buttons 
should work in maths mode (and some of them do).

Best regards,

Ollie

Re: UTF-8 in string literals and translation strings in particular


Le 06/10/15 21:43, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Well, actually I am not sure that we use the same ellipsis as in English.


You mean as a translator I need to find French version of ellipsis?


I even remeber of a document that stated that using 3 dots wa better in 
French, but I cannot find it right now…


JMarc

Re: UTF-8 in string literals and translation strings in particular


Le 06/10/2015 21:01, Pavel Sanda a écrit :

Guillaume Munch wrote:

Seriously, I think this is just going to annoy our translators.


Seriously :) as described in the rationale of my patch, this cannot be more
transparent for translators. Gettext pre-sets the previous translation;
translators just have to do a global search-replace. And until they do, the
old translation is still displayed. I took the time to check that it's
indeed the case. And you might be underestimating our translators, some of
whom might be lovers of proper typographic usage.


Seriously, who knows how to get an ellipsis on his/her keyboard?


Seriously :) I am sorry, ignorance is not an argument. A lot of bad
typographic usage is only the legacy of past technical limitations that are
long gone. It took me 10 seconds to learn that ??? is AltGr+Shift+, in the
french Linux keyboard and Option+; on Mac. (For proper French usage, you
can also input accented upper-case characters and I am sure that your
question marks are preceded by a space ??? though I would agree that a thin
space would appear as too formal in e-mails.)


I dont think this is a question of ignorance but of comfort.
It took me 5 min to figure out how to enter elipsis directly and no
I will not rember the number 2026 or whatever weird shortcut my
keyboard layout might have for the next time.
I'm afraid more on JMarc side on the points above.

Pavel




I think you might be mixing issues. One thing is allowing to have UTF-8 
string literals especially in translations, another one is deciding that 
we now use … instead of ... in the interface to be consistent with Qt.


If you do not find typographic consistency important personally, then I 
imagine that you would continue typing "..." in UI strings. I would see 
it personally as a minor bug, but who will prevent you from doing it?



Guillaume

Re: UTF-8 in string literals and translation strings in particular

Guillaume Munch wrote:
>> Seriously, I think this is just going to annoy our translators.
>
> Seriously :) as described in the rationale of my patch, this cannot be more 
> transparent for translators. Gettext pre-sets the previous translation; 
> translators just have to do a global search-replace. And until they do, the 
> old translation is still displayed. I took the time to check that it's 
> indeed the case. And you might be underestimating our translators, some of 
> whom might be lovers of proper typographic usage.
>
>> Seriously, who knows how to get an ellipsis on his/her keyboard?
>
> Seriously :) I am sorry, ignorance is not an argument. A lot of bad 
> typographic usage is only the legacy of past technical limitations that are 
> long gone. It took me 10 seconds to learn that ??? is AltGr+Shift+, in the 
> french Linux keyboard and Option+; on Mac. (For proper French usage, you 
> can also input accented upper-case characters and I am sure that your 
> question marks are preceded by a space ??? though I would agree that a thin 
> space would appear as too formal in e-mails.)

I dont think this is a question of ignorance but of comfort.
It took me 5 min to figure out how to enter elipsis directly and no
I will not rember the number 2026 or whatever weird shortcut my
keyboard layout might have for the next time.
I'm afraid more on JMarc side on the points above.

Pavel

Re: UTF-8 in string literals and translation strings in particular

Jean-Marc Lasgouttes wrote:
> Well, actually I am not sure that we use the same ellipsis as in English.

You mean as a translator I need to find French version of ellipsis?
P

Re: UTF-8 in string literals and translation strings in particular


Le 06/10/2015 20:03, Guillaume Munch a écrit :

Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit :


For the docstring part of the code, I am not sure what code like the
following do:

-LASSERT(static_cast(*c) < 0x80, return l);
-s.push_back(*c);
+if (static_cast(*c) < 0x80)
+s.push_back(*c);
+else
+return s += from_utf8(string(c));

There is nothing magic about from_utf8(string(c)), right? This is just
accepting latin1 characters, or am I blind?




To be more precise, it accepts Latin-1 characters that are part of the
ASCII subset, yes, if that was your remark :)




In the meanwhile I understood that probably the precision that you need 
is that c is a C string that denotes the suffix of r and string(c) 
converts the whole remainder of r into a c++ string, not just the next char.

Re: UTF-8 in string literals and translation strings in particular


Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit :


For the docstring part of the code, I am not sure what code like the
following do:

-LASSERT(static_cast(*c) < 0x80, return l);
-s.push_back(*c);
+if (static_cast(*c) < 0x80)
+s.push_back(*c);
+else
+return s += from_utf8(string(c));

There is nothing magic about from_utf8(string(c)), right? This is just
accepting latin1 characters, or am I blind?




To be more precise, it accepts Latin-1 characters that are part of the 
ASCII subset, yes, if that was your remark :)

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 18:28, Jean-Marc Lasgouttes a écrit :

Le 06/10/2015 18:38, Guillaume Munch a écrit :

I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.

Is it trivial? On my ubuntu libreoffice (where I can write the same
string to compare), I would say that what is used is three dots and not
ellipsis. I failed to find documentation on the subject, except:
http://stackoverflow.com/questions/3777072/in-menus-for-should-one-use-ellipsis-sign-or-just-three-dots

Note that the above comments are from 2010.

After more looking around, I see that Apple recommends the ellispsis
character:
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3

Gnome seems to prefer ellipsis character too:
https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses

Microsoft does not say anything, but their examples use ...:
https://msdn.microsoft.com/en-us/library/dn742392.aspx

In addition, Qt already uses … to elide strings so we currently have an
inconsistent UI.

Seriously, I think this is just going to annoy our translators.

Seriously :) as described in the rationale of my patch, this cannot be
more transparent for translators. Gettext pre-sets the previous
translation; translators just have to do a global search-replace. And
until they do, the old translation is still displayed. I took the time
to check that it's indeed the case. And you might be underestimating our
translators, some of whom might be lovers of proper typographic usage.

Seriously, who knows how to get an ellipsis on his/her keyboard?

Seriously :) I am sorry, ignorance is not an argument. A lot of bad
typographic usage is only the legacy of past technical limitations that
are long gone. It took me 10 seconds to learn that … is AltGr+Shift+, in
the french Linux keyboard and Option+; on Mac. (For proper French usage,
you can also input accented upper-case characters and I am sure that
your question marks are preceded by a space − though I would agree that
a thin space would appear as too formal in e-mails.)

I could propose to hack it into the menu code...

Please, no. Would you also hack my changes to
src/frontends/qt4/ui/HSpaceUi.ui into the dialog code?

I general, our source code is already UTF8 (in particular author names
in .cpp files), but I am not sure that adding weird characters in the
source is always helpful. I would not swear that there only one
character looking like an ellipsis in unicode standard.

Do you have an example where this might lead to a confusing situation?
If I see … in a translation string I would trust the author that he did
not write U+1D087 BYZANTINE MUSICAL SYMBOL TRIPLI without a good reason.
And I do not see how … is more confusing than 0x2026, developers are
free to explain with a comment in both cases.

> Properly formatted text in general, not just proper ellipses…
> A revamped IPA toolbar?
> The math toolbar?
> See also src/frontends/qt4/ui/HSpaceUi.ui in the patch.

Please note that we have to be very careful with unicode characters. At
some times I advocated using the proper unicode visible space character
in our documentation, but it turned out that several windows font did
not have that. You do not want to force users to use such or such font
in their text editor.

As already discussed in the "newline char" thread, this is a separate
issue, easily fixed by providing a fallback font. This is standard practice.

I hear hacks and half-solutions left and right, when Unicode provides a
standard solution. A fallback font would be a good investment for not
reinventing the wheel constantly. (And a custom portable font with a few
special characters taken from various free fonts is incredibly easy to do.)

Of all programs, if LyX does not need an Unicode interface, which
program does? I am sure you will be able to come up with creative uses.

LyX needs an interface that blends well with the environment where it runs.

This is repeating the argument before, so I would repeat the reply.

LyX already uses a ton of Unicode chars, defined by hand with their code
point. This patch makes it easier to use Unicode in the source, and
enables special chars in translation strings as well.

Code point is more precise than trying to recognize a character in a
unicode table. I am sure that emacs can tell me what is the code point
at cursor position, but life is to short to try to find it.

First, the patch does not prevent you from using code points when
appropriate. But it now also allows you to use the \u and \U escape
sequences in string literals, e.g. for translation strings, if you find
it appropriate. Though this is c++11, so only starting from LyX 2.3.
(For ellipses though, I find more useful to read … in the source rather
than \u2026.)

And the patch is free.

Re: UTF-8 in string literals and translation strings in particular

2015-10-06 Thread Richard Heck


On 10/06/2015 12:38 PM, Guillaume Munch wrote:

Le 06/10/2015 17:13, Pavel Sanda a écrit :

Guillaume Munch wrote:

Le 04/10/2015 23:20, Guillaume Munch a écrit :

Dear list,

Has there been some discussion already about allowing UTF-8 in
the source code, in particular for translatable strings? Is this
 something we long for?

Guillaume


Seeing how there is unanimous interest, here's a proof of concept.

Please read the commit log carefully including the rationale and
the "TODO". Skip the first third regarding string updates (yes I
can make them in a separate patch).

While the subject of the patch may seem trivial, I think that
setting this up is a good investment for future use of Unicode in
the interface.


I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.


Properly formatted text in general, not just proper ellipses…
A revamped IPA toolbar?
The math toolbar?
See also src/frontends/qt4/ui/HSpaceUi.ui in the patch.


There are probably some cases involving HTML output, as well. What about 
lib/symbols and the like?


Richard

Re: UTF-8 in string literals and translation strings in particular

Le 06/10/2015 18:38, Guillaume Munch a écrit :

I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.

http://stackoverflow.com/questions/3777072/in-menus-for-should-one-use-ellipsis-sign-or-just-three-dots

After more looking around, I see that Apple recommends the ellispsis
character:

https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3

Gnome seems to prefer ellipsis character too:
https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses

Microsoft does not say anything, but their examples use ...:
https://msdn.microsoft.com/en-us/library/dn742392.aspx

Seriously, I think this is just going to annoy our translators.
Seriously, who knows how to get an ellipsis on his/her keyboard?

I could propose to hack it into the menu code...

> Properly formatted text in general, not just proper ellipses…
> A revamped IPA toolbar?
> The math toolbar?
> See also src/frontends/qt4/ui/HSpaceUi.ui in the patch.

Of all programs, if LyX does not need an Unicode interface, which
program does? I am sure you will be able to come up with creative uses.

LyX needs an interface that blends well with the environment where it runs.

LyX already uses a ton of Unicode chars, defined by hand with their code
point. This patch makes it easier to use Unicode in the source, and
enables special chars in translation strings as well.

Code point is more precise than trying to recognize a character in a
unicode table. I am sure that emacs can tell me what is the code point
at cursor position, but life is to short to try to find it.

And the patch is free.

For the docstring part of the code, I am not sure what code like the
following do:

- LASSERT(static_cast(*c) < 0x80, return l);
- s.push_back(*c);
+ if (static_cast(*c) < 0x80)
+ s.push_back(*c);
+ else
+ return s += from_utf8(string(c));

There is nothing magic about from_utf8(string(c)), right? This is just
accepting latin1 characters, or am I blind?

JMarc

Re: Size of box insets

This looks like a good solution.

Now that I think about it, what about fixed-width tabular cells ? Do they have 
the same problem ?

Jmarc

Le 6 octobre 2015 17:51:26 GMT+02:00, Pavel Sanda  a écrit :

>I can put it into InsetCollapsable for fixedwidth insets. For insettext
>I do not
>know what the minimum size should be because I have no button in API as
>you already know.
-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: UTF-8 in string literals and translation strings in particular

Well, actually I am not sure that we use the same ellipsis as in English.

JMarc

Le 6 octobre 2015 18:13:25 GMT+02:00, Pavel Sanda  a écrit :
>I'm trying to come up with examples where do we actually "need" unicode
>in the interface. The ellipsis case seems to be trivial indeed.
>So except that I can't use my keyboard directly for ellipsis and worry
>what happens with python 2.x what are the gains actually?
>
>Pavel
>
>... Or are guys secretly preparing for turning GUI into French? :)

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: UTF-8 in string literals and translation strings in particular


Le 06/10/2015 17:13, Pavel Sanda a écrit :

Guillaume Munch wrote:

Le 04/10/2015 23:20, Guillaume Munch a écrit :

Dear list,

Has there been some discussion already about allowing UTF-8 in
the source code, in particular for translatable strings? Is this
 something we long for?

Guillaume


Seeing how there is unanimous interest, here's a proof of concept.

Please read the commit log carefully including the rationale and
the "TODO". Skip the first third regarding string updates (yes I
can make them in a separate patch).

While the subject of the patch may seem trivial, I think that
setting this up is a good investment for future use of Unicode in
the interface.


I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.


Properly formatted text in general, not just proper ellipses…
A revamped IPA toolbar?
The math toolbar?
See also src/frontends/qt4/ui/HSpaceUi.ui in the patch.

Of all programs, if LyX does not need an Unicode interface, which
program does? I am sure you will be able to come up with creative uses.

LyX already uses a ton of Unicode chars, defined by hand with their code
point. This patch makes it easier to use Unicode in the source, and
enables special chars in translation strings as well.

And the patch is free.


So except that I can't use my keyboard directly for ellipsis


Well, Mac and Linux users can. For Windows, I do not know.


and worry what happens with python 2.x what are the gains actually?


Nothing wrong will happen with python 2.x. The patch does not touch the 
Python string literals, and it already support UTF-8 translated strings 
if that was needed because all languages apart from English are already 
written in UTF-8.




Pavel

... Or are guys secretly preparing for turning GUI into French? :)



Of course I would let you know one week in advance if that was the case.


Thanks for the feedback

Guillaume

Re: UTF-8 in string literals and translation strings in particular

Guillaume Munch wrote:
> Le 04/10/2015 23:20, Guillaume Munch a écrit :
>> Dear list,
>>
>> Has there been some discussion already about allowing UTF-8 in the
>> source code, in particular for translatable strings? Is this
>> something we long for?
>>
>> Guillaume
>>
> Seeing how there is unanimous interest, here's a proof of concept.
>
> Please read the commit log carefully including the rationale and the 
> "TODO". Skip the first third regarding string updates (yes I can make them 
> in a separate patch).
>
> While the subject of the patch may seem trivial, I think that setting
> this up is a good investment for future use of Unicode in the interface.

I'm trying to come up with examples where do we actually "need" unicode
in the interface. The ellipsis case seems to be trivial indeed.
So except that I can't use my keyboard directly for ellipsis and worry
what happens with python 2.x what are the gains actually?

Pavel

... Or are guys secretly preparing for turning GUI into French? :)

Re: Size of box insets

Jean-Marc Lasgouttes wrote:
> The code in IntextText::metrics does:
>
>   // This can happen when a layout has a left and right margin,
>   // and the view is made very narrow. We can't do better than
>   // to draw it partly out of view (bug 5890).
>   if (mi.base.textwidth < 1)
>   mi.base.textwidth = 1;
>
>   if (hasFixedWidth())
>   tm.metrics(mi, dim, mi.base.textwidth);
>   else
>   tm.metrics(mi, dim);
>
> So (1) it is a nice place to set a minimum width and (2) it is possible to 
> condition on fixed-width insets.
>
>> I thought that zoom is already taken into account in the patch sent, e.g.
>> button size is already calculated wrt zoom.
>
> I agree that in the case of boxes, button size makes sense. Then you can 
> put your code in InsetCollapsable::metrics :)

I can put it into InsetCollapsable for fixedwidth insets. For insettext I do not
know what the minimum size should be because I have no button in API as you 
already know.

Pavel

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0

2015-10-06 Thread Scott Kostyshak

On Tue, Oct 06, 2015 at 10:41:52AM -0400, PhilipPirrip wrote:
> Thanks, Kornel. I'll check these later. I went back in time, September 28
> 18:13 commit 39343d65af worked. Moving forward, will let you know when
> things went bad and send you the backtrace.

Are you stepping forward one-by-one? If so, please look into doing a
"git bisect". It is a fancy name for doing what you are doing, but much
faster.

Scott

Re: segmentation fault, lyx2.2.0dev @ Fedora 23 with Qt 5.5.0