RE: math toolbar usability suggestion (tiny)
Current install version do not have an icon for functions popup. missing entry in scons_manifest and makefile i guess BTW, I think the provided functions.xpm is not so informative. I made another one. i like it. josé?
Re: math toolbar usability suggestion (tiny)
hzluo wrote: I am not sure I understand. Do the labels appear under the icons? Do we support that? JMarc Current install version do not have an icon for functions popup. I think the patch is on the way. We now have a functions.xpm for that button. So you will have a 20x20 button instead of a long string. BTW, I think the provided functions.xpm is not so informative. I made another one. Please see attached. If anyone wants to test it, just put it in images\math I have tested it at normal size and large size. It looks good at both size. I'd prefer something like f(x). A/
Re: math toolbar usability suggestion (tiny)
I am not sure I understand. Do the labels appear under the icons? Do we support that? JMarc Current install version do not have an icon for functions popup. I think the patch is on the way. We now have a functions.xpm for that button. So you will have a 20x20 button instead of a long string. BTW, I think the provided functions.xpm is not so informative. I made another one. Please see attached. If anyone wants to test it, just put it in images\math I have tested it at normal size and large size. It looks good at both size. Hangzai functions.xpm Description: Binary data
Re: math toolbar usability suggestion (tiny)
Edwin == Leuven, E [EMAIL PROTECTED] writes: Current install version do not have an icon for functions popup. Edwin missing entry in scons_manifest and makefile i guess BTW, I think the provided functions.xpm is not so informative. I made another one. Edwin i like it. I like it too. A small function graph might be adequate too. JMarc
RE: math toolbar usability suggestion (tiny)
What about an f(x) symbol? this suggests to me that there is an argument to give or a function to build, and i would expect it more on a toolbar to interface with maple etc (imho of course...)
Re: math toolbar usability suggestion (tiny)
Selon Alfredo Braunstein [EMAIL PROTECTED]: hzluo wrote: I am not sure I understand. Do the labels appear under the icons? Do we support that? JMarc Current install version do not have an icon for functions popup. I think the patch is on the way. We now have a functions.xpm for that button. So you will have a 20x20 button instead of a long string. BTW, I think the provided functions.xpm is not so informative. I made another one. Please see attached. If anyone wants to test it, just put it in images\math I have tested it at normal size and large size. It looks good at both size. I'd prefer something like f(x). Me too. Mael.
Re: math toolbar usability suggestion (tiny)
IMHO, if you prefer to use f instead of real function names, I suggest to use a black (maybe also bold) f followed by a blue box. Or better, fun followed by a blue box (but then the button may be too wide for normal size, which is set to 20x20. Maybe fn?). But I still think f is less straightforward than real function names. - Original Message - From: Mael Hilléreau [EMAIL PROTECTED] To: Leuven, E. [EMAIL PROTECTED] Cc: Mael Hilléreau [EMAIL PROTECTED]; Jean-Marc Lasgouttes [EMAIL PROTECTED]; hzluo [EMAIL PROTECTED]; LyX Mechanics lyx-devel@lists.lyx.org Sent: Friday, June 08, 2007 11:24 AM Subject: RE: math toolbar usability suggestion (tiny) Selon Leuven, E. [EMAIL PROTECTED]: What about an f(x) symbol? this suggests to me that there is an argument to give or a function to build, and i would expect it more on a toolbar to interface with maple etc (imho of course...) There is actually arguments to give when you insert such a function. I think it is clear enough that no computation will be made (LyX is for writing only). Mael.
Re: math toolbar usability suggestion (tiny)
Selon Mael Hilléreau [EMAIL PROTECTED]: BTW, I think the provided functions.xpm is not so informative. I made another one. Please see attached. If anyone wants to test it, just put it in images\math I have tested it at normal size and large size. It looks good at both size. I'd prefer something like f(x). Me too. Here's an example. Mael.attachment: Image 3.pngattachment: functions.xpm
RE: math toolbar usability suggestion (tiny)
Selon Leuven, E. [EMAIL PROTECTED]: What about an f(x) symbol? this suggests to me that there is an argument to give or a function to build, and i would expect it more on a toolbar to interface with maple etc (imho of course...) There is actually arguments to give when you insert such a function. I think it is clear enough that no computation will be made (LyX is for writing only). Mael.
Re: math toolbar usability suggestion (tiny)
On Friday 08 June 2007 16:24:52 Mael Hilléreau wrote: There is actually arguments to give when you insert such a function. I think it is clear enough that no computation will be made (LyX is for writing only). Mael. Oops, that is not correct. It can connect to a CAS (like maxima) and return the result of a mathematical expression. :-) -- José Abílio
Re: math toolbar usability suggestion (tiny)
hzluo schrieb: Current install version do not have an icon for functions popup. I think the patch is on the way. We now have a functions.xpm for that button. So you will have a 20x20 button instead of a long string. BTW, I think the provided functions.xpm is not so informative. I made another one. Please see attached. If anyone wants to test it, just put it in images\math I have tested it at normal size and large size. It looks good at both size. So does this mean the issue is resolved or will it be forgotten unless I file a bug? thanks, sven
Re: math toolbar usability suggestion (tiny)
Selon José Matos [EMAIL PROTECTED]: On Friday 08 June 2007 16:24:52 Mael Hilléreau wrote: There is actually arguments to give when you insert such a function. I think it is clear enough that no computation will be made (LyX is for writing only). Mael. Oops, that is not correct. It can connect to a CAS (like maxima) and return the result of a mathematical expression. :-) I apologize, I didn't know that (LyX is much powerful!). Anyway, IMHO f(x) may sound like function for many people. Perhaps a CAS icon may be chosen for computations... BTW what is the way to use CAS from LyX? Mael.
Re: math toolbar usability suggestion (tiny)
Sven Schreiber wrote: So does this mean the issue is resolved or will it be forgotten unless I file a bug? is resolved. Jürgen
RE: math toolbar usability suggestion (tiny)
> Current install version do not have an icon for functions popup. missing entry in scons_manifest and makefile i guess > BTW, I think the provided functions.xpm is not so informative. I made another > one. i like it. josé?
Re: math toolbar usability suggestion (tiny)
hzluo wrote: >>I am not sure I understand. Do the labels appear under the icons? Do >>we support that? >> >>JMarc > > Current install version do not have an icon for functions popup. > > I think the patch is on the way. > We now have a functions.xpm for that button. > So you will have a 20x20 button instead of a long string. > > BTW, I think the provided functions.xpm is not > so informative. I made another one. > Please see attached. If anyone wants to test > it, just put it in images\math > I have tested it at normal size and large size. > It looks good at both size. I'd prefer something like f(x). A/
Re: math toolbar usability suggestion (tiny)
I am not sure I understand. Do the labels appear under the icons? Do we support that? JMarc Current install version do not have an icon for functions popup. I think the patch is on the way. We now have a functions.xpm for that button. So you will have a 20x20 button instead of a long string. BTW, I think the provided functions.xpm is not so informative. I made another one. Please see attached. If anyone wants to test it, just put it in images\math I have tested it at normal size and large size. It looks good at both size. Hangzai functions.xpm Description: Binary data
Re: math toolbar usability suggestion (tiny)
> "Edwin" == Leuven, E <[EMAIL PROTECTED]> writes: >> Current install version do not have an icon for functions popup. Edwin> missing entry in scons_manifest and makefile i guess >> BTW, I think the provided functions.xpm is not so informative. I >> made another one. Edwin> i like it. I like it too. A small function graph might be adequate too. JMarc
RE: math toolbar usability suggestion (tiny)
> What about an "f(x)" symbol? this suggests to me that there is an argument to give or a function to build, and i would expect it more on a toolbar to interface with maple etc (imho of course...)
Re: math toolbar usability suggestion (tiny)
Selon Alfredo Braunstein <[EMAIL PROTECTED]>: > hzluo wrote: > > >>I am not sure I understand. Do the labels appear under the icons? Do > >>we support that? > >> > >>JMarc > > > > Current install version do not have an icon for functions popup. > > > > I think the patch is on the way. > > We now have a functions.xpm for that button. > > So you will have a 20x20 button instead of a long string. > > > > BTW, I think the provided functions.xpm is not > > so informative. I made another one. > > Please see attached. If anyone wants to test > > it, just put it in images\math > > I have tested it at normal size and large size. > > It looks good at both size. > > I'd prefer something like f(x). Me too. Mael.
Re: math toolbar usability suggestion (tiny)
IMHO, if you prefer to use "f" instead of real function names, I suggest to use a black (maybe also bold) "f" followed by a blue box. Or better, "fun" followed by a blue box (but then the button may be too wide for normal size, which is set to 20x20. Maybe "fn"?). But I still think "f" is less straightforward than real function names. - Original Message - From: "Mael Hilléreau" <[EMAIL PROTECTED]> To: "Leuven, E." <[EMAIL PROTECTED]> Cc: "Mael Hilléreau" <[EMAIL PROTECTED]>; "Jean-Marc Lasgouttes" <[EMAIL PROTECTED]>; "hzluo" <[EMAIL PROTECTED]>; "LyX Mechanics" <lyx-devel@lists.lyx.org> Sent: Friday, June 08, 2007 11:24 AM Subject: RE: math toolbar usability suggestion (tiny) Selon "Leuven, E." <[EMAIL PROTECTED]>: > What about an "f(x)" symbol? this suggests to me that there is an argument to give or a function to build, and i would expect it more on a toolbar to interface with maple etc (imho of course...) There is actually arguments to give when you insert such a function. I think it is clear enough that no computation will be made (LyX is for writing only). Mael.
Re: math toolbar usability suggestion (tiny)
Selon Mael Hilléreau <[EMAIL PROTECTED]>: > > > BTW, I think the provided functions.xpm is not > > > so informative. I made another one. > > > Please see attached. If anyone wants to test > > > it, just put it in images\math > > > I have tested it at normal size and large size. > > > It looks good at both size. > > > > I'd prefer something like f(x). > > Me too. Here's an example. Mael.<><>
RE: math toolbar usability suggestion (tiny)
Selon "Leuven, E." <[EMAIL PROTECTED]>: > > What about an "f(x)" symbol? > > this suggests to me that there is an argument to give or a function to build, > and i would expect it more on a toolbar to interface with maple etc (imho of > course...) There is actually arguments to give when you insert such a function. I think it is clear enough that no computation will be made (LyX is for writing only). Mael.
Re: math toolbar usability suggestion (tiny)
On Friday 08 June 2007 16:24:52 Mael Hilléreau wrote: > There is actually arguments to give when you insert such a function. I > think it is clear enough that no computation will be made (LyX is for > writing only). > > Mael. Oops, that is not correct. It can connect to a CAS (like maxima) and return the result of a mathematical expression. :-) -- José Abílio
Re: math toolbar usability suggestion (tiny)
hzluo schrieb: > Current install version do not have an icon for functions popup. > > I think the patch is on the way. > We now have a functions.xpm for that button. > So you will have a 20x20 button instead of a long string. > > BTW, I think the provided functions.xpm is not > so informative. I made another one. > Please see attached. If anyone wants to test > it, just put it in images\math > I have tested it at normal size and large size. > It looks good at both size. So does this mean the issue is resolved or will it be forgotten unless I file a bug? thanks, sven
Re: math toolbar usability suggestion (tiny)
Selon José Matos <[EMAIL PROTECTED]>: > On Friday 08 June 2007 16:24:52 Mael Hilléreau wrote: > > There is actually arguments to give when you insert such a function. I > > think it is clear enough that no computation will be made (LyX is for > > writing only). > > > > Mael. > > Oops, that is not correct. It can connect to a CAS (like maxima) and return > the result of a mathematical expression. :-) > I apologize, I didn't know that (LyX is much powerful!). Anyway, IMHO "f(x)" may sound like "function" for many people. Perhaps a "CAS" icon may be chosen for computations... BTW what is the way to use CAS from LyX? Mael.
Re: math toolbar usability suggestion (tiny)
Sven Schreiber wrote: > So does this mean the issue is resolved or will it be forgotten unless I > file a bug? is resolved. Jürgen
Re: Math toolbar translation
On Sat, Apr 21, 2007 at 08:51:58PM +0200, Edwin Leuven wrote: Edwin Leuven wrote: Edwin Leuven wrote: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match = no translation. the attached then? we should not add the backslash in qltoolbar, so what about the attached? and only the patch to stdtoolbars.inc should be necessary sigh, let's standardize on a single language to get rid of is translation business. i suggest dutch... +1 - Martin
Re: Math toolbar translation
On Sunday 22 April 2007 8:21:39 am Martin Vermeer wrote: sigh, let's standardize on a single language to get rid of is translation business. i suggest dutch... +1 Being a python fan is for me difficult to disagree. ;-) $ python -c 'import this' | grep -B1 Dutch There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. - Martin -- José Abílio
Re: Math toolbar translation
On Sat, Apr 21, 2007 at 08:51:58PM +0200, Edwin Leuven wrote: > Edwin Leuven wrote: > >Edwin Leuven wrote: > >>Michael Gerz wrote: > >>>The problem is the double \\ which is collapsed into a single > >>>\ somewhere in your code. However, in the po files we assume > >>>that the message has two \\ . Therefore, the internal message > >>>and the translation do not match => no translation. > >> > >>the attached then? > > > >we should not add the backslash in qltoolbar, so what about the > >attached? > > and only the patch to stdtoolbars.inc should be necessary > > sigh, let's standardize on a single language to get rid of is > translation business. > > i suggest dutch... +1 - Martin
Re: Math toolbar translation
On Sunday 22 April 2007 8:21:39 am Martin Vermeer wrote: > > > > sigh, let's standardize on a single language to get rid of is > > translation business. > > > > i suggest dutch... > > +1 Being a python fan is for me difficult to disagree. ;-) $ python -c 'import this' | grep -B1 Dutch There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. > - Martin -- José Abílio
Re: Math toolbar translation
Michael Gerz wrote:
Edwin,
I remerged the po files using scons. Afterwards, I saw hundreds of
entries like
#: lib/ui/stdtoolbars.inc:266
msgid Scriptscript (smaller) style\tscriptscriptstyle
msgstr Scriptscript-Stil (kleiner)\tscriptscriptstyle
However, the German translations are not shown in the math panel toolbar.
Any idea what goes wrong?
does the attached solve it?
am not a champ at this translation business (although i switch between
dutch, english and french on a daily basis)
maybe more knowledgeable people can chime in?
Index: src/frontends/qt4/QLToolbar.C
===
--- src/frontends/qt4/QLToolbar.C (revision 17893)
+++ src/frontends/qt4/QLToolbar.C (working copy)
@@ -220,11 +220,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it-func_).unknown()) {
+ docstring const label = _(to_utf8(it-label_));
Action * action = new Action(owner_,
getIcon(it-func_),
- it-label_,
+ label,
it-func_,
- it-label_);
+ label);
panel-addButton(action);
ActionVector.push_back(action);
// use the icon of first action for the toolbar
button
@@ -254,11 +255,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it-func_).unknown()) {
+ docstring const label = _(to_utf8(it-label_));
Action * action = new Action(owner_,
getIcon(it-func_, false),
- it-label_,
+ label,
it-func_,
- it-label_);
+ label);
m-add(action);
ActionVector.push_back(action);
}
Re: Math toolbar translation
Edwin Leuven schrieb: Michael Gerz wrote: Edwin, I remerged the po files using scons. Afterwards, I saw hundreds of entries like #: lib/ui/stdtoolbars.inc:266 msgid Scriptscript (smaller) style\tscriptscriptstyle msgstr Scriptscript-Stil (kleiner)\tscriptscriptstyle However, the German translations are not shown in the math panel toolbar. Any idea what goes wrong? does the attached solve it? No, sorry. BTW: I have no problems with regular toolbars. Only the math panel toolbar is not translated. Michael
Re: Math toolbar translation
Michael Gerz schrieb: Edwin, I remerged the po files using scons. Afterwards, I saw hundreds of entries like #: lib/ui/stdtoolbars.inc:266 msgid Scriptscript (smaller) style\tscriptscriptstyle msgstr Scriptscript-Stil (kleiner)\tscriptscriptstyle However, the German translations are not shown in the math panel toolbar. The problem seems to be related to the number of backslashes. In stdtoolbar.inc, there are entries like Item Standard \\frac math-insert \frac The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match = no translation. Michael
Re: Math toolbar translation
Michael Gerz wrote:
The problem is the double \\ which is collapsed into a single \
somewhere in your code. However, in the po files we assume that the
message has two \\ . Therefore, the internal message and the translation
do not match = no translation.
the attached then?
Index: src/frontends/qt4/QLToolbar.C
===
--- src/frontends/qt4/QLToolbar.C (revision 17893)
+++ src/frontends/qt4/QLToolbar.C (working copy)
@@ -220,11 +220,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it-func_).unknown()) {
+ docstring const label = _(to_utf8(it-label_));
Action * action = new Action(owner_,
getIcon(it-func_),
- it-label_,
+ label,
it-func_,
- it-label_);
+ label);
panel-addButton(action);
ActionVector.push_back(action);
// use the icon of first action for the toolbar
button
@@ -254,11 +255,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it-func_).unknown()) {
+ docstring const label = _(string(\\) +
to_utf8(it-label_));
Action * action = new Action(owner_,
getIcon(it-func_, false),
- it-label_,
+ label,
it-func_,
- it-label_);
+ label);
m-add(action);
ActionVector.push_back(action);
}
Re: Math toolbar translation
Edwin Leuven wrote: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match = no translation. the attached then? we should not add the backslash in qltoolbar, so what about the attached? Index: lib/ui/stdtoolbars.inc === --- lib/ui/stdtoolbars.inc (revision 17893) +++ lib/ui/stdtoolbars.inc (working copy) @@ -289,498 +289,498 @@ End Toolbar latex_dots Dots - Item ldots math-insert \ldots - Item cdots math-insert \cdots - Item vdots math-insert \vdots - Item ddots math-insert \ddots + Item \\ldots math-insert \ldots + Item \\cdots math-insert \cdots + Item \\vdots math-insert \vdots + Item \\ddots math-insert \ddots End Toolbar latex_deco Frame Decorations - Item widehat math-insert \widehat - Item widetilde math-insert \widetilde - Item overbrace math-insert \overbrace - Item overleftarrow math-insert \overleftarrow - Item overrightarrow math-insert \overrightarrow - Item overline math-insert \overline - Item underbrace math-insert \underbrace - Item underline math-insert \underline - Item underleftarrow math-insert \underleftarrow - Item underrightarrow math-insert \underrightarrow - Item underleftrightarrow math-insert \underleftrightarrow - Item overleftrightarrow math-insert \overleftrightarrow - Item hat math-insert \hat - Item acute math-insert \acute - Item bar math-insert \bar - Item dot math-insert \dot - Item check math-insert \check - Item grave math-insert \grave - Item vec math-insert \vec - Item ddot math-insert \ddot - Item breve math-insert \breve - Item tilde math-insert \tilde - Item overset math-insert \overset - Item underset math-insert \underset + Item \\widehat math-insert \widehat + Item \\widetilde math-insert \widetilde + Item \\overbrace math-insert \overbrace + Item \\overleftarrow math-insert \overleftarrow + Item \\overrightarrow math-insert \overrightarrow + Item \\overline math-insert \overline + Item \\underbrace math-insert \underbrace + Item \\underline math-insert \underline + Item \\underleftarrow math-insert \underleftarrow + Item \\underrightarrow math-insert \underrightarrow + Item \\underleftrightarrow math-insert \underleftrightarrow + Item \\overleftrightarrow math-insert \overleftrightarrow + Item \\hat math-insert \hat + Item \\acute math-insert \acute + Item \\bar math-insert \bar + Item \\dot math-insert \dot + Item \\check math-insert \check + Item \\grave math-insert \grave + Item \\vec math-insert \vec + Item \\ddot math-insert \ddot + Item \\breve math-insert \breve + Item \\tilde math-insert \tilde + Item \\overset math-insert \overset + Item \\underset math-insert \underset End Toolbar latex_arrow Arrows - Item leftarrow math-insert \leftarrow - Item rightarrow math-insert \rightarrow - Item downarrow math-insert \downarrow - Item uparrow math-insert \uparrow - Item updownarrow math-insert \updownarrow - Item leftrightarrow math-insert \leftrightarrow - Item Leftarrow math-insert \Leftarrow - Item Rightarrow math-insert \Rightarrow - Item Downarrow math-insert \Downarrow - Item Uparrow math-insert \Uparrow - Item Updownarrow math-insert \Updownarrow - Item Leftrightarrow math-insert \Leftrightarrow - Item Longleftrightarrow math-insert \Longleftrightarrow - Item Longleftarrow math-insert \Longleftarrow - Item Longrightarrow math-insert \Longrightarrow - Item longleftrightarrow math-insert \longleftrightarrow - Item longleftarrow math-insert \longleftarrow - Item longrightarrow math-insert \longrightarrow - Item leftharpoondown math-insert \leftharpoondown - Item rightharpoondown math-insert \rightharpoondown - Item mapsto math-insert \mapsto - Item
Re: Math toolbar translation
Edwin Leuven wrote: Edwin Leuven wrote: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match = no translation. the attached then? we should not add the backslash in qltoolbar, so what about the attached? and only the patch to stdtoolbars.inc should be necessary sigh, let's standardize on a single language to get rid of is translation business. i suggest dutch...
Re: Math toolbar translation
Edwin Leuven schrieb: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match = no translation. the attached then? Wait a minute. This is an excerpt of the current stdtoolbars.inc Toolbar style Styles Item Display style \\displaystyle math-insert \displaystyle Item Normal text style \\textstyle math-insert \textstyle Item Script (small) style \\scriptstyle math-insert \scriptstyle Item Scriptscript (smaller) style \\scriptscriptstyle math-insert \scriptscriptstyle End Why do we need a double \\ in the label but only single \ in the command? Can't we find a solution where a backslash is represented by a single \ ? Michael
Re: Math toolbar translation
Michael Gerz wrote:
Edwin,
I remerged the po files using scons. Afterwards, I saw hundreds of
entries like
#: lib/ui/stdtoolbars.inc:266
msgid "Scriptscript (smaller) style\tscriptscriptstyle"
msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle"
However, the German translations are not shown in the math panel toolbar.
Any idea what goes wrong?
does the attached solve it?
am not a champ at this translation business (although i switch between
dutch, english and french on a daily basis)
maybe more knowledgeable people can chime in?
Index: src/frontends/qt4/QLToolbar.C
===
--- src/frontends/qt4/QLToolbar.C (revision 17893)
+++ src/frontends/qt4/QLToolbar.C (working copy)
@@ -220,11 +220,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it->func_).unknown()) {
+ docstring const label = _(to_utf8(it->label_));
Action * action = new Action(owner_,
getIcon(it->func_),
- it->label_,
+ label,
it->func_,
- it->label_);
+ label);
panel->addButton(action);
ActionVector.push_back(action);
// use the icon of first action for the toolbar
button
@@ -254,11 +255,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it->func_).unknown()) {
+ docstring const label = _(to_utf8(it->label_));
Action * action = new Action(owner_,
getIcon(it->func_, false),
- it->label_,
+ label,
it->func_,
- it->label_);
+ label);
m->add(action);
ActionVector.push_back(action);
}
Re: Math toolbar translation
Edwin Leuven schrieb: Michael Gerz wrote: Edwin, I remerged the po files using scons. Afterwards, I saw hundreds of entries like #: lib/ui/stdtoolbars.inc:266 msgid "Scriptscript (smaller) style\tscriptscriptstyle" msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle" However, the German translations are not shown in the math panel toolbar. Any idea what goes wrong? does the attached solve it? No, sorry. BTW: I have no problems with regular toolbars. Only the math panel toolbar is not translated. Michael
Re: Math toolbar translation
Michael Gerz schrieb: Edwin, I remerged the po files using scons. Afterwards, I saw hundreds of entries like #: lib/ui/stdtoolbars.inc:266 msgid "Scriptscript (smaller) style\tscriptscriptstyle" msgstr "Scriptscript-Stil (kleiner)\tscriptscriptstyle" However, the German translations are not shown in the math panel toolbar. The problem seems to be related to the number of backslashes. In stdtoolbar.inc, there are entries like Item "Standard \\frac" "math-insert \frac" The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match => no translation. Michael
Re: Math toolbar translation
Michael Gerz wrote:
The problem is the double \\ which is collapsed into a single \
somewhere in your code. However, in the po files we assume that the
message has two \\ . Therefore, the internal message and the translation
do not match => no translation.
the attached then?
Index: src/frontends/qt4/QLToolbar.C
===
--- src/frontends/qt4/QLToolbar.C (revision 17893)
+++ src/frontends/qt4/QLToolbar.C (working copy)
@@ -220,11 +220,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it->func_).unknown()) {
+ docstring const label = _(to_utf8(it->label_));
Action * action = new Action(owner_,
getIcon(it->func_),
- it->label_,
+ label,
it->func_,
- it->label_);
+ label);
panel->addButton(action);
ActionVector.push_back(action);
// use the icon of first action for the toolbar
button
@@ -254,11 +255,12 @@
ToolbarInfo::item_iterator const end = tbb.items.end();
for (; it != end; ++it)
if (!lyx::getStatus(it->func_).unknown()) {
+ docstring const label = _(string("\\") +
to_utf8(it->label_));
Action * action = new Action(owner_,
getIcon(it->func_, false),
- it->label_,
+ label,
it->func_,
- it->label_);
+ label);
m->add(action);
ActionVector.push_back(action);
}
Re: Math toolbar translation
Edwin Leuven wrote: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match => no translation. the attached then? we should not add the backslash in qltoolbar, so what about the attached? Index: lib/ui/stdtoolbars.inc === --- lib/ui/stdtoolbars.inc (revision 17893) +++ lib/ui/stdtoolbars.inc (working copy) @@ -289,498 +289,498 @@ End Toolbar "latex_dots" "Dots" - Item "ldots" "math-insert \ldots" - Item "cdots" "math-insert \cdots" - Item "vdots" "math-insert \vdots" - Item "ddots" "math-insert \ddots" + Item "\\ldots" "math-insert \ldots" + Item "\\cdots" "math-insert \cdots" + Item "\\vdots" "math-insert \vdots" + Item "\\ddots" "math-insert \ddots" End Toolbar "latex_deco" "Frame Decorations" - Item "widehat" "math-insert \widehat" - Item "widetilde" "math-insert \widetilde" - Item "overbrace" "math-insert \overbrace" - Item "overleftarrow" "math-insert \overleftarrow" - Item "overrightarrow" "math-insert \overrightarrow" - Item "overline" "math-insert \overline" - Item "underbrace" "math-insert \underbrace" - Item "underline" "math-insert \underline" - Item "underleftarrow" "math-insert \underleftarrow" - Item "underrightarrow" "math-insert \underrightarrow" - Item "underleftrightarrow" "math-insert \underleftrightarrow" - Item "overleftrightarrow" "math-insert \overleftrightarrow" - Item "hat" "math-insert \hat" - Item "acute" "math-insert \acute" - Item "bar" "math-insert \bar" - Item "dot" "math-insert \dot" - Item "check" "math-insert \check" - Item "grave" "math-insert \grave" - Item "vec" "math-insert \vec" - Item "ddot" "math-insert \ddot" - Item "breve" "math-insert \breve" - Item "tilde" "math-insert \tilde" - Item "overset" "math-insert \overset" - Item "underset" "math-insert \underset" + Item "\\widehat" "math-insert \widehat" + Item "\\widetilde" "math-insert \widetilde" + Item "\\overbrace" "math-insert \overbrace" + Item "\\overleftarrow" "math-insert \overleftarrow" + Item "\\overrightarrow" "math-insert \overrightarrow" + Item "\\overline" "math-insert \overline" + Item "\\underbrace" "math-insert \underbrace" + Item "\\underline" "math-insert \underline" + Item "\\underleftarrow" "math-insert \underleftarrow" + Item "\\underrightarrow" "math-insert \underrightarrow" + Item "\\underleftrightarrow" "math-insert \underleftrightarrow" + Item "\\overleftrightarrow" "math-insert \overleftrightarrow" + Item "\\hat" "math-insert \hat" + Item "\\acute" "math-insert \acute" + Item "\\bar" "math-insert \bar" + Item "\\dot" "math-insert \dot" + Item "\\check" "math-insert \check" + Item "\\grave" "math-insert \grave" + Item "\\vec" "math-insert \vec" + Item "\\ddot" "math-insert \ddot" + Item "\\breve" "math-insert \breve" + Item "\\tilde" "math-insert \tilde" + Item "\\overset" "math-insert \overset" + Item "\\underset" "math-insert \underset" End Toolbar "latex_arrow" "Arrows" - Item "leftarrow" "math-insert \leftarrow" - Item "rightarrow" "math-insert \rightarrow" - Item "downarrow" "math-insert \downarrow" - Item "uparrow" "math-insert \uparrow" - Item "updownarrow" "math-insert \updownarrow" - Item "leftrightarrow" "math-insert \leftrightarrow" - Item "Leftarrow" "math-insert \Leftarrow" - Item "Rightarrow" "math-insert \Rightarrow" - Item "Downarrow" "math-insert \Downarrow" - Item "Uparrow" "math-insert \Uparrow" - Item "Updownarrow" "math-insert \Updownarrow" - Item "Leftrightarrow" "math-insert \Leftrightarrow" - Item "Longleftrightarrow" "math-insert \Longleftrightarrow" - Item "Longleftarrow" "math-insert \Longleftarrow" - Item "Longrightarrow" "math-insert \Longrightarrow" - Item "longleftrightarrow" "math-insert \longleftrightarrow" - Item
Re: Math toolbar translation
Edwin Leuven wrote: Edwin Leuven wrote: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match => no translation. the attached then? we should not add the backslash in qltoolbar, so what about the attached? and only the patch to stdtoolbars.inc should be necessary sigh, let's standardize on a single language to get rid of is translation business. i suggest dutch...
Re: Math toolbar translation
Edwin Leuven schrieb: Michael Gerz wrote: The problem is the double \\ which is collapsed into a single \ somewhere in your code. However, in the po files we assume that the message has two \\ . Therefore, the internal message and the translation do not match => no translation. the attached then? Wait a minute. This is an excerpt of the current stdtoolbars.inc Toolbar "style" "Styles" Item "Display style \\displaystyle" "math-insert \displaystyle" Item "Normal text style \\textstyle" "math-insert \textstyle" Item "Script (small) style \\scriptstyle" "math-insert \scriptstyle" Item "Scriptscript (smaller) style \\scriptscriptstyle" "math-insert \scriptscriptstyle" End Why do we need a double \\ in the label but only single \ in the command? Can't we find a solution where a backslash is represented by a single \ ? Michael
Re: Math Toolbar patch
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Attached is a patch doing this and fixing the other bugs I Angus discovered. It does not implement the math toolbar at all and Angus can be applied now. Please do so! I am in the process of applying it. JMarc
Re: Math Toolbar patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Attached is a patch doing this and fixing the other bugs I Angus> discovered. It does not implement the math toolbar at all and Angus> can be applied now. Please do so! I am in the process of applying it. JMarc
Re: Math Toolbar patch
Thanks everybody for the feedback. Point 1, for Lars: this IS almost generic. At least as a first attempt it ain't far off. And for this, I think you/I must extend a special thank you to Jean-Marc for creating such a general toolbar code. Even if toolbarItem should be a base class so that combox and FL_OBJECTs can exist in the same list... In order to make the stuff completely generic, I think the following points need to be addressed: * How to associate Toolbar definitions in default.ui with particular insets? Something like Toolbar text ... End Toolbar math ... End springs to mind. * This would allow the signals to be replaced with showToolbar(name), hideToolbar(name). * Finally, the Layout definition in default.ui should be replaced with DropdownList layout. Point 2, for Lars: You are removing some of the boundires... LyXView knows about BufferView which knows about WorkArea, LyXView is not supposed to know anything about WorkArea. (and if it already does, that can be considered a bug) Well then, why have a publically accessible WorkArea * workarea() in BufferView.h? But I agree with you! The only things accessing BufferView::workarea() are the new stuff in LyXView that call width(), height(), xpos(), ypos() and insettext, insettabular that call getClipboard() Shall I add some wrappers for these calls to BufferView? Point 3, for Dekel, Allan. The flicker is annoying isn't it! If we're thinking of multiple toolbars with only one present at a time, how about: A common toolbar, always present Toolbar Common DropdownList layouts Icon file-open Icon buffer-write Icon buffer-print End If text is marked, then show this to the right of Toolbar Common Toolbar CutPaste Icon cut Icon copy Icon paste End If in a text inset then this would go to the right of Common or CutPaste: Toolbar Text Icon font-emph Icon font-noun Icon font-free Separator Icon tex-mode Separator Icon depth-next Separator Icon math-insert Icon footnote-insert Icon marginalnote-insert Icon figure-insert Icon tabular-insert End If in a math inset Toolbar Math DropdownList functions Icon math-insert sqrt Icon math-insert frac ... End Shall I have a go at this next time I find a spare couple of hours? Angus
Re: Math Toolbar patch
Angus Leeming [EMAIL PROTECTED] writes: | Thanks everybody for the feedback. | | Point 1, for Lars: | this IS almost generic. At least as a first attempt it ain't far | off. I realize that, and I think we should go all the way from the beginning. | And for | this, I think you/I must extend a special thank you to Jean-Marc for creating| such |a general toolbar code. Even if toolbarItem should be a base class so | that combox and FL_OBJECTs can exist in the same list... I think I am going to thank my self as well. But you are right the Toolbard handling has turned out pretty nice. | In order to make the stuff completely generic, I think the following points | need to be addressed: | * How to associate Toolbar definitions in default.ui with particular insets? | Something like | Toolbar text | ... | End | Toolbar math | ... | End | springs to mind. looks ok to me. | * This would allow the signals to be replaced with showToolbar(name), | hideToolbar(name). | * Finally, the Layout definition in default.ui should be replaced with | DropdownList layout. mmm | Point 2, for Lars: | You are removing some of the boundires... LyXView knows about | BufferView which knows about WorkArea, LyXView is not supposed to know | anything about WorkArea. (and if it already does, that can be | considered a bug) | | Well then, why have a publically accessible WorkArea * workarea() in | BufferView.h? But I agree with you! | The only things accessing BufferView::workarea() are the new stuff in LyXView | that call | width(), height(), xpos(), ypos() | and insettext, insettabular that call | getClipboard() | | Shall I add some wrappers for these calls to BufferView? please do. (and in a separate from the toolbar patch please) | Point 3, for Dekel, Allan. | The flicker is annoying isn't it! Can we avoid this by locking the xforms forms/object? -- Lgb
Re: Math Toolbar patch
On Friday 27 April 2001 10:56, Lars Gullik Bjønnes wrote: | Well then, why have a publically accessible WorkArea * workarea() in | BufferView.h? But I agree with you! | The only things accessing BufferView::workarea() are the new stuff in LyXView | that call | width(), height(), xpos(), ypos() | and insettext, insettabular that call | getClipboard() | | Shall I add some wrappers for these calls to BufferView? please do. (and in a separate from the toolbar patch please) Attached is a patch doing this and fixing the other bugs I discovered. It does not implement the math toolbar at all and can be applied now. Please do so! Angus smallbugfixes.patch.bz2
Re: Math Toolbar patch
Thanks everybody for the feedback.
Point 1, for Lars:
this IS almost generic. At least as a first attempt it ain't far off. And for
this, I think you/I must extend a special thank you to Jean-Marc for creating
such a general toolbar code. Even if toolbarItem should be a base class so
that combox and FL_OBJECTs can exist in the same list...
In order to make the stuff completely generic, I think the following points
need to be addressed:
* How to associate Toolbar definitions in default.ui with particular insets?
Something like
Toolbar "text"
...
End
Toolbar "math"
...
End
springs to mind.
* This would allow the signals to be replaced with showToolbar("name"),
hideToolbar("name").
* Finally, the Layout definition in default.ui should be replaced with
DropdownList "layout".
Point 2, for Lars:
> You are removing some of the boundires... LyXView knows about
> BufferView which knows about WorkArea, LyXView is not supposed to know
> anything about WorkArea. (and if it already does, that can be
> considered a bug)
Well then, why have a publically accessible WorkArea * workarea() in
BufferView.h? But I agree with you!
The only things accessing BufferView::workarea() are the new stuff in LyXView
that call
width(), height(), xpos(), ypos()
and insettext, insettabular that call
getClipboard()
Shall I add some wrappers for these calls to BufferView?
Point 3, for Dekel, Allan.
The flicker is annoying isn't it!
If we're thinking of multiple toolbars with only one present at a time, how
about:
A common toolbar, always present
Toolbar "Common"
DropdownList "layouts"
Icon "file-open"
Icon "buffer-write"
Icon "buffer-print"
End
If text is marked, then show this to the right of Toolbar "Common"
Toolbar "Cut"
Icon "cut"
Icon "copy"
Icon "paste"
End
If in a text inset then this would go to the right of Common or Cut:
Toolbar "Text"
Icon "font-emph"
Icon "font-noun"
Icon "font-free"
Separator
Icon "tex-mode"
Separator
Icon "depth-next"
Separator
Icon "math-insert"
Icon "footnote-insert"
Icon "marginalnote-insert"
Icon "figure-insert"
Icon "tabular-insert"
End
If in a math inset
Toolbar "Math"
DropdownList "functions"
Icon "math-insert sqrt"
Icon "math-insert frac"
...
End
Shall I have a go at this next time I find a spare couple of hours?
Angus
Re: Math Toolbar patch
Angus Leeming <[EMAIL PROTECTED]> writes:
| Thanks everybody for the feedback.
|
| Point 1, for Lars:
| this IS almost generic. At least as a first attempt it ain't far
| off.
I realize that, and I think we should go all the way from the beginning.
| And for
| this, I think you/I must extend a special thank you to Jean-Marc for creating| such
|a general toolbar code. Even if toolbarItem should be a base class so
| that combox and FL_OBJECTs can exist in the same list...
I think I am going to thank my self as well. But you are right the
Toolbard handling has turned out pretty nice.
| In order to make the stuff completely generic, I think the following points
| need to be addressed:
| * How to associate Toolbar definitions in default.ui with particular insets?
| Something like
| Toolbar "text"
| ...
| End
| Toolbar "math"
| ...
| End
| springs to mind.
looks ok to me.
| * This would allow the signals to be replaced with showToolbar("name"),
| hideToolbar("name").
| * Finally, the Layout definition in default.ui should be replaced with
| DropdownList "layout".
mmm
| Point 2, for Lars:
| > You are removing some of the boundires... LyXView knows about
| > BufferView which knows about WorkArea, LyXView is not supposed to know
| > anything about WorkArea. (and if it already does, that can be
| > considered a bug)
|
| Well then, why have a publically accessible WorkArea * workarea() in
| BufferView.h? But I agree with you!
| The only things accessing BufferView::workarea() are the new stuff in LyXView
| that call
| width(), height(), xpos(), ypos()
| and insettext, insettabular that call
| getClipboard()
|
| Shall I add some wrappers for these calls to BufferView?
please do. (and in a separate from the toolbar patch please)
| Point 3, for Dekel, Allan.
| The flicker is annoying isn't it!
Can we avoid this by locking the xforms forms/object?
--
Lgb
Re: Math Toolbar patch
On Friday 27 April 2001 10:56, Lars Gullik Bjønnes wrote: > | Well then, why have a publically accessible WorkArea * workarea() in > | BufferView.h? But I agree with you! > | The only things accessing BufferView::workarea() are the new stuff in LyXView > | that call > | width(), height(), xpos(), ypos() > | and insettext, insettabular that call > | getClipboard() > | > | Shall I add some wrappers for these calls to BufferView? > > please do. (and in a separate from the toolbar patch please) Attached is a patch doing this and fixing the other bugs I discovered. It does not implement the math toolbar at all and can be applied now. Please do so! Angus smallbugfixes.patch.bz2
Re: Math Toolbar
On Wed, 25 Apr 2001, Angus Leeming wrote: The question is, where's the right place to emit the signals showMathToolbar hideMathToolbar I can't answer your question, but perhaps the signal should be a little more general, so it could be expanded for other types of insets etc. like we were discussing some time ago. I'd prefer something like enteredRegion(RegionType) ... then we can connect whatever we like that might care about such a thing ... what do you think ? thanks john -- And they made their father drink wine that night: and the firstborn went in, and lay with her father; and he perceived not when she lay down, nor when she arose. - Genesis 19:33
Re: Math Toolbar
On Wed, Apr 25, 2001 at 03:40:59PM +0100, Angus Leeming wrote: Sorry for the long silence; work has been v. busy recently and this isn't likely to change for a while... Anyway, in a few minutes of free time, I've been trying to build the bones of a Math Toolbar. The idea is that the Toolbar should become visible when an InsetFormula becomes active and that it should disappear again when the InsetFormula becomes inactive. The question is, where's the right place to emit the signals showMathToolbar hideMathToolbar I'd guess that BufferView::Pimpl::workAreaButtonPress BufferView::Pimpl::workAreaButtonRelease would be right, but what about using the arrow keys to just move the cursor into the InsetFormula? I think you need InsetFormula::Edit InsetFormula::InsetUnlock However, I prefer to always keep the math toolbar open (as the interface change when entering/leaving a formula might be annoying). so I guess that the behaviour should be controllable by default.ui
Re: Math Toolbar patch
On Thu, Apr 26, 2001 at 08:58:42PM +0100, Angus Leeming wrote: Attached is a patch creating a Math Toolbar. I'm posting it, rather than commiting it to the repository because I discovered what I think are a couple of bugs in WorkArea and in ToolbarDefaults, but am not very familiar with the code, so think I should seek a second opinion... Nice. However, as I suspected, the workarea resizing is annoying: when you enter/leave a math inset, the screen flickers - it seems that the screen is redrawn more than once. How about making the math toolbar replace some of the icon in the standard toolbar (e.g. the font icons, figure/tabular/footnote insertion) so you won't need to resize the workarea ?
Re: Math Toolbar patch
Angus Leeming [EMAIL PROTECTED] writes: | WorkArea's (width, height, xpos, ypos) returned the dimensions of something | in between the work_area FL_OBJECT and the entire space taken up by WorkArea. | I think that this is wrong and have changed them to return the dimensions of | the entire WorkArea. As the only places these methods are called are in the | new LyXView::showMathToolbar, hideMathToolbar methods, I think I'm safe, | but... You are removing some of the boundires... LyXView knows about BufferView which knows about WorkArea, LyXView is not supposed to know anything about WorkArea. (and if it already does, that can be considered a bug) I must also say that a special solution for Math is not completely to my liking. IMHO it should have been a generic solution to add toolbars of any kind, even the existing one. (Handling in LyXView) -- Lgb
Re: Math Toolbar patch
On Fri, 27 Apr 2001, Dekel Tsur wrote: On Thu, Apr 26, 2001 at 08:58:42PM +0100, Angus Leeming wrote: Attached is a patch creating a Math Toolbar. I'm posting it, rather than commiting it to the repository because I discovered what I think are a couple of bugs in WorkArea and in ToolbarDefaults, but am not very familiar with the code, so think I should seek a second opinion... Nice. However, as I suspected, the workarea resizing is annoying: when you enter/leave a math inset, the screen flickers - it seems that the screen is redrawn more than once. Ideally the resizing should just cause the workarea to crop the top of its display and keep the rest of the drawing. This should be croppable at any pixel height but I'm nort sure how that will affect the workareas idea of a current row. There wouldn't be any flicker then apart from the magical appearance of the math toolbar. How about making the math toolbar replace some of the icon in the standard toolbar (e.g. the font icons, figure/tabular/footnote insertion) so you won't need to resize the workarea ? Or just replace one toolbar with the other. The general toolbar isn't much use in math anyway. The 4 general toolbar buttons that are useful in math mode should just be repeated in the math toolbars definition. This gets us to the idea of rotating toolbars -- like those available in Ami Pro all those wonderful years ago, or in Blender or like James Bond's car number plates. Then you just need to define a rotate toolbar icon that displays the icon of the toolbar you would switch to when you hold down a mouse button and move the mouse cursor. Blender style. Or use a small menu to list the names of the toolbars you can switch to. Ami Pro style. You wouldn't normally need to force the change to a different toolbar until we start offering the user multiple custom toolbars to choose from. FWIW: Signal1string const , void showToolbar; You don't really need a hideToolbar(string) although some implementations might want to allow several toolbars to clutter up the screen even though some aren't useful until you are within an appropriate environment. KLyX is a good example of this in the Linux world. Or Word in the Dark Universe. Math or general text inside tables would require at most two toolbars: table + maths table + general that is, one outer-context sensitive toolbar and one inner-context. You could also consider the rotated toolbars as being placed on a stack and thereby just: Signal0void popToolbar; Although this may not work if the user jumps around their document using the mouse. I don't think keyboard interaction could trick the stack. Allan. (ARRae)
Re: Math Toolbar
On Thursday 26 April 2001 14:03, Dekel Tsur wrote: I think you need InsetFormula::Edit InsetFormula::InsetUnlock Indeed. I got there by a process of trial and error. However, I prefer to always keep the math toolbar open (as the interface change when entering/leaving a formula might be annoying). so I guess that the behaviour should be controllable by default.ui Well, this is all very much work-in-progress. It'll be very easy to wrap an if-statement around the mathtoolbar-show() and mathtoolbar-hide() commands in LyXView. A
Re: Math Toolbar
On Wed, 25 Apr 2001, Angus Leeming wrote: > The question is, where's the right place to emit the signals > showMathToolbar > hideMathToolbar I can't answer your question, but perhaps the signal should be a little more general, so it could be expanded for other types of insets etc. like we were discussing some time ago. I'd prefer something like enteredRegion(RegionType) ... then we can connect whatever we like that might care about such a thing ... what do you think ? thanks john -- "And they made their father drink wine that night: and the firstborn went in, and lay with her father; and he perceived not when she lay down, nor when she arose." - Genesis 19:33
Re: Math Toolbar
On Wed, Apr 25, 2001 at 03:40:59PM +0100, Angus Leeming wrote: > Sorry for the long silence; work has been v. busy recently and this isn't > likely to change for a while... > > Anyway, in a few minutes of free time, I've been trying to build the bones of > a Math Toolbar. The idea is that the Toolbar should become visible when an > InsetFormula becomes active and that it should disappear again when the > InsetFormula becomes inactive. > > The question is, where's the right place to emit the signals > showMathToolbar > hideMathToolbar > > I'd guess that > BufferView::Pimpl::workAreaButtonPress > BufferView::Pimpl::workAreaButtonRelease > would be right, but what about using the arrow keys to just move the cursor > into the InsetFormula? I think you need InsetFormula::Edit InsetFormula::InsetUnlock However, I prefer to always keep the math toolbar open (as the interface change when entering/leaving a formula might be annoying). so I guess that the behaviour should be controllable by default.ui
Re: Math Toolbar patch
On Thu, Apr 26, 2001 at 08:58:42PM +0100, Angus Leeming wrote: > Attached is a patch creating a Math Toolbar. I'm posting it, rather than > commiting it to the repository because I discovered what I think are a couple > of bugs in WorkArea and in ToolbarDefaults, but am not very familiar with the > code, so think I should seek a second opinion... Nice. However, as I suspected, the workarea resizing is annoying: when you enter/leave a math inset, the screen flickers - it seems that the screen is redrawn more than once. How about making the math toolbar replace some of the icon in the standard toolbar (e.g. the font icons, figure/tabular/footnote insertion) so you won't need to resize the workarea ?
Re: Math Toolbar patch
Angus Leeming <[EMAIL PROTECTED]> writes: | WorkArea's (width, height, xpos, ypos) returned the dimensions of something | in between the work_area FL_OBJECT and the entire space taken up by WorkArea. | I think that this is wrong and have changed them to return the dimensions of | the entire WorkArea. As the only places these methods are called are in the | new LyXView::showMathToolbar, hideMathToolbar methods, I think I'm safe, | but... You are removing some of the boundires... LyXView knows about BufferView which knows about WorkArea, LyXView is not supposed to know anything about WorkArea. (and if it already does, that can be considered a bug) I must also say that a special solution for Math is not completely to my liking. IMHO it should have been a "generic" solution to add toolbars of any kind, even the existing one. (Handling in LyXView) -- Lgb
Re: Math Toolbar patch
On Fri, 27 Apr 2001, Dekel Tsur wrote: > On Thu, Apr 26, 2001 at 08:58:42PM +0100, Angus Leeming wrote: > > Attached is a patch creating a Math Toolbar. I'm posting it, rather than > > commiting it to the repository because I discovered what I think are a couple > > of bugs in WorkArea and in ToolbarDefaults, but am not very familiar with the > > code, so think I should seek a second opinion... > > Nice. However, as I suspected, the workarea resizing is annoying: when > you enter/leave a math inset, the screen flickers - it seems that the > screen is redrawn more than once. Ideally the resizing should just cause the workarea to crop the top of its display and keep the rest of the drawing. This should be "croppable" at any pixel height but I'm nort sure how that will affect the workareas idea of a current row. There wouldn't be any flicker then apart from the magical appearance of the math toolbar. > How about making the math toolbar replace some of the icon in the standard > toolbar (e.g. the font icons, figure/tabular/footnote insertion) > so you won't need to resize the workarea ? Or just replace one toolbar with the other. The general toolbar isn't much use in math anyway. The 4 general toolbar buttons that are useful in math mode should just be repeated in the math toolbars definition. This gets us to the idea of rotating toolbars -- like those available in Ami Pro all those wonderful years ago, or in Blender or like James Bond's car number plates. Then you just need to define a "rotate toolbar" icon that displays the icon of the toolbar you would switch to when you hold down a mouse button and move the mouse cursor. Blender style. Or use a small menu to list the names of the toolbars you can switch to. Ami Pro style. You wouldn't normally need to force the change to a different toolbar until we start offering the user multiple custom toolbars to choose from. FWIW: Signal1 showToolbar; You don't really need a hideToolbar(string) although some implementations might want to allow several toolbars to clutter up the screen even though some aren't useful until you are within an appropriate environment. KLyX is a good example of this in the Linux world. Or Word in the Dark Universe. Math or general text inside tables would require at most two toolbars: table + maths table + general that is, one outer-context sensitive toolbar and one inner-context. You could also consider the rotated toolbars as being placed on a stack and thereby just: Signal0 popToolbar; Although this may not work if the user jumps around their document using the mouse. I don't think keyboard interaction could trick the stack. Allan. (ARRae)
Re: Math Toolbar
On Thursday 26 April 2001 14:03, Dekel Tsur wrote: > > I think you need > InsetFormula::Edit > InsetFormula::InsetUnlock Indeed. I got there by a process of trial and error. > However, I prefer to always keep the math toolbar open > (as the interface change when entering/leaving a formula might be annoying). > so I guess that the behaviour should be controllable by default.ui Well, this is all very much work-in-progress. It'll be very easy to wrap an if-statement around the mathtoolbar->show() and mathtoolbar->hide() commands in LyXView. A
