headers
Maria G. | 1 Oct 2005 01:32
Picon

LyX - look and feel

Hi -
I've set up a theme for Linux, so that application windows look 
green instead of grey.  LyX, however, despite being an excellent 
document processor, especially for maths, still looks grey.  It would 
be really nice if LyX could conform to the L&F of the environment it 
is installed in,
Thank you,
Maria G.
Permalink | Reply | 1 comment |
headers
Martin Vermeer | 1 Oct 2005 08:23
Picon
Picon

Re: LyX speedup patch

On Fri, 30 Sep 2005 10:00:22 +0200 Jean-Marc Lasgouttes
<Jean-Marc.Lasgouttes@...> wrote:

> >>>>> "Martin" == Martin Vermeer <martin.vermeer@...> writes:
> 
> Martin> On Thu, Sep 29, 2005 at 09:00:47PM +0200, Helge Hafting wrote:
> >> The patch did not apply well to todays CVS.
> >> 
> >> Helge Hafting
> 
> Martin> OK, here's a fresh patch.
> 
> I'll try it out. Note though that the patches to ChangeLogs do not
> apply because of a unicode<=>latin1 conversion.
> 
> JMarc
> 

What's wrong? As far as I remember my additions to the changelogs are US ASCII.

- Martin
Permalink | Reply | 0 comments |
headers
Angus Leeming | 1 Oct 2005 09:08
Favicon

Re: LyX - look and feel

Maria G. wrote:
> Hi -
> I've set up a theme for Linux, so that application windows look 
> green instead of grey.  LyX, however, despite being an excellent 
> document processor, especially for maths, still looks grey.  It would 
> be really nice if LyX could conform to the L&F of the environment it 
> is installed in,
> Thank you,
> Maria G.

Hi, Maria.

Which frontend are you using? XForms or Qt?

The XForms frontend will never conform to your L&F unless you manually 
change it using the Edit->Preferences dialog. I don't suppose that this 
will ever change.

The Qt frontend does whatever any Qt app does in regard of look and feel. 
It certainly responds to look and feel changes here.

Angus
Permalink | Reply | 0 comments |
headers
Georg Baum | 1 Oct 2005 12:18
Picon
Picon

Re: The build broke today, *** No rule to make target `ro_TOC.lyx', needed by `all-am'. Stop.

Am Freitag, 30. September 2005 16:11 schrieb Kayvan A. Sylvan:
> I get this (in my automated builds):
> 
> [...]
> config.status: creating development/lyx.spec
> config.status: creating lib/Makefile
> config.status: creating lib/doc/Makefile
> config.status: error: cannot find input file: lib/doc/Makefile.in
> error: Bad exit status from /var/tmp/rpm-tmp.76369 (%build)
> 
> Looks like a forgotten file for "make dist".

Not one file, but all files in lib/doc. My trick for forcing the 
generation of the TOC files did not work. For a reason I don't understand 
make complains that it can't build the TOC files, although we have rules 
to build them.
The attached patch fixes this for me. Kayvan, can you please test whether 
it works for you, too?

Georg
Attachment (TOC2.diff): text/x-diff, 8 KiB
Permalink | Reply | 2 comments |
headers
Georg Baum | 1 Oct 2005 19:58
Picon
Picon

[patch] fix bug 2060

See http://bugzilla.lyx.org/show_bug.cgi?id=2060. The problem is that 
macros with no arguments are stored as a MathNestInset with 0 cells, and 
that MathNestInset::editXY() assumes at least one cell.
I fixed that and added two more checks for 0 cells which I think are 
necessary.

OK to commit?

Georg
Attachment (math-macro-crash.diff): text/x-diff, 1985 bytes
Permalink | Reply | 15 comments |
headers
Georg Baum | 1 Oct 2005 21:47
Picon
Picon

[patch] fix bug 2050

See http://bugzilla.lyx.org/show_bug.cgi?id=2050. Math mcros that contain 
\kern are misrendered on screen. The fix is obvious, and I could not 
reproduce the crash.
I propose to put this in. If the crash reappears we may find out the real 
reason, but for now I think that it is gone.

OK?

Georg
Attachment (2050.diff): text/x-diff, 1158 bytes
Permalink | Reply | 2 comments |
headers
Juergen Spitzmueller | 2 Oct 2005 11:42
Picon
Favicon

Re: Bug 2058: LyX crashes when attempting to undo matrix deletion

Daniel Watkins wrote:
> Bug 2058 (http://bugzilla.lyx.org/show_bug.cgi?id=2058): LyX crashes
> when attempting to undo matrix deletion
> Description:
> When I attempt to undo (using Ctrl-Z) the deletion of a matrix (deleted
> by pressing Backspace at the start of the top-left box), LyX crashes
> with the appended CLI output.

The attached patch fixes it for me.

Jürgen
Attachment (2058.diff): text/x-diff, 1159 bytes
Permalink | Reply | 4 comments |
headers
Andre Poenitz | 2 Oct 2005 12:34
Picon

Re: [patches 13x, 14x] wrappers for ShGetFolderPath, GetLongPathName

On Mon, Sep 26, 2005 at 08:01:10PM +0100, Angus Leeming wrote:
> Andre Poenitz wrote:
> 
> > On Mon, Sep 26, 2005 at 03:51:00PM +0100, Angus Leeming wrote:
> >> Just for completeness, here are patches that I believe will allow
> >> tex2lyx to run successfully on Win95 and Win98 and will allow both LyX
> >> 1.3.x and LyX 1.4.x to be used as a conversion filter on such machines.
> >> (It's likely that Qt/WinFree will die a horrible death though...)
> 
> > Given that Qt 4 is (also) GPL'ed on Win this seems quite certain.
> 
> Right, but we'll need to patch our qt frontend source code to use Qt4, no?

'patch' would be a proper British understatement.
'rework' would be closer in a continental climate.

> (Ie, that won't happen until the LyX 1.5 cycle.)

Sure.

> And, anyway, I actually meant that running an executable compiled against
> Qt/WinFree will die a horrible death today on Win98. Apparently.
> 
> > Btw, some good news on the Qt front: it starts getting usable
> > performance-wise with 4.0.1
> > (Don't tell the Trolls, though...)
> 
> Yes, I've been keeping half an eye on your posts to the qt-devel list.

The nice thing is that the respond positively to pushing...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andre Poenitz | 2 Oct 2005 13:26
Picon

Re: LyX speedup patch

On Tue, Sep 27, 2005 at 05:51:47PM +0300, Martin Vermeer wrote:
> Sort of. But how would you do that? And how would you achieve this while 
> preserving one-paragraph update where that is what you want? I sort of 
> see what you are hinting at, but I have no idea how to do it.

The whole update machinery is still in a somewhat unsatisfactory state.

We can make it work but simply doing more than we actually need, but
making it efficient and complete seems to be tricky.

I have been thinking about it since Martin's first patches arrived on
the list, and by now I am faily confident that it is achievable, but
not without effort.

Up to 1.3.x we have 'The old update machinery', which tries to do
immediate, but minimal updates. It has certain limitations to 'minimal'
as we e.g. rebreak whole paragraphs there, and behaviour is not excatly
deterministic as updates go up and down the inset hierarchy until thinks
have settled. Sometimes finishing was enforced by explicit 'premature'
braking endless loops and such.

In current 1.4.0cvs we have 'update everything' which is conceptionally
pretty robust but seemingly too slow in some cases.

In my opinion we should just make it faster and retain the simplicity of
the concept and only add structural changes if really necesary.
Currently we have four(!) calls to Paragraph::redoParagraph() for a 
single paragraph. Obviously, the concept requires only a single one.

Moreover, redoParagraph examines each item twice (in rowBreakPoint()
(Continue reading)

Permalink | Reply | 10 comments |
headers
Andre Poenitz | 2 Oct 2005 12:41
Picon

Re: [Patch] Re: Scroll wheel etc. with this doc

On Tue, Sep 27, 2005 at 07:51:05AM +0200, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > -           // display style insets are always centered, omit indentation
> > -           && !(!par.empty()
> > -                   && par.isInset(pos)
> > -                   && par.getInset(pos)->display())
> > +           // insets at start of line are never indented
> > +           && !(!par.empty() && par.isInset(pos))
> 
> I'm not sure if this is a good idea. I think e.g. Footnotes in an empty par 
> should definitely be indented, because they are in the output.
> 
> Is there no way to just let the insets take care of leftMargin?

Sounds like a good idea.

Andre'
Permalink | Reply | 0 comments |

Gmane