Jean-Marc Lasgouttes wrote:
> > 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.
How about the attached?
Jürgen
Index: src/fr
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> This is _my_ bottom line indeed. The thing (menu entries) were removed 3
> years
> ago. I don't remember any complaint about this, except for Bo's. Sorry, Bo,
> this is not enough reasoning to change the ui in a minor release; you can
> customiz
"Bo Peng" <[EMAIL PROTECTED]> writes:
> At least you agree that 1. this is a problem,
I'd have to blind not to see that this is a problem to you at least.
However, I cannot say that this has been a hot topic on lyx-users
after 1.4 release.
> 2. you use bold a lot,
In math (aka \mathbf). This is
Jürgen Spitzmüller wrote:
Edwin Leuven wrote:
the attached patch checks only the first action on a panel instead of all
(this won't change the behavior for the panels we ship)
because in the panels, we currently have all or nothing enabled, right?
because all the actions in the panels are t
Edwin Leuven wrote:
> the attached patch checks only the first action on a panel instead of all
>
> (this won't change the behavior for the panels we ship)
because in the panels, we currently have all or nothing enabled, right?
Jürgen
Helge Hafting wrote:
> Leave every option enabled
> and just don't do anything when the user tries something impossible.
> This should be an easy patch.
I doubt this will be much easier (you still have to check). And it's risky: we
had countless crashes in tha past because an "impossible" action
Abdelrazak Younes wrote:
> And not even compiled... here is another one that compiles and seems to
> work fine.
This looks very sensible.
I asked the reporters on bugzilla for testing, to assure the this fixes the
bug.
Jürgen
Uwe Stöhr wrote:
> 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 case the argument om
Dear Uwe,
Thanks for reminding. Here, I send you the updated file.
Alex
PS. I resend my e-mail, since I had problems with my ISP
Uwe Stöhr írta:
> Hello Alex,
>
> could you eventually translate section 5.2.2 of the Czech Tutorial.lyx
> (latest SVN 1.5.x branch version)?
> If you find some time
Jean-Marc Lasgouttes wrote:
> 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 math
Bo Peng wrote:
> And lib/images/font-bold.png is there (and was surely used).
No. Have a look at what icons are there. We just provide these for people who
want to customize their toolbars.
Jürgen
Martin Vermeer wrote:
> Even for charstyles? They used to use a different open/close mechanism
> (now fixed in trunk)
Yes, just checked again: all-insets-toggle works for charstyles in 1.5. Here's
the change:
http://www.lyx.org/trac/changeset/
Jürgen
On Sun, Sep 30, 2007 at 08:08:25PM +0200, Jürgen Spitzmüller wrote:
> Martin Vermeer wrote:
> > For trunk, yes.
>
> Even for branch, I think (I remember having implemented this some time ago).
>
> Jürgen
Even for charstyles? They used to use a different open/close mechanism
(now fixed in trunk)
On Sun, Sep 30, 2007 at 10:44:37PM +0200, Helge Hafting wrote:
> 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 o
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
> 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
> Could someone please apply the same patch to the trunk?
Done.
regards Uwe
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
> >
> >
> 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
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
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
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
> > 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
> >
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
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
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'
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
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
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
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
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
> 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
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
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'
[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
> It was a rhetorical answer. I couldn't let you go having the last word.
I am relieved.
JMarc
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.
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
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
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:
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
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
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
> > 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 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
> 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
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
> > 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
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
Martin Vermeer wrote:
> I seem to remember there was a menu item, yes.
When? When has it been removed?
Jürgen
Martin Vermeer wrote:
> For trunk, yes.
Even for branch, I think (I remember having implemented this some time ago).
Jürgen
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
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
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
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
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
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
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
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?
> >>>
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 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
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
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
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
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
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
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 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
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
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
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
Andre Poenitz <[EMAIL PROTECTED]> writes:
> So reformulate "short"?
Thanks.
JMarc
"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
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
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
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
> 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: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: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
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
> > 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
> Wrt 1.5, however, please wait with this a few days, until 1.5.2 is out.
That was my plan too.
Bo
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
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
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
Bo Peng wrote:
> The bottom line is: some sort of bold is needed.
Your bottom line.
Jürgen
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:
> 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.
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
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:
> 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:
> 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
"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
[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
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
> 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
> > > 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
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'
1 - 100 of 114 matches
Mail list logo
