On Thu, Apr 23, 2009 at 08:41:54AM +0200, Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
>
> >> It's in the LyX/Cygwin package here:
> >> ftp://ftp.lyx.org/pub/lyx/bin/1.6.2/lyx-1.6.2-cygwin.tar.gz
> >
> > i see. imho worth to add such file somewere into development/.
>
> Why not in the manuals
Pavel Sanda wrote:
>> It's in the LyX/Cygwin package here:
>> ftp://ftp.lyx.org/pub/lyx/bin/1.6.2/lyx-1.6.2-cygwin.tar.gz
>
> i see. imho worth to add such file somewere into development/.
Why not in the manuals?
>> I think that a button "Use src-specials" coud be added to
>> Preferences->Outpu
On 2009-04-22, Pavel Sanda wrote:
> Enrico Forestieri wrote:
>> > i just asked if we can have (easily) something like View->DVI
>> > (reverse) in our output formats, which will work in normal lyx
>> > install, without any additional tweaks so xdvi works...
>> I think that a button "Use src-specia
Enrico Forestieri wrote:
> So, the bug is about "inverse DVI search", which is now implemented (and
> thus the bug should be either closed or renamed), but the last comments
> are about the "forward DVI search" feature.
i renamed the bug
pavel
Enrico Forestieri wrote:
> > > > you even don't use any
> > > > special converter preferences or scripts for yap?
> > >
> > > Only a wrapper is necessary. I attach here an excerpt of the README
> > > file in the LyX/Cygwin package, explaining everything.
> >
> > where is this file located? i just
On Thu, Apr 23, 2009 at 12:40:15AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > > > is this version patched somehow?
> > > >
> > > > No, it works OOTB on cygwin.
> > >
> > > hmmm i recently studied this bug:
> > > http://www.lyx.org/trac/ticket/94
> > > and thought this is not poss
On Wed, Apr 22, 2009 at 11:33:18PM +0200, Pavel Sanda wrote:
> hmmm i recently studied this bug:
> http://www.lyx.org/trac/ticket/94
> and thought this is not possible OOTB.
Now that I read bug 94, I think that there's some confusion there.
Inverse DVI search is already implemented in LyX. What i
Enrico Forestieri wrote:
> > > > is this version patched somehow?
> > >
> > > No, it works OOTB on cygwin.
> >
> > hmmm i recently studied this bug:
> > http://www.lyx.org/trac/ticket/94
> > and thought this is not possible OOTB.
>
> I think this has always been possible OOTB with xdvi, provided
On Wed, Apr 22, 2009 at 11:33:18PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Apr 22, 2009 at 06:08:12PM +0200, Pavel Sanda wrote:
> >
> > > Enrico Forestieri wrote:
> > > > On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> > > >
> > > > > I'm running LyX 1.6.2 on Wi
Enrico Forestieri wrote:
> On Wed, Apr 22, 2009 at 06:08:12PM +0200, Pavel Sanda wrote:
>
> > Enrico Forestieri wrote:
> > > On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> > >
> > > > I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> > > > searches from Yap back to
On Wed, Apr 22, 2009 at 06:08:12PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> >
> > > I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> > > searches from Yap back to the actual line in LyX. Is this possi
Enrico Forestieri wrote:
> On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
>
> > I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> > searches from Yap back to the actual line in LyX. Is this possible?
>
> This is possible only with the cygwin version of LyX.
is t
sykes wrote:
hi,
I'm running LyX 1.6.2 on Windows XP. I use the Tortoise SVN client for
subversion. I'm getting an error when I try to commit from within LyX:
"Some problem occured while running the command:
'svn commit -m " ... "
I'm assuming I need a command line client for svn to exec
On Tue, Apr 21, 2009 at 07:27:46PM -0700, sykes wrote:
> I'm running LyX 1.6.2 on Windows XP. I would like to perform inverse
> searches from Yap back to the actual line in LyX. Is this possible?
This is possible only with the cygwin version of LyX.
--
Enrico
Georg Baum wrote:
Abdelrazak Younes wrote:
I agree that we need two comparison methods. I am not sure though that
the operator==() should be lighter one. I 'd rather look at the all the
cases where it is used and replace them on a case by case with
equivalent() or isSimilarTo() as I suggeste
Abdelrazak Younes wrote:
> I agree that we need two comparison methods. I am not sure though that
> the operator==() should be lighter one. I 'd rather look at the all the
> cases where it is used and replace them on a case by case with
> equivalent() or isSimilarTo() as I suggested earlier. I fea
Andre Poenitz wrote:
On Tue, Mar 24, 2009 at 08:02:12AM -0400, rgheck wrote:
I had a similar concern. Just changing the semantics of operator== seems
dangerous. But another option would be, short term, to replace it by two
methods, get things working again, and then make one of them back i
On Tue, Mar 24, 2009 at 08:02:12AM -0400, rgheck wrote:
> I had a similar concern. Just changing the semantics of operator== seems
> dangerous. But another option would be, short term, to replace it by two
> methods, get things working again, and then make one of them back into
> operator==.
Abdelrazak Younes wrote:
Hi Georg,
Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will
be more
performance problems caused by the current FileName implementation. The
reason is simple: FileName once was a lightweight wrapper around a
string,
and it is still
Hi Georg,
Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will be more
performance problems caused by the current FileName implementation. The
reason is simple: FileName once was a lightweight wrapper around a string,
and it is still used in many places like tha
Vincent van Ravesteijn - TNW wrote:
>>Yes, that is the case I am aware of. I just tried, and the patch
> ensures
>>that you cannot open two buffers in that case. Note that there is still
>>a bug in setting path.d->name in FileName::onlyPath(), this needs to be
>>set from path.d->fi, not d->fi.
>
>> I could be wrong, but I think so, yes. The problem is that an
absolute
>> filename isn't the same as a canonical filename, i.e., one with
>> symlinks etc resolved. We don't want to open /home/me/file.lyx and
>> /tmp/file.lyx in different buffers if, in fact, they are the same
file.
>
>Yes, th
rgheck wrote:
> Georg Baum wrote:
>> rgheck wrote:
>>
>>> Unfortunately, the case where equivalence() is needed is one of the
>>> cases causing the performance problems.
>>>
>>
>> Honest question: Really?
>>
>>
> I could be wrong, but I think so, yes. The problem is that an absolute
> file
On Sun, Mar 22, 2009 at 01:48:39PM +0100, Georg Baum wrote:
> Apart from the performance changes, the patch corrects the following issues:
I can confirm that this patch solves the slowness problem with child
documents (I only checked it on Solaris). Well spotted Georg!
--
Enrico
Georg Baum wrote:
rgheck wrote:
Georg Baum wrote:
I believe that the performance problems could be solved quite easily by
basing FileName::operator==() on simple string comparison again and
implenting an equivalence() method that is used only when needed.
Unfortunately, the
rgheck wrote:
> Georg Baum wrote:
>> I believe that the performance problems could be solved quite easily by
>> basing FileName::operator==() on simple string comparison again and
>> implenting an equivalence() method that is used only when needed.
>>
>>
> Unfortunately, the case where equivale
Georg Baum wrote:
I believe that the performance problems could be solved quite easily by
basing FileName::operator==() on simple string comparison again and
implenting an equivalence() method that is used only when needed.
Unfortunately, the case where equivalence() is needed is one of the
Vincent van Ravesteijn - TNW wrote:
>>> Do we need a new class that we use internally. In this class we store
>
>>> a filename, which is case-sensitive on case-sensitive filesystem,
> that
>>> is guaranteed to be a long filename and not a short one (on Windows),
>
>>> that is not a symlink, that
Helge Hafting wrote:
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, t
>Seems excessive indeed. Ideally, typing text should be fine
>even with a "sleep(1)" in every filesystem interface. Just a
>slight stop whenever the emergency save happens.
That's why I now use a test document that I access via WebDav. It is
very rewarding to see the speed up then.
>Helge Hafti
rgheck wrote:
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to b
Hi all,
I'm not familar with the coding of LyX in any case - and so don't misinterpret
my comment as any kind of paternalism. LyX is a worthy successor of SciWord,
open source, and full of excellent ideas and work.
I have the same suspicion as Vincent: Each user input inside the master(not
onl
>> Do we need a new class that we use internally. In this class we store
>> a filename, which is case-sensitive on case-sensitive filesystem,
that
>> is guaranteed to be a long filename and not a short one (on Windows),
>> that is not a symlink, that is relative or absolute (pick one or
both).
>
Vincent van Ravesteijn - TNW wrote:
Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long file
> Maybe it's already clear,
Yes, I understand now.
How do we solve it then ?
Do we need a new class that we use internally. In this class we store a
filename, which is case-sensitive on case-sensitive filesystem, that is
guaranteed to be a long filename and not a short one (on Windows), that
The previous == and != checks had just been against the file NAMES,
which meant you could get file1 != file2, >if the names were symlinks
pointing to the same file, and names with different capatalizations
would be seen >as different on Windows, VFAT, etc. So Abdel changed it
to call QFileInfo::
-Original Message-
From: rgheck [mailto:rgh...@bobjweil.com]
Sent: donderdag 19 maart 2009 20:46
To: Vincent van Ravesteijn - TNW
Cc: lyx-devel@lists.lyx.org
Subject: Re: LyX 1.6.2: possible performance issue inside master
document
Vincent van Ravesteijn - TNW wrote:
>
>
Vincent van Ravesteijn - TNW wrote:
So, if there are four filesystem-checks in Linux, there are at least
six on Windows and maybe the compiler does something smart when
os::internal_path does nothing.
That would make it worse. But enough worse that I see nothing
here? Is networ
Vincent van Ravesteijn - TNW wrote:
rgheck wrote:
By the way, can you remember what problem Bennet had which made you
adding the lhs.refresh() and rhs.refresh() lines to
FileName::operator==(). This solution looks a bit like "Abdel's
hammer".
Not right now, no, thou
>> So, if there are four filesystem-checks in Linux, there are at least
>> six on Windows and maybe the compiler does something smart when
>> os::internal_path does nothing.
>>
>>
>That would make it worse. But enough worse that I see nothing
>here? Is network file system performance much >s
rgheck wrote:
>>> By the way, can you remember what problem Bennet had which made you
>>> adding the lhs.refresh() and rhs.refresh() lines to
>>> FileName::operator==(). This solution looks a bit like "Abdel's
hammer".
>>>
>>>
>> Not right now, no, though it's probably on the list somewhere.
rgheck wrote:
By the way, can you remember what problem Bennet had which made you
adding the lhs.refresh() and rhs.refresh() lines to
FileName::operator==(). This solution looks a bit like "Abdel's hammer".
Not right now, no, though it's probably on the list somewhere. But I
think the proble
Vincent van Ravesteijn - TNW wrote:
As a data point, I don't see any slowdown in Linux, using latest
branch and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source
window, when (unsurprisingly) I do. Same result if I put the files
on a network drive.
Is it possible that LaTeX is being genera
>As a data point, I don't see any slowdown in Linux, using latest
>branch and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source
>window, when (unsurprisingly) I do. Same result if I put the files
>on a network drive.
>
>Is it possible that LaTeX is being generated, even though the window
>
Well list didn't accept the large files. Now with small ones. Slowness is the
same.
Thanks,
Zardoz
Original-Nachricht
> Datum: Thu, 19 Mar 2009 12:31:59 -0400
> Von: rgheck
> An: pseudo2...@gmx.at
> CC: lyx-devel@lists.lyx.org
> Betreff: Re: LyX 1.6.2: p
pseudo2...@gmx.at wrote:
Well, my attached zip-file has been rejected. I try the lyx-files.
An no, the latex "view source" window is not open.
OK, thanks.
As a data point, I don't see any slowdown in Linux, using latest branch
and Qt 4.4.3, under Fedora 8. UNLESS I open the View Source wi
pseudo2...@gmx.at wrote:
I've created some testdocument that reproduces the behaviour (where can files be uploaded?).
Just attach it.
rh
> If you are able to send me a test document (maybe privately) I'll have a
> look. Even better: put it in a new bugzilla entry.
>
I've created some testdocument that reproduces the behaviour (where can files
be uploaded?). (WinXP)
-> 1.6.1 (AltInstaller or Classic same behaviour): slow down in
On 2009-03-18, Richard Heck wrote:
> pseudo2...@gmx.at wrote:
>>> Child document opened alone or together with its parent?
>> For me it looks like heavy internal updating inside the master is done
>> for each included child-doc (it does not matter whether the child is
>> opend).
> I wish I had s
Well, I'll keep the traffic to the devel-list.
> I wish I had some idea why this is happening only on certain platforms.
> Or is it only on certain platforms? I've not seen reports of this
> behavior under Linux, but maybe there are people with similar problems.
>
> Have there been other change
Vincent van Ravesteijn - TNW wrote:
I wish I had some idea why this is happening only on
certain platforms. Or is it only on certain platforms?
I've not seen reports of this behavior under Linux, but
maybe there are people with similar problems.
Have there been other changes to the Windows or Ma
>I wish I had some idea why this is happening only on
>certain platforms. Or is it only on certain platforms?
>I've not seen reports of this behavior under Linux, but
>maybe there are people with similar problems.
>
>Have there been other changes to the Windows or Mac distributions from
>1.6.1 to 1
pseudo2...@gmx.at wrote:
Child document opened alone or together with its parent?
Performance inside the child document is much better. Only the master is
concerned. It does not matter whether the master is opened or not. It even does
not make any difference if the master or the child is
Hi all,
thank Abdelrazak Younes for the prompt answer.
so I'm not the only one (see users list: Lyx 1.6.2 unusably slow on the Mac)
> Child document opened alone or together with its parent?
Performance inside the child document is much better. Only the master is
concerned. It does not matter
Vincent van Ravesteijn - TNW wrote:
> Any sign of life from Joost yet ?
no.
Jürgen
Any sign of life from Joost yet ?
Vincent
pseudo2...@gmx.at wrote:
Hi all,
has anybody noticed some performance issues while editing inside a master
document that includes a number (say about 5 or more) of long child docs. The
same large document caused no problems in LyX 1.5.6
indication: cursor movement is annoyingly slow, fast typ
Jean-Marc Lasgouttes wrote:
> They just fixed the problem.
Thanks, I reset the links.
Jürgen
On Sat, Mar 14, 2009 at 11:16 PM, Jürgen Spitzmüller wrote:
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
FYI, I have put up binaries for the Eeepc 701.
http://www.ucc.asn.au/~mccabedj/eeepc/lyx-1.5.7-eeepc.tar.bz2
http://www.ucc.asn.au/~mccabedj/eeepc/lyx-1.6.2-eeepc.tar.bz2
Le 15 mars 09 à 13:21, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
I just sent a message to the ftp admins.
Thanks.
They just fixed the problem.
JMarc
On Sun, Mar 15, 2009 at 12:13:49PM +0100, Abdelrazak Younes wrote:
> On 15/03/2009 11:59, Jürgen Spitzmüller wrote:
>> Sven Hoexter wrote:
>>
>>> Now I just need to meet you to verify your key or find a trustpath to
>>> you. :) Hm no sigs on the key. Bad. But fair enough for the moment.
>>>
On Sun, Mar 15, 2009 at 2:02 PM, Anders Ekberg wrote:
> On 15 mar 2009, at 16.56, Jürgen Spitzmüller wrote:
>
>> BH wrote:
>>>
>>> The new version is now at:
>>>
>>> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
>>
>> It's online.
>
> Updated on http://www.apple.com/downloa
On Sun, Mar 15, 2009 at 11:56 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> The new version is now at:
>>
>> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
>
> It's online.
>
> Jürgen
>
Thanks.
Bennett
On 15 mar 2009, at 16.56, Jürgen Spitzmüller wrote:
BH wrote:
The new version is now at:
http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
It's online.
Updated on http://www.apple.com/downloads/macosx/
It should show up in a day or two.
/Anders
BH wrote:
> The new version is now at:
>
> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2.1-Mac-Universal.dmg
It's online.
Jürgen
On Sun, Mar 15, 2009 at 9:44 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> Can you remove the Mac binary for now? Uwe correctly identified that
>> problems I was having with typesetting the User's Guide are the result
>> of using Qt-4.5, and I'm currently recompiling with Qt-4.4. I'll post
>> a new
BH wrote:
> Can you remove the Mac binary for now? Uwe correctly identified that
> problems I was having with typesetting the User's Guide are the result
> of using Qt-4.5, and I'm currently recompiling with Qt-4.4. I'll post
> a new binary shortly.
OK. (I wouldn't have recommended Qt 4.5 for the
On Sun, Mar 15, 2009 at 7:31 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> I've put the Mac universal binary here:
>>
>> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2-Mac-Universal.dmg
>>
>> Could you upload it to the server?
>>
>> ... And thank you for your patience!
>
> Thanks, Bennett, Uwe a
Vincent van Ravesteijn wrote:
> But, that's probably because you don't have an installer from Joost yet..
exactly :-)
Jürgen
Vincent van Ravesteijn schreef:
Jürgen Spitzmüller schreef:
Jean-Marc Lasgouttes wrote:
I just sent a message to the ftp admins.
Thanks.
Note that the access via http
just works. We can use that as URLs.
Ah, excellent. Then I use that for the time being.
Jürgen
Please not
Jürgen Spitzmüller schreef:
Jean-Marc Lasgouttes wrote:
I just sent a message to the ftp admins.
Thanks.
Note that the access via http
just works. We can use that as URLs.
Ah, excellent. Then I use that for the time being.
Jürgen
Please note that in section 2.1 of http:
Jean-Marc Lasgouttes wrote:
> I just sent a message to the ftp admins.
Thanks.
> Note that the access via http
> just works. We can use that as URLs.
Ah, excellent. Then I use that for the time being.
Jürgen
Jürgen Spitzmüller writes:
> Vincent van Ravesteijn wrote:
>> But you did put it on the website ?
>
> Yes. I only realized that afterwards.
I just sent a message to the ftp admins. Note that the access via http
just works. We can use that as URLs.
JMarc
Vincent van Ravesteijn wrote:
> But you did put it on the website ?
Yes. I only realized that afterwards.
Jürgen
Jürgen Spitzmüller schreef:
BH wrote:
I've put the Mac universal binary here:
http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2-Mac-Universal.dmg
Could you upload it to the server?
... And thank you for your patience!
Thanks, Bennett, Uwe and Enrico,
your binaries are on the server
BH wrote:
> I've put the Mac universal binary here:
>
> http://edisk.fandm.edu/bennett.helm/lyx/LyX-1.6.2-Mac-Universal.dmg
>
> Could you upload it to the server?
>
> ... And thank you for your patience!
Thanks, Bennett, Uwe and Enrico,
your binaries are on the server or on the way to the server
On 15/03/2009 11:59, Jürgen Spitzmüller wrote:
Sven Hoexter wrote:
Now I just need to meet you to verify your key or find a trustpath to
you. :) Hm no sigs on the key. Bad. But fair enough for the moment.
Just tell me if there's anything I can do to make it more trustworthy.
You
Sven Hoexter wrote:
> Now I just need to meet you to verify your key or find a trustpath to
> you. :) Hm no sigs on the key. Bad. But fair enough for the moment.
Just tell me if there's anything I can do to make it more trustworthy.
Jürgen
> LyX 1.6.2 is here:
I've uploaded the alternative Windows installer here:
http://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=15926
Can you please put it to ftp.lyx.org?
thanks and regards
Uwe
On Sat, Mar 14, 2009 at 03:16:24PM +0100, Jürgen Spitzmüller wrote:
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
Please, find a cygwin binary here:
http://www.lyx.org/~forenr/lyx-1.6.2-cygwin.tar.gz
--
Enrico
On Sat, Mar 14, 2009 at 05:20:06PM +0100, Jürgen Spitzmüller wrote:
> Sven Hoexter wrote:
> > Is it possible to post the sha-/md5sum for the tarball on your
> > system?
>
> I intend to post the attached signatures on ftp.lyx.org. Would that be
> sufficient?
Sure. Thanks.
Now I just need to meet
On Sat, Mar 14, 2009 at 10:16 AM, Jürgen Spitzmüller wrote:
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
>
> As usual, I will wait a bit with the announce, to give the packagers the time
> to set up the binaries. I hope ftp.lyx.org will be back until then (I can log
> into the ser
Sven Hoexter wrote:
> Is it possible to post the sha-/md5sum for the tarball on your
> system?
I intend to post the attached signatures on ftp.lyx.org. Would that be
sufficient?
Jürgen
lyx-1.6.2.tar.gz.sig
Description: PGP signature
lyx-1.6.2.tar.bz2.sig
Description: PGP signature
On Sat, Mar 14, 2009 at 03:16:24PM +0100, Jürgen Spitzmüller wrote:
Hi Juergen,
> LyX 1.6.2 is here:
> ftp://ftp.devel.lyx.org/pub/lyx/stable
Is it possible to post the sha-/md5sum for the tarball on your
system?
Sven
--
If God passed a mic to me to speak
I'd say stay in bed, world
Sleep in pe
Vincent van Ravesteijn wrote:
> I've committed the two fixes for Qt4.5.
thanks.
> Are we set now or are there still more issues open ?
no, we are ready now. I'll set up the final tarball now.
> By the way, note that ftp.lyx.org/pub/lyx is still not available, so
> before releasing 1.6.2, we'll
Jürgen Spitzmüller schreef:
The test tarball is available here:
http://www.lyx.org/~spitz/lyx-1.6.2rc1.tar.gz
If no regressions are reported, this will become LyX 1.6.2. Please test.
Meanwhile, branch remains frozen until the freeze lift is announced (probably
end of next week).
Thanks,
Jürg
Jürgen Spitzmüller wrote:
(I wonder, however, why no one noticed earlier; am I the only one who uses
branch for daily work?)
I always do, but I've had so much administrative stuff to do that that
kind of daily work hasn't been happening of late
rh
Konrad Hofbauer wrote:
In 1.5.7, the screen scrolls half a screen.
In 1.6.1, the screen scrolls one line.
In most apps (TextEdit, TeXShop, Smultron) it scrolls half a screen.
In some other apps (TextWrangler, Word) it scrolls one line.
Personally, I prefer the 1.5.7-behaviour (recenter on scree
Jürgen Spitzmüller wrote:
BH wrote:
I've applied the equivalent patch to my local copy of 1.6.2. Jürgen:
Shall I package up the unpatched version for distribution (and risk
complaints) or stick with the current 1.6.2?
Uh ... what I meant was Well, you know what I meant.
O
Jürgen Spitzmüller wrote:
> > OK, OK. Since it seems so important to all of you, apply to branch, and
> > I'm gonna build another tarball on Friday.
>
> I did it myself. I probably can build another tarball today.
http://www.lyx.org/~spitz/lyx-1.6.2rc2.tar.gz
Jürgen
Jürgen Spitzmüller wrote:
> OK, OK. Since it seems so important to all of you, apply to branch, and I'm
> gonna build another tarball on Friday.
I did it myself. I probably can build another tarball today.
Jürgen
Jürgen Spitzmüller wrote:
> Vincent, I have already copied the content of status.16x to ANNOUNCE. Could
> you please add the description to both files?
Well, since it's a regression, no description is needed anyway.
Jürgen
BH wrote:
> > I've applied the equivalent patch to my local copy of 1.6.2. Jürgen:
> > Shall I package up the unpatched version for distribution (and risk
> > complaints) or stick with the current 1.6.2?
>
> Uh ... what I meant was Well, you know what I meant.
OK, OK. Since it seems so impor
On Sun, Mar 8, 2009 at 8:07 PM, BH wrote:
> I've applied the equivalent patch to my local copy of 1.6.2. Jürgen:
> Shall I package up the unpatched version for distribution (and risk
> complaints) or stick with the current 1.6.2?
Uh ... what I meant was Well, you know what I meant.
Bennett
On Sun, Mar 8, 2009 at 5:28 PM, Vincent van Ravesteijn
wrote:
> Fixed in trunk: http://www.lyx.org/trac/changeset/28730
>
> Is this better ?
>
> Vincent
Yes -- much. Thanks! (Can it be applied to branch, too?)
I've applied the equivalent patch to my local copy of 1.6.2. Jürgen:
Shall I package u
Abdelrazak Younes wrote:
> I am going to bet that you will have a lot
> of complains...
i have the same feeling
pavel
Abdelrazak Younes schreef:
On 08/03/2009 16:24, Jürgen Spitzmüller wrote:
BH wrote:
It used to be (with 1.6.1) that when the cursor was at the bottom of
the screen and was pressed, the screen would scroll down
one line, leaving the cursor still at the bottom. Now, pressing
will scroll a f
On Sun, 8 Mar 2009, Abdelrazak Younes wrote:
It used to be (with 1.6.1) that when the cursor was at the bottom of
the screen and was pressed, the screen would scroll down
one line, leaving the cursor still at the bottom.
Which is both expected behavior and desired when one is reading throug
On 08/03/2009 16:24, Jürgen Spitzmüller wrote:
BH wrote:
It used to be (with 1.6.1) that when the cursor was at the bottom of
the screen and was pressed, the screen would scroll down
one line, leaving the cursor still at the bottom. Now, pressing
will scroll a full screen, so that the cur
BH wrote:
It used to be (with 1.6.1) that when the cursor was at the bottom of
the screen and was pressed, the screen would scroll down
one line, leaving the cursor still at the bottom. Now, pressing
will scroll a *full* screen, so that the cursor is at the
next line in the document but at the
1 - 100 of 110 matches
Mail list logo
