Math Toolbar
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? As you can see, I know very little about how all this is controlled; be gentle, please! Angus
Math toolbar translation
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? Michael
1.5b2 math toolbar?
Sorry, I haven't been following the discussion. I don't see any math toolbar. Am I missing something?
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
Math Toolbar patch
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... 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... ToolbarDefaults::read had a final lex.next() call that buggered up the reading of subsequent Toolbar definitions. Removing it fixed the bug. Other than thses points, the patch is pretty straight forward. It shows, hides a Math Toolbar when the cursor enters, leaves an InsetFormula and resizes the WorkArea appropriately. The Tolbar currently contains only a sqrt and a frac, but the functionality is there. Note that there's a bug in the mathed stuf that means that the new sqrt, frac are displayed only by scrolling the InsetFormula out of sight and back again. I think that this is the bug reported earlier by Dekel. Angus mathtoolbar.patch.bz2
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
rc2 - math toolbar
Does 'auto' work? When I choose math (auto), with cursor in plain text, math toolbar is still there.
Misplacement of math toolbar
Hi all, first of all thanks for your work and keep it up. I've been compiling the source from subversion for a couple of days now and I noticed that when starting some math the math toolbar shows up (nothing wrong with that) but it shows up right under the menu bar. I also don't know how to move it or any toolbar in general. I attached a screenshoot so you'll understand because I don't know if I described it right. Jonathan lyx1.png Description: PNG image
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"
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: 1.5b2 math toolbar?
Neal Becker wrote: > Sorry, I haven't been following the discussion. I don't see any math > toolbar. Am I missing something? Nevermind - found it.
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 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 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&Paste"
Icon "cut"
Icon "copy"
Icon "paste"
End
If in a text inset then this would go to the right of Common or Cut&Paste:
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
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> * Finally, the Angus> Layout definition in default.ui should be replaced with Angus> DropdownList "layout". An even better suggestion was to use the menu backend for toolbars too (somehow) and to implement drop down lists as submenus. Angus> A common toolbar, always present Toolbar "Common" DropdownList Angus> "layouts" Icon "file-open" Icon "buffer-write" Icon Angus> "buffer-print" End Angus> If text is marked, then show this to the right of Toolbar Angus> "Common" Toolbar "Cut&Paste" Icon "cut" Icon "copy" Icon Angus> "paste" End I don't like that... I would not want icons to appear/disappear when I move the cursor. Note that currently, the cut-and-paste icons are made active/inactive as needed. The only problem is that I have not found a nice way to get visual feedback about that in xforms. Also, if we use the menu backend for toolbar, we already have OptItem for items that can appear/disappear as needed. 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: rc2 - math toolbar
Neal Becker wrote: > Does 'auto' work? > > When I choose math (auto), with cursor in plain text, math toolbar is > still there. Actually, IMO the design is really confusing. What does 'checking' math(auto) mean? According to the math manual, it's auto if its unchecked, and always on if checked? That's confusing. And, it doesn't work. It's always on if checked and always off if not.
Re: rc2 - math toolbar
Neal Becker <[EMAIL PROTECTED]> writes: > Neal Becker wrote: > >> Does 'auto' work? >> >> When I choose math (auto), with cursor in plain text, math toolbar is >> still there. > > Actually, IMO the design is really confusing. What does 'checking' > math(auto) mean? > > According to the math manual, it's auto if its unchecked, and always > on if checked? That's confusing. > > And, it doesn't work. It's always on if checked and always off if not. It used to be that toolbars that have the 'auto' flag could be in three states (always on, always off, auto) while the others only had 2 states (on and off). With the merging of the toolbar backend with the GUI, the information is now lost. I think the new behaviour does not make sense... JMarc
Re: rc2 - math toolbar
Jean-Marc Lasgouttes wrote: Neal Becker<[EMAIL PROTECTED]> writes: Neal Becker wrote: Does 'auto' work? When I choose math (auto), with cursor in plain text, math toolbar is still there. Actually, IMO the design is really confusing. What does 'checking' math(auto) mean? According to the math manual, it's auto if its unchecked, and always on if checked? That's confusing. And, it doesn't work. It's always on if checked and always off if not. It used to be that toolbars that have the 'auto' flag could be in three states (always on, always off, auto) while the others only had 2 states (on and off). With the merging of the toolbar backend with the GUI, the information is now lost. Wrong, the information is still there and simpler. Or at least it was last time I worked on that. I think the new behaviour does not make sense... When I cleaned up that mess, it was working fine. Abdel.
Re: rc2 - math toolbar
Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Neal Becker<[EMAIL PROTECTED]> writes: Neal Becker wrote: Does 'auto' work? When I choose math (auto), with cursor in plain text, math toolbar is still there. Actually, IMO the design is really confusing. What does 'checking' math(auto) mean? According to the math manual, it's auto if its unchecked, and always on if checked? That's confusing. And, it doesn't work. It's always on if checked and always off if not. It used to be that toolbars that have the 'auto' flag could be in three states (always on, always off, auto) while the others only had 2 states (on and off). With the merging of the toolbar backend with the GUI, the information is now lost. Wrong, the information is still there and simpler. Or at least it was last time I worked on that. The problem is that GuiToolbar::visibility_ is always equal to zero whereas it should have been saved in GuiToolbar::saveSession() with Toolbars::AUTO value. So there is a problem with session handling. Work around: Go to preference settings-> interface, uncheck "window geometry saving" and click "apply" in order to clear out the session info. Check it again and apply to reenable session info. Now auto toolbars should work again. I know, there are a number of bugs in the session handling, but I am very very busy... I'll try to fix them next weekend if nobody has fixed them in the mean time. Abdel.
Re: rc2 - math toolbar
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > It used to be that toolbars that have the 'auto' flag could be in > three states (always on, always off, auto) while the others only had 2 > states (on and off). With the merging of the toolbar backend with the > GUI, the information is now lost. I think the new behaviour does not > make sense... After getting a vehement complaint from Abdel, I got to try out again the behaviour of the toolbars ;) The situation now is that auto toolbars (like the math toolbar) have two possible positions: auto and off. In 1.5, there were 3 positions: on, auto and off. I think it is a regression in functionality, even though the old UI was confusing. The possible menu positions in 1.5 were: [X] Math on [X] Math (auto)auto, currently on [ ] Math (auto)auto, currently off [ ] Math off These menu positions convey correctly current status IMO, but they do not convey what is going to happen when clicking on the menu entry, which is to cycle through on->auto->off->on. The fact is, that the GUI does not consider a tristate, but only a on/off setting. JMarc
Re: rc2 - math toolbar
Jean-Marc Lasgouttes wrote: Jean-Marc Lasgouttes<[EMAIL PROTECTED]> writes: It used to be that toolbars that have the 'auto' flag could be in three states (always on, always off, auto) while the others only had 2 states (on and off). With the merging of the toolbar backend with the GUI, the information is now lost. I think the new behaviour does not make sense... After getting a vehement complaint from Abdel, I got to try out again the behaviour of the toolbars ;) The situation now is that auto toolbars (like the math toolbar) have two possible positions: auto and off. In 1.5, there were 3 positions: on, auto and off. Maybe there is a bug in GuiToolbar::toggle(), I implemented that quickly... but the information should be there for a tristate toggling. I think it is a regression in functionality, even though the old UI was confusing. The possible menu positions in 1.5 were: [X] Math on [X] Math (auto)auto, currently on [ ] Math (auto)auto, currently off [ ] Math off These menu positions convey correctly current status IMO, but they do not convey what is going to happen when clicking on the menu entry, which is to cycle through on->auto->off->on. The fact is, that the GUI does not consider a tristate, but only a on/off setting. Well, I have to confess that I hate this menu based UI. The only sane UI for this would be a context menu with three radio buttons (on/off/auto) for all available toolbar. The default Qt toolbar menu is good but is disabled because of the icon size menu. IMHO, we should try to reenable it and improve it with radio buttons. Abdel.
Re: rc2 - math toolbar
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Well, I have to confess that I hate this menu based UI. The only sane > UI for this would be a context menu with three radio buttons > (on/off/auto) for all available toolbar. The default Qt toolbar menu > is good but is disabled because of the icon size menu. IMHO, we should > try to reenable it and improve it with radio buttons. Why not. JMarc
Re: rc2 - math toolbar
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> Well, I have to confess that I hate this menu based UI. The only sane >> UI for this would be a context menu with three radio buttons >> (on/off/auto) for all available toolbar. The default Qt toolbar menu >> is good but is disabled because of the icon size menu. IMHO, we should >> try to reenable it and improve it with radio buttons. > > Why not. But still, context menus without corresponding menus are bad... JMarc
Re: disabling math toolbar
Pavel Sanda wrote: > Richard Heck wrote: > > On 11/30/2009 06:15 PM, Uwe Stöhr wrote: > >> rgheck schrieb: > >> > >>>> Use the menu View->Toolbars or alternatively the toolbar button at the > >>>> right of the main toolbar that shows an equation and is named "toggle > >>>> math toolbar". > >>>> For more info about LyX's look and feel, have a look at LyX's User's > >>>> guide, appendix A. > >>>> > >>> I don't see a way, Uwe, to turn it off completely, at least on my system. > >>> I can turn it on, and then turn it off, but it always stays on "auto". > > try this: go into equation, now turn it off. from now on auto shouldn't > be triggered. > > >> It stays on auto, but does no longer pop up when clicking into a formula. > >> Thus it is turned on. I admit that the label "(auto)" suggests the > >> opposite. > >> > > Didn't we used to have "three state buttons" here? > > iirc it was and it seems to be broken now, at least as far se the occurence of > "auto" string appearance in the menu. but after some playing i was still able > to > put it into all three states. bisect leads to r24954: commit 7fd567d187e51c6168dfb4af991ee6aff82f Author: younes Date: Tue May 27 11:15:17 2008 + Re-engineer the toolbar support code: - We now rely more upon Qt features, - the initial toolbar positioning defined in "lib/ui/default.ui" is now only used if there is no session or if session handling is disabled, - The session saving/restoring is window dependent. after this commit tristate in menu for toolbars no more works. pavel
Re: disabling math toolbar
after this commit tristate in menu for toolbars no more works. Yes, and I complained about it at the time. JMarc
Re: disabling math toolbar
Pavel Sanda schrieb: bisect leads to r24954: commit 7fd567d187e51c6168dfb4af991ee6aff82f Author: younes Date: Tue May 27 11:15:17 2008 + Re-engineer the toolbar support code: - We now rely more upon Qt features, - the initial toolbar positioning defined in "lib/ui/default.ui" is now only used if there is no session or if session handling is disabled, - The session saving/restoring is window dependent. after this commit tristate in menu for toolbars no more works. Can you please open a regression bug report so that Abdel won't forget to fix this? thanks and regards Uwe
Re: disabling math toolbar
Uwe Stöhr wrote: Pavel Sanda schrieb: bisect leads to r24954: commit 7fd567d187e51c6168dfb4af991ee6aff82f Author: younes Date: Tue May 27 11:15:17 2008 + Re-engineer the toolbar support code: - We now rely more upon Qt features, - the initial toolbar positioning defined in "lib/ui/default.ui" is now only used if there is no session or if session handling is disabled, - The session saving/restoring is window dependent. after this commit tristate in menu for toolbars no more works. Can you please open a regression bug report so that Abdel won't forget to fix this? First we have to agree that there is something to fix. Abdel.
Re: disabling math toolbar
Abdelrazak Younes schrieb: First we have to agree that there is something to fix. What we need to fix is: - use the menu View->Toolbar to deactivate the math toolbars Result: the checkmark is correctly removed and the menu entry contains "(auto)" - now try to change the state from auto to completely disabled Result: this is not possible: the menu entry still contains "(auto)" In LyX 1.5.x "auto" is removed. This is misleading because there are three possible states: * always enabled * always disabled * auto: is inly shown when the cursor is inside a formula regards Uwe
Re: disabling math toolbar
Uwe Stöhr wrote: Abdelrazak Younes schrieb: First we have to agree that there is something to fix. What we need to fix is: - use the menu View->Toolbar to deactivate the math toolbars Result: the checkmark is correctly removed and the menu entry contains "(auto)" - now try to change the state from auto to completely disabled Result: this is not possible: the menu entry still contains "(auto)" In LyX 1.5.x "auto" is removed. This is misleading because there are three possible states: * always enabled * always disabled * auto: is inly shown when the cursor is inside a formula OK, I guess this is an ui description problem as the three possible states are still possible: When you are in math mode and the math toolbar is auto, you can disable it by invoking the menu. When you are *not* in math mode and the toolbar is auto you can enable it. The problem is that this menubar access is very bad. We need a real dialog for the toolbar configuration with 3 radio button for the three states and also 4 radio buttons for the position in the window. Abdel.
Re: disabling math toolbar
Abdelrazak Younes schrieb: OK, I guess this is an ui description problem as the three possible states are still possible: Yes, the problem is that the label "auto" indicates that it is in auto state while this is not always the case. The problem is that this menubar access is very bad. We need a real dialog for the toolbar configuration with 3 radio button for the three states I fully agree. and also 4 radio buttons for the position in the window. Why that? When the menubar is shown I drag it to a position of my choice. Even when it is in the auto mode, the toolbar will then appear at the wanted position. regards Uwe
Re: disabling math toolbar
Uwe Stöhr wrote: Abdelrazak Younes schrieb: and also 4 radio buttons for the position in the window. Why that? When the menubar is shown I drag it to a position of my choice. Even when it is in the auto mode, the toolbar will then appear at the wanted position. Maybe it's needed... But some people doesn't like (or doesn't know) dragging toolbars... Abdel.
Re: disabling math toolbar
Abdelrazak Younes wrote: >>> bisect leads to r24954: >>> commit 7fd567d187e51c6168dfb4af991ee6aff82f >>> Author: younes >>> Date: Tue May 27 11:15:17 2008 + >>> >>> Re-engineer the toolbar support code: >>> - We now rely more upon Qt features, >>> - the initial toolbar positioning defined in "lib/ui/default.ui" is >>> now only used if there is no session or if session handling is disabled, >>> - The session saving/restoring is window dependent. >>> >>> after this commit tristate in menu for toolbars no more works. >> >> Can you please open a regression bug report so that Abdel won't forget to >> fix this? > > First we have to agree that there is something to fix. so do you agree that there is something to fix after the thread? as i see it we have 3 real states and only 2 menu states with weird way how to switch it. pavel
Re: disabling math toolbar
Pavel Sanda wrote: Abdelrazak Younes wrote: bisect leads to r24954: commit 7fd567d187e51c6168dfb4af991ee6aff82f Author: younes Date: Tue May 27 11:15:17 2008 + Re-engineer the toolbar support code: - We now rely more upon Qt features, - the initial toolbar positioning defined in "lib/ui/default.ui" is now only used if there is no session or if session handling is disabled, - The session saving/restoring is window dependent. after this commit tristate in menu for toolbars no more works. Can you please open a regression bug report so that Abdel won't forget to fix this? First we have to agree that there is something to fix. so do you agree that there is something to fix after the thread? Guess so. as i see it we have 3 real states and only 2 menu states with weird way how to switch it. The one sane way to solve this rapidly is to create a new dialog for that as I outlined earlier. Should be quite easy but I don't have the time... Abdel.
Re: disabling math toolbar
Abdelrazak Younes writes: > The one sane way to solve this rapidly is to create a new dialog for > that as I outlined earlier. Should be quite easy but I don't have the > time... Or use the support for tristate checkbox that exists in qt. JMarc
Re: disabling math toolbar
Jean-Marc Lasgouttes wrote: Abdelrazak Younes writes: The one sane way to solve this rapidly is to create a new dialog for that as I outlined earlier. Should be quite easy but I don't have the time... Or use the support for tristate checkbox that exists in qt. From an ui point of view tristate checkbox in menu is very very bad IMO. Abdel.
Re: disabling math toolbar
Abdelrazak Younes writes: >> Or use the support for tristate checkbox that exists in qt. > > From an ui point of view tristate checkbox in menu is very very bad IMO. Fair enough. JMarc
Re: disabling math toolbar
Abdelrazak Younes wrote: >>> The one sane way to solve this rapidly is to create a new dialog for >>> that as I outlined earlier. Should be quite easy but I don't have the >>> time... >> >> Or use the support for tristate checkbox that exists in qt. > > From an ui point of view tristate checkbox in menu is very very bad IMO. i tend to agree with tristate. pavel
Re: disabling math toolbar
Uwe Stöhr wrote: > Can you please open a regression bug report so that Abdel won't forget to > fix this? this is now: http://www.lyx.org/trac/ticket/6364 pavel
Active table and math toolbar
Hello, I think this patch (or a similar one) has been discussed already. Should I commit it? BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Michael Index: default.ui === --- default.ui(revision 14919) +++ default.ui(working copy) @@ -34,7 +34,7 @@ Toolbars "standard" "on,top" "extra" "on,top" -"table" "off,bottom" -"math" "off,bottom" +"table" "table,bottom" +"math" "math,bottom" "minibuffer" "off,bottom" End
Re: Misplacement of math toolbar
Jonathan Vogt wrote: Hi all, first of all thanks for your work and keep it up. I've been compiling the source from subversion for a couple of days now and I noticed that when starting some math the math toolbar shows up (nothing wrong with that) but it shows up right under the menu bar. I also don't know how to move it or any toolbar in general. I attached a screenshoot so you'll understand because I don't know if I described it right. You've described it very clearly. Thanks for reporting but this is a known bug. I have to find some time to solved it. If someone wants to look at it, the problem is related to a toolbar separator inserted between the table toolbar and the math toolbar. If the cursor goes in math within the table, you will notice that the two toolbars show correctly. When in math alone, the separator should not be inserted, or something like that. The code in question is in GuiView.C. Abdel.
Re: Misplacement of math toolbar
Abdelrazak Younes wrote: I have to find some time to solved it. If someone wants to look at it, the problem is related to a toolbar separator inserted between the table toolbar and the math toolbar. If the cursor goes in math within the table, you will notice that the two toolbars show correctly. When in math alone, the separator should not be inserted, or something like that. The code in question is in GuiView.C. i have been looking a bit at this today, but haven't come very much further. the problem is different and a bit more tricky than you describe. when enabling a toolbar at the bottom, but before the table and math one, this gets misplaced as well try this in default.ui Toolbars "standard" "on,top" "extra" "on,bottom" "math" "math,bottom" "table" "table,bottom" "review" "off,bottom" "minibuffer" "off,bottom" End and you'll see
Re: Misplacement of math toolbar
Edwin Leuven wrote: Abdelrazak Younes wrote: I have to find some time to solved it. If someone wants to look at it, the problem is related to a toolbar separator inserted between the table toolbar and the math toolbar. If the cursor goes in math within the table, you will notice that the two toolbars show correctly. When in math alone, the separator should not be inserted, or something like that. The code in question is in GuiView.C. i have been looking a bit at this today, but haven't come very much further. the problem is different and a bit more tricky than you describe. when enabling a toolbar at the bottom, but before the table and math one, this gets misplaced as well Indeed, this is tricky. The interaction between the toolbar backend and QLToolbar needs to be rethought IMHO. Abdel.
Re: Misplacement of math toolbar
Jonathan Vogt wrote: > Hi all, > > first of all thanks for your work and keep it up. > > I've been compiling the source from subversion for a couple of days now and I > noticed that when starting some math the math toolbar shows up (nothing wrong > with that) but it shows up right under the menu bar. > I also don't know how to move it or any toolbar in general. > I attached a screenshoot so you'll understand because I don't know if I > described it right. > > Jonathan > > > > I open lyx, ctrl-n, ctrl-m, but I don't see the bug. -- Peter Kümmel
Re: Misplacement of math toolbar
Peter Kümmel wrote: > Jonathan Vogt wrote: >> Hi all, >> >> first of all thanks for your work and keep it up. >> >> I've been compiling the source from subversion for a couple of days now and >> I >> noticed that when starting some math the math toolbar shows up (nothing >> wrong >> with that) but it shows up right under the menu bar. >> I also don't know how to move it or any toolbar in general. >> I attached a screenshoot so you'll understand because I don't know if I >> described it right. >> >> Jonathan >> >> >> >> > > I open lyx, ctrl-n, ctrl-m, but I don't see the bug. > Maybe this helps investigating the bug: $ svn diff frontends/qt4/QLToolbar.C Index: frontends/qt4/QLToolbar.C === --- frontends/qt4/QLToolbar.C (revision 15548) +++ frontends/qt4/QLToolbar.C (working copy) @@ -154,7 +154,7 @@ // allowing the toolbars to tear off is too easily done, // and we don't save their orientation anyway. Disable the handle. - setMovable(false); + setMovable(true); ToolbarBackend::item_iterator it = tbb.items.begin(); ToolbarBackend::item_iterator end = tbb.items.end(); Is the comment still valid? Why not enable movable for 1.5? It's a so simple and noncritical change with such a big effect. We also have to sell lyx 1.5. -- Peter Kümmel
Re: Misplacement of math toolbar
On Thu, Oct 26, 2006 at 09:23:15AM +0200, Abdelrazak Younes wrote: > Edwin Leuven wrote: > >Abdelrazak Younes wrote: > >>I have to find some time to solved it. If someone wants to look at it, > >>the problem is related to a toolbar separator inserted between the > >>table toolbar and the math toolbar. If the cursor goes in math within > >>the table, you will notice that the two toolbars show correctly. When > >>in math alone, the separator should not be inserted, or something like > >>that. > >> > >>The code in question is in GuiView.C. > > > >i have been looking a bit at this today, but haven't come very much > >further. > > > >the problem is different and a bit more tricky than you describe. when > >enabling a toolbar at the bottom, but before the table and math one, > >this gets misplaced as well > > Indeed, this is tricky. The interaction between the toolbar backend and > QLToolbar needs to be rethought IMHO. I consider 'toolbars' a GUI feature. Sureley the kernel can load configuration, but controling placement etc belongs to the GUI. Andre'
Re: Active table and math toolbar
On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote: > I think this patch (or a similar one) has been discussed already. Should > I commit it? This is a really difficult one to decide. I can see this being enormously irritating default behaviour for some people, and we don't yet have a View->Toolbars that can easily turn it off. On the other hand, these toolbars are extremely useful. Can you point me to the discussion? > BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always > displayed at the top. Should I add a bugzilla report? Sounds broken yes regards john
Re: Active table and math toolbar
Michael Gerz wrote: BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Yes, I am aware of it an I plaid guilty. Right now the toolbars are hard-coded to be at the top because I didn't have the time to fix it properly last christmas. Abdel.
Re: Active table and math toolbar
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Sep 06, 2006 at 11:01:41PM +0200, Michael Gerz wrote: >> I think this patch (or a similar one) has been discussed already. >> Should I commit it? John> This is a really difficult one to decide. I can see this being John> enormously irritating default behaviour for some people, and we John> don't yet have a View->Toolbars that can easily turn it off. On John> the other hand, these toolbars are extremely useful. What about a new 'Allow automatic toolbars' lyxrc entry? Then we could set the default to 'true'. Or to 'false' :) JMarc
Re: Active table and math toolbar
Jean-Marc Lasgouttes schrieb: John> This is a really difficult one to decide. I can see this being John> enormously irritating default behaviour for some people, and we John> don't yet have a View->Toolbars that can easily turn it off. On John> the other hand, these toolbars are extremely useful. What about a new 'Allow automatic toolbars' lyxrc entry? Then we could set the default to 'true'. Or to 'false' :) In that case, the current UI file design does not make sense any longer. Anyway, there are at least three people among us who would like to see a short-term solution. See http://bugzilla.lyx.org/show_bug.cgi?id=2813 Why don't we activate the toolbars for now (and for 1.4.3)? The activation is not a showstopper in case someone wants to optimize the look & feel later. Michael
Re: Active table and math toolbar
On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote: > Why don't we activate the toolbars for now (and for 1.4.3)? The > activation is not a showstopper in case someone wants to optimize the > look & feel later. Let's activate it for 1.5.0svn and see what happens, but not 1.4... regards john
Re: Active table and math toolbar
John Levon schrieb: On Thu, Sep 07, 2006 at 08:54:38PM +0200, Michael Gerz wrote: Why don't we activate the toolbars for now (and for 1.4.3)? The activation is not a showstopper in case someone wants to optimize the look & feel later. Let's activate it for 1.5.0svn and see what happens, but not 1.4... Activation commited to 1.5.0svn. Michael
Re: Active table and math toolbar
Abdelrazak Younes wrote: Michael Gerz wrote: BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always displayed at the top. Should I add a bugzilla report? Yes, I am aware of it an I plaid guilty. Right now the toolbars are hard-coded to be at the top because I didn't have the time to fix it properly last christmas. I am going to cleanup a bit the toolbars code. Abdel.
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" 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
Combine math toolbar and math panel?
I use math a lot in lyx, and it would seem simpler to me to combine the math toolbar and the math panel into a single, double-decker toolbar. I find myself using the panel as much as the toolbar, and I am not sure why they are separated. One minor problem: When adding math to the end of a file, the automatic popup of the toolbar (which I like very much) partially covers the math box until one starts typing math. If the math panel is also activated, it completely covers the box. The box pops into view as soon as one types some math, but it is a little disconcerting initially. This all refers to lyx 1.6.1. Dave Raymond
Re: The buttons in the math toolbar...
Angus Leeming wrote: > They're a bit ugly aren't they ;-) > > So, I thought I'd use lyx together with lyxpreview2bitmap.sh to > harness latex's typesetting power. > > Generated from the attached latex file as > $ sh lyxpreview2bitmap.sh buttons.tex 100 ppm > > What do you think? Could these be turned into buttons? If so, how > big should they be? These 'strips' are about 40 pixels high, but > that's trivial to control by varying the '100' above. Second incidental: I think that the mathed brackets chooser is kaput. I couldn't change the style at all. -- Angus
Re: The buttons in the math toolbar...
Angus Leeming wrote: > They're a bit ugly aren't they ;-) > > So, I thought I'd use lyx together with lyxpreview2bitmap.sh to > harness latex's typesetting power. > > Generated from the attached latex file as > $ sh lyxpreview2bitmap.sh buttons.tex 100 ppm > > What do you think? Could these be turned into buttons? If so, how > big should they be? These 'strips' are about 40 pixels high, but > that's trivial to control by varying the '100' above. Incidentally André, I really like the new color facility in mathed ;-) -- Angus
Re: The buttons in the math toolbar...
Angus Leeming wrote: > They're a bit ugly aren't they ;-) > > So, I thought I'd use lyx together with lyxpreview2bitmap.sh to > harness latex's typesetting power. > > Generated from the attached latex file as > $ sh lyxpreview2bitmap.sh buttons.tex 100 ppm > > What do you think? Could these be turned into buttons? If so, how > big should they be? These 'strips' are about 40 pixels high, but > that's trivial to control by varying the '100' above. Ok see attached. They look bloody good on the toolbar. Shall I commit these? -- Angus<><><><><><><><><><>
Re: The buttons in the math toolbar...
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Angus Leeming wrote: >> They're a bit ugly aren't they ;-) >> >> So, I thought I'd use lyx together with lyxpreview2bitmap.sh to >> harness latex's typesetting power. >> >> Generated from the attached latex file as $ sh lyxpreview2bitmap.sh >> buttons.tex 100 ppm >> >> What do you think? Could these be turned into buttons? If so, how >> big should they be? These 'strips' are about 40 pixels high, but >> that's trivial to control by varying the '100' above. Angus> Ok see attached. They look bloody good on the toolbar. Shall I Angus> commit these? But they do not have an uniform size, do they? Is xforms able to use them? JMarc
Re: The buttons in the math toolbar...
On Friday 10 October 2003 15:51, Angus Leeming wrote: > > Ok see attached. They look bloody good on the toolbar. Shall I commit > these? By all means. :-) They look impressive, you are really a great artist. ;-) -- José Abílio LyX and docbook, a perfect match. :-)
Re: The buttons in the math toolbar...
On Friday 10 October 2003 2:04 pm, Jean-Marc Lasgouttes wrote: > But they do not have an uniform size, do they? Is xforms able to use > them? xforms doesn't have a math toolbar...
Re: The buttons in the math toolbar...
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> On Friday 10 October 2003 2:04 pm, Jean-Marc Lasgouttes wrote: >> But they do not have an uniform size, do they? Is xforms able to >> use them? Angus> xforms doesn't have a math toolbar... Sure, but one may want to customize his own toolbar nevertheless... JMarc
Re: The buttons in the math toolbar...
Jean-Marc Lasgouttes wrote: >>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> On Friday 10 October 2003 2:04 pm, Jean-Marc Lasgouttes > wrote: >>> But they do not have an uniform size, do they? Is xforms able to >>> use them? > > Angus> xforms doesn't have a math toolbar... > > Sure, but one may want to customize his own toolbar nevertheless... Then try them and see what xforms makes of them... Ok, I did. All are fine except for the cases.xpm which extends above/below the button. -- Angus
Re: The buttons in the math toolbar...
On Fri, Oct 10, 2003 at 02:51:39PM +, Angus Leeming wrote: > Ok see attached. They look bloody good on the toolbar. Shall I commit > these? Yes. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: The buttons in the math toolbar...
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Then try them and see what xforms makes of them... Ok, I did. Angus> All are fine except for the cases.xpm which extends above/below Angus> the button. Thanks. JMarc
Re: Combine math toolbar and math panel?
David Raymond wrote: > One minor problem: When adding math to the end of a file, the > automatic popup of the toolbar (which I like very much) partially > covers the math box until one starts typing math. If the math panel > is also activated, it completely covers the box. The box pops into > view as soon as one types some math, but it is a little disconcerting > initially. http://bugzilla.lyx.org/show_bug.cgi?id=4733 pavel
searching for frame icons for the math toolbar
The math toolbar misses a submenu where the user can insert the following boxes \fbox, \framebox, \mbox, \makebox, and \boxed Has anybody a proposal for icons for them? thanks and regards Uwe
Re: searching for frame icons for the math toolbar
Uwe Stöhr <[EMAIL PROTECTED]> writes: > The math toolbar misses a submenu where the user can insert the following > boxes > \fbox, \framebox, \mbox, \makebox, and \boxed > > Has anybody a proposal for icons for them? Do we need all of these boxes in the toolbar? If somebody understands the difference between \fbox and \framebox, he is probably able to just type the macro name. JMarc
Re: searching for frame icons for the math toolbar
Jean-Marc Lasgouttes schrieb: Do we need all of these boxes in the toolbar? If somebody understands the difference between \fbox and \framebox, he is probably able to just type the macro name. OK, but we should have at least have two icons for \fbox and \boxed. regards Uwe
Re: searching for frame icons for the math toolbar
Uwe Stöhr <[EMAIL PROTECTED]> writes: > Jean-Marc Lasgouttes schrieb: > >> Do we need all of these boxes in the toolbar? If somebody understands >> the difference between \fbox and \framebox, he is probably able to >> just type the macro name. > > OK, but we should have at least have two icons for \fbox and \boxed. Could you recall what \boxed does? JMarc
Re: searching for frame icons for the math toolbar
Jean-Marc Lasgouttes schrieb: OK, but we should have at least have two icons for \fbox and \boxed. Could you recall what \boxed does? \fbox : to frame inline formulas \boxed : to frame displayed formulas Both are already supported by mathed, only a math toolbar icon is missing. regards Uwe
Re: searching for frame icons for the math toolbar
Am Mittwoch, 23. Januar 2008 09:33:18 schrieb Jean-Marc Lasgouttes: > Uwe Stöhr <[EMAIL PROTECTED]> writes: > > The math toolbar misses a submenu where the user can insert the following > > boxes \fbox, \framebox, \mbox, \makebox, and \boxed > > > > Has anybody a proposal for icons for them? > > Do we need all of these boxes in the toolbar? If somebody understands > the difference between \fbox and \framebox, he is probably able to > just type the macro name. Having icons for actions is always a good thing; e.g. a user might want to customize his toolbar etc. -- Ciao, / / /--/ / / ANS
Re: searching for frame icons for the math toolbar
> Having icons for actions is always a good thing; e.g. a user might want to > customize his toolbar etc. As said I'll add them as soon as somebody proposed some icons. regards Uwe
[patch] for LyX 1.5.3 register placeholders to the math toolbar
The attached patch registeres placeholders to the math toolbar and clarify some entries. OK for branch? regards Uwe p.s. lyx.org is currently dead Index: stdtoolbars.inc === --- stdtoolbars.inc (revision 21421) +++ stdtoolbars.inc (working copy) @@ -194,6 +194,7 @@ Toolbar "math_panels" "Math Panels" PopupMenu "space" "Math Spacings" + PopupMenu "phantom" "Placeholders" PopupMenu "style" "Styles" PopupMenu "frac-square" "Fractions" PopupMenu "font" "Fonts" @@ -258,6 +259,12 @@ Item "Negative space \\!" "math-insert \!" End + Toolbar "phantom" "Placeholders" + Item "Placeholder \\phantom" "math-insert \phantom" + Item "Horizontal placeholder \\hphantom" "math-insert \hphantom" + Item "Vertical placeholder \\vphantom" "math-insert \vphantom" + End + Toolbar "sqrt-square" "Roots" Item "Square root \\sqrt" "math-insert \sqrt" Item "Other root \\root" "math-insert \root" @@ -272,11 +279,11 @@ Toolbar "frac-square" "Fractions" Item "Standard \\frac" "math-insert \frac" - Item "No hor. line \\atop" "math-insert \atop" - Item "Nice \\nicefrac" "math-insert \nicefrac" - Item "Text frac (amsmath) \\tfrac" "math-insert \tfrac" - Item "Display frac (amsmath) \\dfrac" "math-insert \dfrac" - Item "Binomial \\choose" "math-insert \choose" + Item "No horizontal line \\atop" "math-insert \atop" + Item "Nice fraction (3/4) \\nicefrac" "math-insert \nicefrac" + Item "Text fraction (amsmath) \\tfrac" "math-insert \tfrac" + Item "Display fraction (amsmath) \\dfrac" "math-insert \dfrac" + Item "Binomial \\binom" "math-insert \binom" End Toolbar "font" "Fonts"
Auto popup of math toolbar hides the cursor (bug 4733)
hi,
in short the problem is that at the end of lyxfunc dispatch we firstly
processUpdateFlags and after we do restartCursor() which in turn updates
toolbar, which toggling-on hides the cursor. moving processUpdateFlags after
restartCursor leads to crashes.
the following patch is a workaround for the bug, so that processUpdateFlags is
called once more after this. it cant be used as an fix, because it will slow
down the editation. moreover it does not fixes the logic...
i can devise some ugly patch which triggers processUpdateFlags only when
toolbar toggling is detected, but beforehand i would like to ask whether
there is some better idea what to do -- Abdel?
pavel
diff --git a/src/LyXFunc.cpp b/src/LyXFunc.cpp
index 5fc04c1..1f70863 100644
--- a/src/LyXFunc.cpp
+++ b/src/LyXFunc.cpp
@@ -1755,6 +1755,7 @@ void LyXFunc::dispatch(FuncRequest const & cmd)
// update gui
lyx_view_->restartCursor();
+ view()->processUpdateFlags(updateFlags);
}
}
if (lyx_view_) {
[PATCH] Cleanup toolbar code (was Re: Active table and math toolbar)
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Michael Gerz wrote:
BTW: "bottom" is ignored in 1.5.0svn/qt4. The tool bar is always
displayed at the top. Should I add a bugzilla report?
Yes, I am aware of it an I plaid guilty. Right now the toolbars are
hard-coded to be at the top because I didn't have the time to fix it
properly last christmas.
I am going to cleanup a bit the toolbars code.
This patch does so and should also fix the above bug.
Only qt4 for now... I am willing to adapt gtk to the Toolbars API change
but please, could we once and for all forget about qt3?
Abdel.
Log:
* LyXView.h:
- makeToolbar(): new pure virtual method
* qt4/GuiView.h:
- makeToolbar(): new method transferred from QLToolbar
* qt4/QLToolbar: derive from QToolBar instead of owning a QToolBar member.
* Toolbars.h: remove make_toolbar() prototype (use LyXView::makeToolbar
instead).
Index: frontends/LyXView.h
===
--- frontends/LyXView.h (revision 14911)
+++ frontends/LyXView.h (working copy)
@@ -13,6 +13,8 @@
#ifndef LYXVIEW_H
#define LYXVIEW_H
+#include "frontends/Toolbars.h"
+
#include
#include
#include
@@ -20,7 +22,6 @@
#include
class Buffer;
-class Toolbars;
class InsetBase;
class Intl;
class Menubar;
@@ -73,6 +74,8 @@
/// show busy cursor
virtual void busy(bool) const = 0;
+ virtual Toolbars::ToolbarPtr makeToolbar(ToolbarBackend::Toolbar const
& tbb) = 0;
+
//@{ generic accessor functions
/** return the current buffer view
Index: frontends/qt4/GuiView.C
===
--- frontends/qt4/GuiView.C (revision 14911)
+++ frontends/qt4/GuiView.C (working copy)
@@ -24,7 +24,6 @@
#include "debug.h"
-#include "frontends/Toolbars.h"
#include "frontends/WorkArea.h"
#include "support/filetools.h"
#include "support/convert.h"
@@ -36,6 +35,7 @@
#include "GuiView.h"
#include "QLMenubar.h"
+#include "QLToolbar.h"
#include "FontLoader.h"
#include "QCommandBuffer.h"
#include "qt_helpers.h"
@@ -245,6 +245,32 @@
QApplication::restoreOverrideCursor();
}
+
+Toolbars::ToolbarPtr GuiView::makeToolbar(ToolbarBackend::Toolbar const & tbb)
+{
+ QLToolbar * Tb = new QLToolbar(tbb, *this);
+ static QLToolbar * lastTb = 0;
+
+ if (tbb.flags & ToolbarBackend::TOP) {
+ addToolBar(Qt::TopToolBarArea, Tb);
+ addToolBarBreak(Qt::TopToolBarArea);
+ }
+ if (tbb.flags & ToolbarBackend::BOTTOM) {
+ addToolBar(Qt::BottomToolBarArea, Tb);
+ if (lastTb)
+ insertToolBarBreak(lastTb);
+ lastTb = Tb;
+ }
+ if (tbb.flags & ToolbarBackend::LEFT) {
+ addToolBar(Qt::LeftToolBarArea, Tb);
+ }
+ if (tbb.flags & ToolbarBackend::RIGHT) {
+ addToolBar(Qt::RightToolBarArea, Tb);
+ }
+
+ return Toolbars::ToolbarPtr(Tb);
+}
+
} // namespace frontend
} // namespace lyx
Index: frontends/qt4/GuiView.h
===
--- frontends/qt4/GuiView.h (revision 14911)
+++ frontends/qt4/GuiView.h (working copy)
@@ -60,6 +60,8 @@
/// show busy cursor
virtual void busy(bool) const;
+ Toolbars::ToolbarPtr makeToolbar(ToolbarBackend::Toolbar const & tbb);
+
/// display a status message
virtual void message(std::string const & str);
Index: frontends/qt4/QLToolbar.C
===
--- frontends/qt4/QLToolbar.C (revision 14911)
+++ frontends/qt4/QLToolbar.C (working copy)
@@ -47,35 +47,7 @@
return lv.buffer()->params().getLyXTextClass();
}
-/*
-/// \todo Remove Qt::Dock getPosition(ToolbarBackend::Flags const & flags) if
not needed anymore
-Qt::Dock getPosition(ToolbarBackend::Flags const & flags)
-{
- if (flags & ToolbarBackend::TOP)
- return Qt::DockTop;
- if (flags & ToolbarBackend::BOTTOM)
- return Qt::DockBottom;
- if (flags & ToolbarBackend::LEFT)
- return Qt::DockLeft;
- if (flags & ToolbarBackend::RIGHT)
- return Qt::DockRight;
- return Qt::DockTop;
-}
-*/
-Qt::ToolBarArea getToolBarPosition(ToolbarBackend::Flags const & flags)
-{
- if (flags & ToolbarBackend::TOP)
- return Qt::TopToolBarArea;
- if (flags & ToolbarBackend::BOTTOM)
- return Qt::BottomToolBarArea;
- if (flags & ToolbarBackend::LEFT)
- return Qt::LeftToolBarArea;
- if (flags & ToolbarBackend::RIGHT)
- return Qt::RightToolBarArea;
- return Qt::TopToolBarArea;
-}
-
} // namespace anon
@@ -173,48 +145,17 @@
layoutSelected(owner_, sel);
}
-} // namespace frontend
-} // namespace lyx
-Toolbars::ToolbarPtr make_toolbar(Toolba
Re: [patch] for LyX 1.5.3 register placeholders to the math toolbar
On Sun, Nov 04, 2007 at 08:33:59PM +0100, Uwe Stöhr wrote: > The attached patch registeres placeholders to the math toolbar and clarify > some entries. > OK for branch? > > regards Uwe > > p.s. lyx.org is currently dead In deep coma. But I did get a commit through... - Martin
