Uwe Stöhr wrote:
> Since I got no response from the marvosym package maintainer, g-brief won't
> be usable for MiKTeX and TeXLive 2007 users. I therefore added a warning to
> the templates to switch to g-brief2.
>
> What do you think?
Fine with me.
Jürgen
Uwe Stöhr wrote:
> Is the attached patch OK to go into trunk?
I rather don't like to put all these in the menus. A dialog (or a context
menu) would be much better ui.
Jürgen
Bo Peng wrote:
> > But the information what kind of char style this is ois still available
> > somewhere? In the status line perhaps when the cursor is inside the
> > style inset perhaps?
>
> I think the font used in such an inset is (almost) enough to tell us
> what kinds of charstyle it is. If so
[EMAIL PROTECTED] wrote:
> + // but when the user has chosen a non-default
> inner_pos, the height + // must be given:
> \minipage[pos][height][inner-pos]{width} + if
> (params_.height != Length("1in") ||
> +
Should be uncontroversial, but I'll wait for a nod.
I have a few more controversial ones up my sleeve...
Andre'
Index: Rules
===
--- Rules (revision 20603)
+++ Rules (working copy)
@@ -12,6 +12,7 @@
but still, we don't
Abdelrazak Younes wrote:
Richard Heck wrote:
[...]
By the way, can someone explain to me what FitCursor is?
FitCursor will trigger a screen re-centering around the current cursor
position if the cursor is outside the visible area.
Apparently not only when the cursor is outside. Make a tabl
Richard Heck wrote:
Helge Hafting wrote:
A really strange test:
I compiled LyX, ran it, and couldn't type fast.
If I press down 10 keyboard keys at the same time, then I get
instant response (10 lowercase letters) in xterm. LyX outputs the
characters one by one! I could type a little faster than
I want to get rid of those parts of boost that have an
exceptionally bad overhead.
Patch to replace boost::noncopyable with a homemade version attached.
This is to avoid a discussion on the "expressiveness" of
#include "something"
class Foo : NonCopiable {
...
On Sat, Sep 29, 2007 at 08:53:13AM -0500, Bo Peng wrote:
> I am confused. In a .lyx file, we have
>
> emph \emph on/default
> bold \series bold/default
> code \family typewriter
> noun \noun on
>
> So you want to define charstyle bold, emph, code and noun and lyx2lyx
> everything to something li
On Sat, Sep 29, 2007 at 05:27:51PM +0200, Jürgen Spitzmüller wrote:
> Bo Peng wrote:
> > > C-b works here.
> >
> > Why do not you remove C-b as well if you decide to hide it? If you
> > have C-b, why cannot you have Toggle bold menu item (and toolbar
> > icon)?
>
> This is nonsense. I do not argu
Martin Vermeer wrote:
> Actually we do... it is called strong.
In 1.5? Where?
Jürgen
On Sun, Sep 30, 2007 at 09:38:51AM +0200, Jürgen Spitzmüller wrote:
> Bo Peng wrote:
> > > But the information what kind of char style this is ois still available
> > > somewhere? In the status line perhaps when the cursor is inside the
> > > style inset perhaps?
> >
> > I think the font used in su
On Sun, Sep 30, 2007 at 01:20:58PM +0200, Jürgen Spitzmüller wrote:
> Martin Vermeer wrote:
> > Actually we do... it is called strong.
>
> In 1.5? Where?
Ah... no.
- Martin
Martin Vermeer wrote:
> Yes, that has been my idea too. Should be done in a way that also works
> in trunk. I believe that LaTeX document charstyles should start by not
> displaying the label (which Bo's patch does),
Probably yes.
> but for 'elements' in docbook you want to see the label.
Also
Hi,
After much work I've isolated the string that is causing the trouble. The
string id is 3569. The string itself is "[[Replace with the code of your
language]]". No matter what I'm writing as a translation (I even tried to
omit the square brackets) I'm getting the error I've described. If I don'
> > > Actually we do... it is called strong.
> >
> > In 1.5? Where?
>
> Ah... no.
In any case, bold icon and menu item can be added. In 1.5.x, bold can
be \textrm, and in 1.6.x, bold will be \strong.
The bottom line is: some sort of bold is needed.
Bo
> Also for some other charstyles. Consider a "letterspaced" char style. Since we
> cannot emulate letterspacing in the workarea, I'd prefer the label to be
> shown initially.
There be no way to reach a consensus here. I propose that
1. apply the patch for 1.5.x and 1.6.x
2. add a 'ShowLabel' keyw
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Autoraise is asking for trouble anyway.
>
> It has been working for me for 15 years and I fail to see why it
> suddenly should not.
That's what I thought about qt 3.0 and LyX...
JMarc
[EMAIL PROTECTED] writes:
> Author: poenitz
> Date: Sat Sep 29 22:02:32 2007
> New Revision: 20598
>
> URL: http://www.lyx.org/trac/changeset/20598
> Log:
> cosmetics
> (maily move layout related enums into a header of there own to remov
> include dependencies, alos rename a few things)
Aren't yo
Martin Vermeer <[EMAIL PROTECTED]> writes:
> That was what I had in mind, yes. I know there has been opposition to
> that, but charstyles look a lot better now.
I do not think that bold should be a charstyle. It kind of defeats the
idea.
Even if fonts are turned to insets, they should be kept se
Andre Poenitz <[EMAIL PROTECTED]> writes:
> We recently also had a "updateLabel()" creep. By now there are 38
> instances of updateLabels() in the code. This somehow does not
> sound right.
sigh.
JMarc
Martin Vermeer <[EMAIL PROTECTED]> writes:
> I still think at least bold should be named 'strong'.
> Cf. the way emph and noun are done.
This is wrong if what it really does (as now) is \textbf.
JMarc
Andre Poenitz <[EMAIL PROTECTED]> writes:
> I remember sending at least two messages to the list saying that calling
> QClipboard::text() is an extremely expensive operation and should be
> avoided.
I am not sure I ever saw your rumored Bromarv message about how
selection should be done.
JMarc
Bo Peng wrote:
> There be no way to reach a consensus here. I propose that
>
> 1. apply the patch for 1.5.x and 1.6.x
> 2. add a 'ShowLabel' keyword to CharLayout definition. Because this
> involves lyx2lyx, it can only be done for 1.6.x. (This will have low
> priority, but I will do it before 1.6.
Richard Heck <[EMAIL PROTECTED]> writes:
> Second, every toolbar is updated every time through here EVEN IF IT IS
> NOT DISPLAYED. I found this out because hiding the standard toolbar
> made no difference. This is a waste.
This should definitely be fixed.
> Third, even under the best of circumst
Uwe Stöhr <[EMAIL PROTECTED]> writes:
> Is the attached patch OK to go into trunk?
It would be better to have a dialog, or to implement space toggling
like in mathed.
JMarc
Bo Peng wrote:
> The bottom line is: some sort of bold is needed.
Your bottom line.
Jürgen
Jean-Marc Lasgouttes wrote:
> I do not think that bold should be a charstyle. It kind of defeats the
> idea.
>
> Even if fonts are turned to insets, they should be kept separate
> concepts.
+ 1.
We need a gui for charstyles, then people can attribute bold to whatever
entity they want.
And those
Andre Poenitz <[EMAIL PROTECTED]> writes:
> -We also require you to provide a ChangeLog entry with every patch, this
> -describes shortly what the patch is doing. The ChangeLog entry follows
> -this syntax:
> +We also require you to provide a commit message entry with every patch,
> +this describe
> Wrt 1.5, however, please wait with this a few days, until 1.5.2 is out.
That was my plan too.
Bo
> > The bottom line is: some sort of bold is needed.
>
> Your bottom line.
It is the least-surprise bottom line.
I will give up if you can find *any* popular word processor that does
not have bold in menu or toolbar.
Bo
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> > It has been working for me for 15 years and I fail to see why it
>> > suddenly should not.
>>
>> That's what I thought about qt 3.0 and LyX...
>
> As far as I remember Qt started in 1992, but not with version 3.0...
It is a metaphor. I really need t
On Sun, Sep 30, 2007 at 05:26:39PM +0200, Jean-Marc Lasgouttes wrote:
> [EMAIL PROTECTED] writes:
>
> > Author: poenitz
> > Date: Sat Sep 29 22:02:32 2007
> > New Revision: 20598
> >
> > URL: http://www.lyx.org/trac/changeset/20598
> > Log:
> > cosmetics
> > (maily move layout related enums into a
On Sun, Sep 30, 2007 at 05:34:20PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > I remember sending at least two messages to the list saying that calling
> > QClipboard::text() is an extremely expensive operation and should be
> > avoided.
>
> I am not sure
On Sun, Sep 30, 2007 at 05:25:08PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >> Autoraise is asking for trouble anyway.
> >
> > It has been working for me for 15 years and I fail to see why it
> > suddenly should not.
>
> That's what I thought about qt 3.0 an
> And those who will not learn should still be able to use physical markup
> (although they should not be able to do this easily).
You guys are too idealistic.
There is nothing wrong to advocate charstyle, but there is no reason
to discourage the use of simple physical markup either. For simple
t
On Sun, Sep 30, 2007 at 05:37:53PM +0200, Jean-Marc Lasgouttes wrote:
> Richard Heck <[EMAIL PROTECTED]> writes:
>
> > Second, every toolbar is updated every time through here EVEN IF IT IS
> > NOT DISPLAYED. I found this out because hiding the standard toolbar
> > made no difference. This is a wa
On Sun, Sep 30, 2007 at 05:42:51PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > -We also require you to provide a ChangeLog entry with every patch, this
> > -describes shortly what the patch is doing. The ChangeLog entry follows
> > -this syntax:
> > +We als
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> +lots---though, that said, there are times you just need a bit of boldface.
>
> It is easy enough for latex people to do \textbf{}. Why do we
> discourage the use of it??
But if we have Bold in the menus, why not sans serif? And what about
slanted?
Menus
Bo Peng wrote:
> I will give up if you can find *any* popular word processor that does
> not have bold in menu or toolbar.
There are two possible anwers to this, depending on the philosophy:
a.) LyX isn't a word processor
b.) LyX (if you disagree with a.)
I already told you about the concept of
"Bo Peng" <[EMAIL PROTECTED]> writes:
> There is nothing wrong to advocate charstyle, but there is no reason
> to discourage the use of simple physical markup either. For simple
> texts, bold and italic are perfect for their purposes. Because they
> are used so often, they deserve a place in menu
Andre Poenitz <[EMAIL PROTECTED]> writes:
> So reformulate "short"?
Thanks.
JMarc
Andre Poenitz <[EMAIL PROTECTED]> writes:
> Ah... "Sending Mail" and "Bromarv" somehow has a strong connotation to
> "Black Hole"...
>
> Could it be that I sent the mails, but _in Bromarv_?
Yes.
JMarc
Bo Peng wrote:
> There is nothing wrong to advocate charstyle, but there is no reason
> to discourage the use of simple physical markup either. For simple
> texts, bold and italic are perfect for their purposes. Because they
> are used so often, they deserve a place in menu and toolbar.
I disagre
Abdel,
we have a problem... are you sure the stuff you did with dimension and
coord cache is OK for InsetMathFrac? I see misrendering and crashes,
but the latter only for UNIT.
- Martin
On Sun, Sep 30, 2007 at 05:15:40PM +0200, Andre Poenitz wrote:
> On Sun, Sep 30, 2007 at 04:12:47PM +0300, Ma
On Sun, Sep 30, 2007 at 05:30:02PM +0200, Jean-Marc Lasgouttes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> > That was what I had in mind, yes. I know there has been opposition to
> > that, but charstyles look a lot better now.
>
> I do not think that bold should be a charstyle. It kin
Andre Poenitz wrote:
I want to get rid of those parts of boost that have an
exceptionally bad overhead.
Patch to replace boost::noncopyable with a homemade version attached.
If you're confident about the code, I don't myself see any loss---except
the 30,000 lines of code.
rh
This is to av
On Sun, Sep 30, 2007 at 04:51:36PM +0200, Ran Rutenberg wrote:
> Hi,
>
> After much work I've isolated the string that is causing the trouble. The
> string id is 3569. The string itself is "[[Replace with the code of your
> language]]". No matter what I'm writing as a translation (I even tried to
On Sun, Sep 30, 2007 at 05:56:22PM +0200, Jürgen Spitzmüller wrote:
> Bo Peng wrote:
> > I will give up if you can find *any* popular word processor that does
> > not have bold in menu or toolbar.
>
> There are two possible anwers to this, depending on the philosophy:
>
> a.) LyX isn't a word pro
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Second, every toolbar is updated every time through here EVEN IF IT IS
NOT DISPLAYED. I found this out because hiding the standard toolbar
made no difference. This is a waste.
This should definitely be fixed.
And it
Helge Hafting wrote:
Richard Heck wrote:
Helge Hafting wrote:
A really strange test:
I compiled LyX, ran it, and couldn't type fast.
If I press down 10 keyboard keys at the same time, then I get
instant response (10 lowercase letters) in xterm. LyX outputs the
characters one by one! I could typ
Jürgen Spitzmüller wrote:
Bo Peng wrote:
But the information what kind of char style this is ois still available
somewhere? In the status line perhaps when the cursor is inside the
style inset perhaps?
I think the font used in such an inset is (almost) enough to tell us
what kinds of
On Sun, Sep 30, 2007 at 05:50:31PM +0200, Andre Poenitz wrote:
> On Sun, Sep 30, 2007 at 05:34:20PM +0200, Jean-Marc Lasgouttes wrote:
> > Andre Poenitz <[EMAIL PROTECTED]> writes:
> >
> > > I remember sending at least two messages to the list saying that calling
> > > QClipboard::text() is an ext
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
during the theClipboard().empty() check. So I did
On Sun, Sep 30, 2007 at 12:43:03PM -0400, Richard Heck wrote:
> Jürgen Spitzmüller wrote:
> >Bo Peng wrote:
> >
> >>>But the information what kind of char style this is ois still available
> >>>somewhere? In the status line perhaps when the cursor is inside the
> >>>style inset perhaps?
> >>>
Martin Vermeer wrote:
> > Another possibility is for the label to be toggleable (sp?). Much like
> > we have with---ERT? Then all you need is something in the layout file
> > that will tell whether to display the label by default.
> We have this already... try the right mouse button. (Documentatio
Le 30 sept. 07 à 18:32, Martin Vermeer a écrit :
On Sun, Sep 30, 2007 at 04:51:36PM +0200, Ran Rutenberg wrote:
Hi,
After much work I've isolated the string that is causing the
trouble. The
string id is 3569. The string itself is "[[Replace with the code
of your
language]]". No matter what
Richard Heck wrote:
> > Should be easy to solve.
>
> Can you fix this, Abdel? Unfortunately, I do not have time now, as I'd
> have to learn a lot about this code before I'd know what to do, and I
> have a lecture to give next weekend at a big conference. It would be
> really, really nice if a fix c
Martin Vermeer wrote:
> But for 1.5 we don't have the infrastructure. People want to
> bold/strongly emphasize stuff. We should allow them as well we can. How?
We hadn't the infrastructure before, and we hadn't a bold button AFAIR. Did we
ever have a menu? I don't see an urgent reason to do it no
Dov Feldstern wrote:
> I'm attaching a series of patches which are a step in the right
> direction, but still not there yet. However, I think that they only make
> things better, so I would be happy to have them applied once someone
> looks them over...
I let others comment on it. These patches mi
On Sun, Sep 30, 2007 at 06:59:47PM +0200, Jürgen Spitzmüller wrote:
> Martin Vermeer wrote:
> > But for 1.5 we don't have the infrastructure. People want to
> > bold/strongly emphasize stuff. We should allow them as well we can. How?
>
> We hadn't the infrastructure before, and we hadn't a bold bu
On Sun, Sep 30, 2007 at 06:54:13PM +0200, Jürgen Spitzmüller wrote:
> Martin Vermeer wrote:
> > > Another possibility is for the label to be toggleable (sp?). Much like
> > > we have with---ERT? Then all you need is something in the layout file
> > > that will tell whether to display the label by d
Martin Vermeer wrote:
> For trunk, yes.
Even for branch, I think (I remember having implemented this some time ago).
Jürgen
Martin Vermeer wrote:
> I seem to remember there was a menu item, yes.
When? When has it been removed?
Jürgen
Jürgen Spitzmüller wrote:
> When? When has it been removed?
To answer myself: it has been removed with the switch to the new menus, in
2004. The entries are still in classic.ui.
Jürgen
> > When? When has it been removed?
>
> To answer myself: it has been removed with the switch to the new menus, in
> 2004. The entries are still in classic.ui.
And lib/images/font-bold.png is there (and was surely used).
Bo
Andre Poenitz wrote:
I want to get rid of those parts of boost that have an
exceptionally bad overhead.
Patch to replace boost::noncopyable with a homemade version attached.
This is to avoid a discussion on the "expressiveness" of
#include "something"
class Foo : NonCopiabl
> What are the cases where you use bold?
Bold and italic are for emphasis. In the book I am writing, italic
(actually \em) is used for definitions and bold is used in other cases
like note.
Of course I can define for every case a charstyle like emph_note,
emph_description, emph_blah, but I do not
On Sun, Sep 30, 2007 at 05:48:22PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> > It has been working for me for 15 years and I fail to see why it
> >> > suddenly should not.
> >>
> >> That's what I thought about qt 3.0 and LyX...
> >
> > As far as I remem
> > Aren't you reconstructing something we had a few month ago, before the
> > 'merge all files' frenzy?
>
> Do you think so?
>
> Hm... maybe we should setup some objective measurement. "Total number of
> compiled code" comes to ming, i.e. sum over all line counts of all
> compilation units.
>
>
On Sun, Sep 30, 2007 at 06:01:05PM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > Ah... "Sending Mail" and "Bromarv" somehow has a strong connotation to
> > "Black Hole"...
> >
> > Could it be that I sent the mails, but _in Bromarv_?
>
> Yes.
I case you are
Richard Heck wrote:
Helge Hafting wrote:
Richard Heck wrote:
Helge Hafting wrote:
A really strange test:
I compiled LyX, ran it, and couldn't type fast.
If I press down 10 keyboard keys at the same time, then I get
instant response (10 lowercase letters) in xterm. LyX outputs the
characters on
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a design is very nice
Indeed. But maybe there is a way around that problem, short of reverting
to the math panel.
the attached patch checks only the first action on a panel instead of all
Martin Vermeer wrote:
Abdel,
we have a problem... are you sure the stuff you did with dimension and
coord cache is OK for InsetMathFrac? I see misrendering and crashes,
but the latter only for UNIT.
I'll have a look.
Abdel.
Richard Heck wrote:
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
Second, every toolbar is updated every time through here EVEN IF IT IS
NOT DISPLAYED. I found this out because hiding the standard toolbar
made no difference. This is a waste.
This should definitely
Bo Peng wrote:
And those who will not learn should still be able to use physical markup
(although they should not be able to do this easily).
You guys are too idealistic.
There is nothing wrong to advocate charstyle, but there is no reason
to discourage the use of simple physical markup e
Enrico Forestieri wrote:
On Wed, Sep 26, 2007 at 06:12:51PM +0200, Pavel Sanda wrote:
On a clean checkout of trunk, I get:
This is long known issue.
Enrico posted patch before few days, but nobody comited it.
Should be fixed now.
Confiremd, a fresh checkout compiled for me.
> It was a rhetorical answer. I couldn't let you go having the last word.
I am relieved.
JMarc
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sun Sep 30 21:07:37 2007
New Revision: 20614
URL: http://www.lyx.org/trac/changeset/20614
Log:
* lib/templates/g-brief-en.lyx:
* lib/templates/g-brief-de.lyx: fix typos and wording
Could someone please apply the same patch to
On Sun, Sep 30, 2007 at 08:41:24PM +0200, Helge Hafting wrote:
> Good idea, it will hopefully save some compile time.
> I tried the patch, and unfortunately got:
I somehow managed to build an incomplete patch. Something different is
commited now.
Thanks for testing.
Andre'
Abdelrazak Younes wrote:
Leuven, E. wrote:
there is an issue with collapseables in trunk
open say a footnote and click inside it, and then outside. the
workareas then shifts
This is solved in latest trunk. Please report back if you see other
oddities.
Thanks a lot! I can now position the c
> So if we ship LyX with built-in "emph" and "strong" charstyles, then
> the users wanting bold and italic gets what they want. And we
> still have the advantages of charstyles - a special document
> class can override "strong" to do a color trick, for example.
1. charstyle is more difficult to us
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
during the theClipboard().emp
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
during the theClipboard().emp
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
First, the slowness is coming during the update of the standard
toolbar, in particular, during the update of the PASTE button, and
more precisely during the getStatus() call, and yet more precisely,
dur
Helge Hafting wrote:
Abdelrazak Younes wrote:
Leuven, E. wrote:
there is an issue with collapseables in trunk
open say a footnote and click inside it, and then outside. the
workareas then shifts
This is solved in latest trunk. Please report back if you see other
oddities.
Thanks a lot! I
Just for the record.
Current sizes of translation units:
Total: 24630751 lines
4 ../../development/cmake/src/dummy.cpp
4 ../../src/insets/InsetTheorem.cpp
15 ../../src/version.cpp
82 ../../src/Dimension.cpp
1585 ../../src/frontends/controllers/tests/b
Bo Peng wrote:
So if we ship LyX with built-in "emph" and "strong" charstyles, then
the users wanting bold and italic gets what they want. And we
still have the advantages of charstyles - a special document
class can override "strong" to do a color trick, for example.
1. charstyle is more
On Sun, Sep 30, 2007 at 10:19:04PM +0200, Abdelrazak Younes wrote:
> One question, there is still something I don't understand in this issue.
At the core of the issue is that qApp->clipboard()->text() is expensive.
So anything that removes these calls is Good(tm).
Andre'
Helge Hafting wrote:
Richard Heck wrote:
Helge Hafting wrote:
A really strange test: I compiled LyX, ran it, and couldn't type
fast. If I press down 10 keyboard keys at the same time, then I
get instant response (10 lowercase letters) in xterm. LyX outputs
the characters one by one! I could typ
Edwin Leuven wrote:
Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
calling this a design is very nice
I didn't dare to say it ;-)
Indeed. But maybe there is a way around that problem, short of
reverting to the math panel.
the attached patch che
> > 1. charstyle is more difficult to use than font change. For example,
> > if you have abcdef in a charstyle, and you want to change all or part
> > of them to normal style, several steps are needed. Toggle-bold etc are
> > much easier in this case. So, for simple cases, font-change is easier
> >
Martin Vermeer <[EMAIL PROTECTED]> writes:
> But for 1.5 we don't have the infrastructure. People want to
> bold/strongly emphasize stuff. We should allow them as well we can. How?
As juergen pointed out, this is something that dates back to LyX
1.4.0. We cannot add 'strong' support to 1.5 (forma
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Edwin Leuven wrote:
>> Richard Heck wrote:
Well, toolbars have not been designed for several dozens of entries.
>>
>> calling this a design is very nice
>
> I didn't dare to say it ;-)
FWIW, I agree that the toolbar design is awkward, and that
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> While I won't deny that LyX is doing *way* too much things on a single
> keystroke I might also add that the speed is OK on most systems.
I would interested to know whether stdlib-debug is a factor...
JMarc
> As juergen pointed out, this is something that dates back to LyX
> 1.4.0. We cannot add 'strong' support to 1.5 (format change). Bold is
> available through a couple of key bindings, which make it convenient
> for people who really need it (I use it a lot for bold maths). It is
> not easily disco
On Sun, Sep 30, 2007 at 11:11:49PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Edwin Leuven wrote:
> >> Richard Heck wrote:
> Well, toolbars have not been designed for several dozens of entries.
> >>
> >> calling this a design is very nice
> >
> >
> Could someone please apply the same patch to the trunk?
Done.
regards Uwe
> Uwe, why is this hardcoded to "1in"?
As I said, the idea is to omit the optional argument when the default is given. Therefore it makes
no difference when you set [1\height] or not. When the user don't want to use the optional argument,
the default "1\height" is internally used and in this ca
Abdelrazak Younes wrote:
One question, there is still something I don't understand in this
issue. In principle the X11 Clipboard should not be triggered if the
only thing you did was to select something in some other apps. The
only way this could happen is when this other app automatically put
1 - 100 of 114 matches
Mail list logo
