Re: Compilation report and runtime report with Qt4.5

[Bennett Helm]

On Fri, Feb 27, 2009 at 10:18 AM, Abdelrazak Younes  wrote:
> No hurry on my side :-)

I thought it was Friday! (You didn't get a smiley from me)

Bennett

Re: Compilation report and runtime report with Qt4.5

[Bennett Helm]

On Fri, Feb 27, 2009 at 7:21 AM, Abdelrazak Younes  wrote:
> Bennett Helm wrote:
>>
>> On Wed, Feb 18, 2009 at 12:44 PM, Abdelrazak Younes 
>> wrote:
>>
>>>
>>> FYI I've compiled branch and trunk with the latest Qt4.5. It works fine
>>> AFAICT. The Qt4.5 is said to bring a lot of painting performance
>>> improvement
>>> on Mac (some qtlabs blog says up to 13x!). I guess it's worth testing
>>> that
>>> Bennett.
>>>
>>
>> Well, I tried it, but I don't see any difference at all when I scroll
>> through a long document. Perhaps the speed shows up in other ways, but
>> 13x improvement is pretty hard to believe for typical cases
>>
>
> By the way Bennett, did you try to compile Qt with the new raster graphics
> system? That's the only to see the performance improvment AFAIU.

No, I didn't. (Was I supposed to know that?)

I tried again, but I can't get it to compile with "-graphicssystem
raster", and I don't have time now to try to figure out what's going
wrong. Maybe after the official release

Bennett

Re: feature request: named sessions

[Bennett Helm]

On Thu, Feb 19, 2009 at 9:50 AM, rgheck  wrote:
> Vincent van Ravesteijn - TNW wrote:
>>
>>
>>>
>>> I have started a wiki page to maintain an informal spec:
>>>
>>> http://wiki.lyx.org/Devel/NamedSessions
>>>
>>> Please examine/edit to offer your suggestions. I've tagged
>>> it with [[!LyX 2_0]] though I don't know when v2.0 >is slated
>>> for release - I didn't see anyone use tags > 2_0
>>>
>>
>>
>> Is it really necessary to have a new top level menu item ?
>>
>>
>
> I don't know if it's necessary, but it is common in apps that support
> sessions.

I tend to think we should not unnecessarily multiply top level menus.
On Mac, Smultron.app is one text editor that supports named sessions,
which it calls "projects". These are supported in the File menu, which
has the following structure:

New...
New Project...
Open...
Open Project...
Open Recent
  [list of individual files and projects]
--
Close
Close Project
--
Save
Save As...
Revert
--
Save Documents as Project...


For this to work, Smultron carefully distinguishes (as LyX does not)
between documents open as tabs in a window from documents open in
other windows. So Save Documents as Project applies to all documents
belonging to the frontmost window. (Partly for this reason, Smultron
does not have need of -- or the flexibility provided by -- a Manage
Sessions dialog.)

In any case, I think LyX should do a better job than it does now
making the distinction mentioned above. It's disconcerting to have a
window with 3 tabs in it and to try (with the keyboard) to cycle
around these tabs only to find more tabs being added to that window
for documents that are displayed only in other windows. (Is that
description clear? ... Is that a problem for platforms other than
Mac?)

Bennett

Re: Compilation report and runtime report with Qt4.5

[Bennett Helm]

On Wed, Feb 18, 2009 at 12:44 PM, Abdelrazak Younes  wrote:
> FYI I've compiled branch and trunk with the latest Qt4.5. It works fine
> AFAICT. The Qt4.5 is said to bring a lot of painting performance improvement
> on Mac (some qtlabs blog says up to 13x!). I guess it's worth testing that
> Bennett.

Well, I tried it, but I don't see any difference at all when I scroll
through a long document. Perhaps the speed shows up in other ways, but
13x improvement is pretty hard to believe for typical cases

Bennett

Re: LyX 1.6.1

[Bennett Helm]

On Sun, Dec 14, 2008 at 4:34 AM, Jürgen Spitzmüller
 wrote:
> Bennett Helm wrote:
>> I've put the Mac binary here:
>>
>> http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.1-Mac-Universal.dmg
>>
>> Can someone place them on the server, please?
>
> Many thanks, Bennett.
> I put the binary on the server and adapted the download page.

Thanks!

Bennett

Re: LyX 1.6.1

[Bennett Helm]

On Sat, Dec 13, 2008 at 8:23 AM, Jürgen Spitzmüller
 wrote:
> I have uploaded the tarballs to the server. I will send the announcement on
> monday, so there's still some time to prepare binaries.

I've put the Mac binary here:

http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.1-Mac-Universal.dmg

Can someone place them on the server, please?

Bennett

Re: Modules loading preamble lines unnecessarily

[Bennett Helm]

On Sat, Nov 22, 2008 at 8:37 AM, rgheck <[EMAIL PROTECTED]> wrote:
> Bennett Helm wrote:
>>
>> Another possible module bug ... though perhaps one not worth fixing.
>>
>> Create a document and add a module like Endnotes. Checking the latex
>> source, merely adding the endnotes module doesn't change anything yet:
>> you have to add an endnote, and only then does the
>> \usepackage{endnotes} line get added to the preamble.
>>
>> However, if you add an endnote within a LyX Note (and nowhere else in
>> the document), the endnote will not appear in the LaTeX output, and
>> yet the \usepackage{endnotes} line is added to the preamble anyway --
>> unnecessarily.
>>
>> Should this not happen?
>>
>>
>
> This isn't module-specific. You'd find the same thing happened, say, with
> the use of AMS classes, if you have "Use AMS Automatically" checked. LyX
> isn't (currently) aware of what's being output and what isn't being output,
> at least not in this respect. So when it sees an endnote, it adds the
> package.

Fair enough.

By the way, the more I explore them, the more I realize modules are brilliant!

Bennett

Re: Modules Bug?

[Bennett Helm]

On Sat, Nov 22, 2008 at 8:33 AM, rgheck <[EMAIL PROTECTED]> wrote:
> You need to use AddToPreamble instead of Preamble. The Preamble command
> overwrites all previous Preamble declarations.
>
> I know that's silly, but that's how Preamble has always worked. It's also
> why I added AddToPreamble.

Ah -- that makes sense. What's confusing here is that "Preamble" when
used in defining paragraph styles, e.g., doesn't overwrite the
existing preamble. I wonder whether it would be worthwhile having
paragraph style definitions use "AddToPreamble" as well.

Bennett

Modules loading preamble lines unnecessarily

[Bennett Helm]

Another possible module bug ... though perhaps one not worth fixing.

Create a document and add a module like Endnotes. Checking the latex
source, merely adding the endnotes module doesn't change anything yet:
you have to add an endnote, and only then does the
\usepackage{endnotes} line get added to the preamble.

However, if you add an endnote within a LyX Note (and nowhere else in
the document), the endnote will not appear in the LaTeX output, and
yet the \usepackage{endnotes} line is added to the preamble anyway --
unnecessarily.

Should this not happen?

Bennett

Modules Bug?

[Bennett Helm]

In 1.6.1svn, I'm trying to create a couple of very simple modules that
basically load a single package. Here they are:

#\DeclareLyXModule{Show Labels}
#DescriptionBegin
#Displays all LaTeX labels in the margins.
#DescriptionEnd

Format 11

Preamble
\RequirePackage{showlabels}
EndPreamble

--

#\DeclareLyXModule{Draft Watermark}
#DescriptionBegin
#Adds a Draft watermark on the bottom of each page.
#DescriptionEnd

Format 11

Preamble
\RequirePackage{prelim2e}
EndPreamble

--

These both work when only one of them is loaded: the "\RequirePackage"
line shows up in the "Textclass specific LaTeX commands" section of
the preamble. However, when *both* are loaded, only the last one shows
up rather than both. Is this a problem with the way modules are
loaded, or am I doing something wrong in my module definitions?

Thanks.

Bennett

Re: Trunk crashes on launch

[Bennett Helm]

On Sun, Nov 16, 2008 at 9:10 AM, Andre Poenitz
<[EMAIL PROTECTED]> wrote:
> On Sun, Nov 16, 2008 at 03:01:45PM +0100, Jürgen Spitzmüller wrote:
>> Andre Poenitz wrote:
>> > > (I'm periodically checking to see how Andre's plans for world
>> > > domination are progressing. Don't know if this report is
>> > > premature)
>> >
>> > The instresting part is that I did not touch that particular part
>> > conciously. ut as I get the same crash I think I shall have a look
>> > soonish...
>>
>> FYI a complete rebuild (following make distclean) helped here.
>
> I was about to try that. It looks pretty strange in the debugger
> (mutilated std::string objects immediately after the default constructor
> run. The "only" difference was that the "broken" buikld was configured
> withotu sepcial options and the working one with -disable-stdlib-debug
> -disable-concept-checks, but possibly not in an empty directory.

Don't know if it was a change in the meantime or not, but I did a make
distclean, and it now works.

Thanks.

Bennett

Trunk crashes on launch

[Bennett Helm]

On Mac, of course:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfff5
0x96a06dfa in std::string::compare ()
(gdb) bt
#0  0x96a06dfa in std::string::compare ()
#1  0x0011a5da in lyx::setRcGuiLanguage () at LyX.cpp:237
#2  0x0011af45 in lyx::LyX::init (this=0xb228) at LyX.cpp:678
#3  0x0011bec1 in lyx::LyX::init (this=0xb228, [EMAIL PROTECTED],
argv=0xb270) at LyX.cpp:421
#4  0x0011c613 in lyx::LyX::exec (this=0xb228, [EMAIL PROTECTED],
argv=0xb270) at LyX.cpp:320
#5  0x2b89 in main (argc=1, argv=0xb270) at main.cpp:46


(I'm periodically checking to see how Andre's plans for world
domination are progressing. Don't know if this report is
premature)

Bennett

Re: LyX 1.5.7

[Bennett Helm]

On Thu, Nov 13, 2008 at 2:03 AM, =??B?SsO8cmdlbiBTcGl0em3DvGxsZXI=?=
<[EMAIL PROTECTED]> wrote:
> Bennett Helm wrote:
>
>> I've posted the Mac binary here:
>>
>> http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.5.7-Mac-Universal.dmg
>
> Thanks, I grabbed it.

Thanks!

Bennett

Re: LyX 1.5.7

[Bennett Helm]

On Wed, Nov 12, 2008 at 4:51 PM, =??B?SsO8cmdlbiBTcGl0em3DvGxsZXI=?=
<[EMAIL PROTECTED]> wrote:
>> I did notice that the NEWS file has not been updated. (I usually put
>> this into the LyX/Mac bundle.) Shall I wait to post the binary?
>
> I forgot this :-(
> Thanks.

I've posted the Mac binary here:

http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.5.7-Mac-Universal.dmg

Bennett

Re: LyX 1.5.7

[Bennett Helm]

On Wed, Nov 12, 2008 at 8:48 AM, =??B?SsO8cmdlbiBTcGl0em3DvGxsZXI=?=
<[EMAIL PROTECTED]> wrote:
> I've placed the tarball here:
> http://www.lyx.org/~spitz/lyx-1.5.7.tar.gz
>
> Please test, particularly if importing of 1.6 files works. If so, you can 
> also go ahead an prepare the binaries.

The 1.6 User's Guide imports and typesets, as does another complex,
book-length document of mine.

I did notice that the NEWS file has not been updated. (I usually put
this into the LyX/Mac bundle.) Shall I wait to post the binary?

Bennett

Re: Plans to announce LyX release 1.6.0

[Bennett Helm]

On Mon, Nov 10, 2008 at 7:44 AM, Konrad Hofbauer
<[EMAIL PROTECTED]> wrote:
> Question:
> In the user-directory, the examples-directory is empty. Is this how it is
> supposed to be, or should we give the examples the same treatment as the
> templates?
>
> As it is know, it is difficult to know about / find e.g. the
> beamerlyxexample. The user has to dig into the Application bundle, which
> most of them won't even know that this is possible/exists.
>
> But also this raises the question for me what distinguishes the examples
> from the "specialized manuals" and the default templates. But I vaguely
> remember there was a discussion about this not so long ago ...

I haven't done anything there because I think we should have a proper
solution: when launched, LyX should run a script that does some
clean-up operations and creates softlinks from the user's directory to
the relevant directories inside the LyX.app bundle. I'm attaching the
crude script I came up with as a proof of concept, but it needs a
proper developer to do it right.

See the thread here:

http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg133751.html

Bennett


lyx-start-script
Description: Binary data

Re: Plans to announce LyX release 1.6.0

[Bennett Helm]

On Fri, Nov 7, 2008 at 8:57 PM, Konrad Hofbauer <[EMAIL PROTECTED]> wrote:

> Compiles and looks fine on Mac.
> A Mac universal binary (without installer) at:
> 
> This is NOT for the server, of course.

Thanks, Konrad. I've put the packaged version here:

http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.0-Mac-Universal.dmg

Could someone upload it to the server?

Thanks.

Bennett

Re: LyX version 1.6.0 (release candidate 5) is released

[Bennett Helm]

On Sun, Nov 2, 2008 at 6:14 PM, Konrad Hofbauer <[EMAIL PROTECTED]>wrote:

> Anders Ekberg wrote:
>
>> Select a .lyx-document in Finder. Choose "Open with" and then
>> lyx-1.6.0-rc5
>> The result is that the document opens, but also that a splashscreen window
>> opens. The problem is that the menubar is connected to the splashscreen
>> window: If you close it (which you have to do by the close button on the
>> window sinyou will have no menubar except for the LyX-menu.
>> No error messages in the Console.
>>
>> Anders - On MacOSX 10.5.5 on intel.
>>
>
> Confirmed. The window in which the document opens also has no toolbars.
> Also applies for dragging a document onto the Dock-icon.
>
> Would you put this into bugzilla?
> Maybe put [EMAIL PROTECTED] in CC to the bug.


Isn't this the same as bug 5387? --

http://bugzilla.lyx.org/show_bug.cgi?id=5387

Bennett

Re: The tex4ht changes: please test!

[Bennett Helm]

On Sun, Nov 2, 2008 at 9:11 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]
> wrote:

> Bennett Helm wrote:
> > Putting aside my old LyX user's directory and launching LyX, it correctly
> > recognizes tex4ht and allows me to do a conversion. So it looks like it's
> > working. (Is there anything else I should test?)
>
> So you can succesfully open the Tutorial with OpenOffice after the
> conversion
> with current trunk?


 Yes. (Of course, the conversion is rough, but it does open without errors.)

Bennett

Re: The tex4ht changes: please test!

[Bennett Helm]

On Sun, Nov 2, 2008 at 8:12 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]
> wrote:

Any experiences on the Mac?


Putting aside my old LyX user's directory and launching LyX, it correctly
recognizes tex4ht and allows me to do a conversion. So it looks like it's
working. (Is there anything else I should test?)

Bennett

Re: LyX version 1.6.0 (release candidate 5) is released

[Bennett Helm]

On Tue, Oct 28, 2008 at 4:34 PM, José Matos <[EMAIL PROTECTED]> wrote:

> Public release of LyX version 1.6.0 (release candidate 5)
> =
>
> We are pleased to announce the fifth release candidate of LyX 1.6.0.


I've placed the Mac binary here:

http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.RC5-Mac-Universal.dmg

Can someone please upload it?

Thanks.

Bennett

Re: LyX version 1.6.0 (release candidate 4) is released

[Bennett Helm]

On Thu, Oct 23, 2008 at 7:26 PM, José Matos <[EMAIL PROTECTED]> wrote:

> Public release of LyX version 1.6.0 (release candidate 4)
> =
>
> We are pleased to announce the fourth release candidate of LyX 1.6.0.


I've put the Mac binary here:

http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.4RC4-Mac-Universal.dmg

Could someone please upload it?

Thanks.

Bennett

Re: rc4 release schedule

[Bennett Helm]

On Wed, Oct 22, 2008 at 3:56 PM, Stefan Schimanski <[EMAIL PROTECTED]> wrote:

>
> Am 22.10.2008 um 21:52 schrieb Konrad Hofbauer:
>
>
>>
>> Stefan Schimanski wrote:
>>
>>> 
>>> Crash with Pixmap Cache and special unicode characters.
>>>
>> Fixed. See patch attached to the bug report.
>>>
>>
>> Thanks, thanks, and  thanks again! Very impressive !!!
>
>
And from me too!

Bennett

Re: rc3 (round one)

[Bennett Helm]

On Mon, Oct 6, 2008 at 9:59 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]>wrote:

> Let's trying something I had in mind to avoid using --without-x. Wih
> this patch, the code to configure X is only run when pkg-config has not
> been successful.
>
> With this patch, you should be able to omit --without-x. Could you try
> it out? Enrico, can you also try it on your 'exotic' platforms?


Konrad asked me to try it. The original nox.diff works for me. (I didn't try
nox-2.diff.)

Bennett

Re: os_unix.cpp: fix obvious typo

[Bennett Helm]

On Sun, Oct 5, 2008 at 2:11 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
> > Here's a patch to fix an obvious recent typo in os_unix.cpp. Can someone
> > please apply?
>
> its in.


Thanks.

Bennett

os_unix.cpp: fix obvious typo

[Bennett Helm]

Here's a patch to fix an obvious recent typo in os_unix.cpp. Can someone
please apply?

Thanks.

Bennett


Index: src/support/os_unix.cpp
===
--- src/support/os_unix.cpp (revision 26748)
+++ src/support/os_unix.cpp (working copy)
@@ -39,7 +39,7 @@
 bool isFilesystemCaseSensitive()
 {
 #ifdef __APPLE__
- return false:
+ return false;
 #else
  return true;
 #endif


typo.diff
Description: Binary data

Re: Tab key bindings, completion

[Bennett Helm]

On Wed, Sep 24, 2008 at 2:46 PM, Stefan Schimanski <[EMAIL PROTECTED]> wrote:

> now the questions:
>> 1. complete was replaced by complete-accept.
>>  (complete is trying to complete in the way bash do after tab -
>>  find the longest common prefix from the current on.)
>>  is there some disagreement with it?
>>
>
> Fine with me if it feels more intuitive, especially now with multiple
> bindings.
>
>  in case of no:
>> 2. complete lfun has no binding, should we bind it (and where)?
>>
>
> Good luck to find a good key. I guess nearly every other combination of
> modifiers and tab is somehow used by the OS. On Mac alt-tab would be ok. But
> on Windows it's taken.


Actually, mac.bind has  bound to buffer-next (and
 bound to buffer-previous).

Bennett

Re: Multiple Key Bindings

[Bennett Helm]

On Tue, Sep 23, 2008 at 9:00 PM, Bo Peng <[EMAIL PROTECTED]> wrote:

> I can have a look at the code at the end of this week if needed.


Bo - while you're at it, can you have a look at:

http://bugzilla.lyx.org/show_bug.cgi?id=4544

Thanks. (Sorry to hijack the thread)

Bennett

Re: question 4 of x - help to update the docs for 1.6.0

[Bennett Helm]

On Tue, Sep 23, 2008 at 6:25 PM, Uwe Stöhr <[EMAIL PROTECTED]> wrote:

> In the preferences there is under Look & Feel the option "Open documents in
> tabs". But when I uncheck it and restart LyX, the docs are still opened in
> tabs. What is this option supposed to be?


See bug 4906:

http://bugzilla.lyx.org/show_bug.cgi?id=4906

Bennett

Re: Preparing for rc3

[Bennett Helm]

On Wed, Sep 17, 2008 at 5:29 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
> > A couple quick and easy changes for mac.bind and the lyxeditor script in
> the
> > Mac bundle should go in (attached). (Note that g is the Mac default
> for
> > "search again".)
>
> its in.


Thanks!

Bennett

Re: Preparing for rc3

[Bennett Helm]

On Wed, Sep 17, 2008 at 11:36 AM, José Matos <[EMAIL PROTECTED]> wrote:

> We are approaching now of the time to have a new release. I am satisfied
> with
> a 3/4 weeks period between releases as the testing by users that usually
> just
> take a released version is not too far from the trunk head.
>
> Asking a user to test if a problem remains one or two weeks later on the
> new
> release is reasonable and we are getting good feedback. :-)
>
> What would you like to see in before rc3 is out?


A couple quick and easy changes for mac.bind and the lyxeditor script in the
Mac bundle should go in (attached). (Note that g is the Mac default for
"search again".)

Bennett


mac-updates.diff
Description: Binary data

Re: Newer Gettext for 1.5.x

[Bennett Helm]

On Sat, Aug 30, 2008 at 9:29 AM, Jürgen Spitzmüller <
[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
> > I've put a copy of the package here:
> >
> > LyX-1.5.6-2-Mac-Univ..><
> http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.5.6-2
> >-Mac-Universal.dmg>
> >
> > Could someone upload it to the correct server (and let me know if I need
> to
> > change the download links)?
>
> I've uploaded it and changed the link on the download page.


Thanks!

Bennett

Re: Math manuals uncompilable under rc2

[Bennett Helm]

On Fri, Aug 29, 2008 at 8:48 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:

> Uwe Stöhr wrote:
> > > % used in Kap. 22.4
> > > \usepackage{braket}
> >
> > Sorry, these two lines were leftovers from an older version. I fixed this
> > now.
> >
> > I can compile the math manual without problems and also our French and
> > Spanish translators working on Linux and BSD.
>
> lot of iconv errors remain, however i'm now at least able to compile the
> manual,
> with some err messages on console:


On Mac, however, I still get the same crash when attempting to open the math
manual. Shall I open a bug report?

Bennett

Re: Math manuals uncompilable under rc2

[Bennett Helm]

On Fri, Aug 29, 2008 at 8:58 AM, Vincent van Ravesteijn - TNW <
[EMAIL PROTECTED]> wrote:

> I have basically no problems compiling the Math-manual, until I tried a
> machine without the braket package. I think we could remove the first
> two (quite German sounding) lines below from the preamble.
>
> % used in Kap. 22.4
> \usepackage{braket}
> ...
> % needed in sec. 22.4
> % check for package braket
> \newboolean{braket}
> \IfFileExists{braket.sty}
>  {\usepackage{braket}
>  \setboolean{braket}{true}}
>  {\setboolean{braket}{false}}


I have braket.sty, but I can't even load the math manual: I get a crash.
Here's the backtrace:

Error 92 returned from iconv when converting from UCS-4LE to ISO-8859-15:
Illegal byte sequence
Converted input: 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x005c 0x0061 0x0061 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e
0x0064 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a
0x000a 0x005c 0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065
0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078
0x0074 0x0072 0x006d 0x007b
Stopped at: 0x212b
Unconverted input: 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x0131 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x00f8 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x00d8 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x0142 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x0141 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x0021 0x0060 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064
0x007b 0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a
0x005c 0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076
0x0069 0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074
0x0072 0x006d 0x007b 0x003f 0x0060 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e
0x0064 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a
0x000a 0x005c 0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065
0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078
0x0074 0x0072 0x006d 0x007b 0x0237 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e
0x0064 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a
0x000a 0x005c 0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065
0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078
0x0074 0x0072 0x006d 0x007b 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072 0x006d
0x007b 0x00c5 0x007d 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b
0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c
0x0062 0x0065 0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x0024 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072
0x006d 0x007b 0x005c 0x0074 0x0065 0x0078 0x0074 0x0072 0x006d 0x007b 0x00d8
0x007d 0x007d 0x0024 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b 0x0070 0x0072
0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x000a 0x000a 0x005c 0x0062 0x0065
0x0067 0x0069 0x006e 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077
0x007d 0x000a 0x0024 0x005c 0x0072 0x0061 0x0069 0x0073 0x0065 0x0062 0x006f
0x0078 0x007b 0x0034 0x002e 0x0035 0x006d 0x006d 0x007d 0x007b 0x007d 0x0024
0x000a 0x005c 0x0065 0x006e 0x0064 0x007b 0x0070 0x0072 0x0065 0x0076 0x0069
0x0065 0x0077 0x007d 0x000a 0x000a 0x005c 0x0062 0x0065 0x0067 0x0069 0x006e
0x007b 0x0070 0x0072 0x0065 0x0076 0x0069 0x0065 0x0077 0x007d 0x00

Re: LyX version 1.6.0 (release candidate 2) is released

[Bennett Helm]

On Fri, Aug 29, 2008 at 5:28 AM, José Matos <[EMAIL PROTECTED]> wrote:

> Public release of LyX version 1.6.0 (release candidate 2)
> =
>
> We are pleased to announce the second release candidate of LyX 1.6.0.


I've put the Mac universal binary here:

LyX-1.6.0RC2-Mac-Uni..>

Could someone please upload it?

Also, I recently posted a new version of 1.5.6 for Mac; could someone please
upload that as well? Here's the link for that again:

LyX-1.5.6-2-Mac-Univ..>

Thanks!

Bennett

Re: 1.6svn: Crash on quit after changing preferences

[Bennett Helm]

Sorry for the incomplete message; let's try this again.

On Wed, Aug 27, 2008 at 2:54 PM, Bennett Helm <[EMAIL PROTECTED]> wrote:

> On Mac, anytime I make a change to LyX's preferences, I get a new "special"
> menu appearing. Sometimes (and I'm not sure exactly under what conditions)
> this leads to a crash while editing a document. But it *always* leads to a
> crash if I try to quit. Here'
>

... Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0062
lyx::to_utf8 ([EMAIL PROTECTED]) at docstring.cpp:106
106 vector const utf8 = ucs4_to_utf8(ucs4.data(), ucs4.size());
(gdb) bt
#0  lyx::to_utf8 ([EMAIL PROTECTED]) at docstring.cpp:106
#1  0x0012c4d0 in lyx::LyXFunc::dispatch (this=0x142d0b0, [EMAIL PROTECTED]) at
LyXFunc.cpp:713
#2  0x0010e46e in lyx::dispatch ([EMAIL PROTECTED]) at LyX.cpp:1132
#3  0x0035c634 in lyx::frontend::Action::qt_metacall (this=0xf25f390,
_c=QMetaObject::InvokeMetaMethod, _id=-1, _a=0xbfffe278) at Action.cpp:69
#4  0x00b8012d in QMetaObject::activate () at LyX.cpp:1250
#5  0x005b03bc in QAction::triggered () at LyX.cpp:1250
#6  0x005b21cf in QAction::activate () at LyX.cpp:1250
#7  0x0096e739 in qt_mac_activate_action () at LyX.cpp:1250
#8  0x0096ed15 in qt_mac_menu_event () at LyX.cpp:1250
#9  0x90946763 in DispatchEventToHandlers ()
#10 0x90945b9d in SendEventToEventTargetInternal ()
#11 0x909624ee in SendEventToEventTarget ()
#12 0x90996bc1 in SendHICommandEvent ()
#13 0x909bd3d3 in SendMenuCommandWithContextAndModifiers ()
#14 0x909bd390 in SendMenuItemSelectedEvent ()
#15 0x90a4131f in HIMenuBar::HandleKeyboardEvent ()
#16 0x90946c71 in HIObject::EventHook ()
#17 0x90946763 in DispatchEventToHandlers ()
#18 0x90945b9d in SendEventToEventTargetInternal ()
#19 0x90945a02 in SendEventToEventTargetWithOptions ()
#20 0x90974def in ToolboxEventDispatcherHandler ()
#21 0x90946b1c in DispatchEventToHandlers ()
#22 0x90945b9d in SendEventToEventTargetInternal ()
#23 0x909624ee in SendEventToEventTarget ()
#24 0x00600881 in qt_mac_send_event () at LyX.cpp:1250
#25 0x0060cdb2 in QEventDispatcherMac::processEvents () at LyX.cpp:1250
#26 0x00b6e221 in QEventLoop::processEvents () at LyX.cpp:1250
#27 0x00b6e34a in QEventLoop::exec () at LyX.cpp:1250
#28 0x00b71041 in QCoreApplication::exec () at LyX.cpp:1250
#29 0x00119479 in lyx::LyX::exec (this=0xb258, [EMAIL PROTECTED],
argv=0xb2a0) at LyX.cpp:343
#30 0x2989 in main (argc=1, argv=0xb2a0) at main.cpp:46


Bennett

1.6svn: Crash on quit after changing preferences

[Bennett Helm]

On Mac, anytime I make a change to LyX's preferences, I get a new "special"
menu appearing. Sometimes (and I'm not sure exactly under what conditions)
this leads to a crash while editing a document. But it *always* leads to a
crash if I try to quit. Here'

Re: [Fwd: Re: Newer Gettext for 1.5.x]

[Bennett Helm]

On Mon, Aug 18, 2008 at 5:07 AM, Konrad Hofbauer <[EMAIL PROTECTED]>wrote:

> I am wondering where it came from that 1.5.6 did not pick up the OS
> language anymore.
>
> Question:
> When you built that version, did you patch the official source (i.e.
> removed the -I .../CoreFoundation) that came in through gettext? That would
> maybe explain it (through it being only a partial fix).


Nope -- a standard build, as usual, using the script we came up with.
(Frankly, I don't know enough to even try patching anything like this, so I
don't even try.)

Bennett

Re: [Fwd: Re: Newer Gettext for 1.5.x]

[Bennett Helm]

On Fri, Aug 15, 2008 at 12:10 PM, Jean-Marc Lasgouttes
<[EMAIL PROTECTED]>wrote:

> Le 15 août 08 à 18:00, Konrad Hofbauer a écrit :
>
>  Jean-Marc Lasgouttes wrote:
>>
>>> Of course, the autoconf and automake versions will not match the original
>>> release,
>>> but I assume it will not matter.
>>>
>>
>> This was exactly my concern (plus whatever other system libraries might
>> matter).
>>
>> JMarc, can I just use the official 1.5.6 tarball, apply the patch you
>> initially posted here, re-run autogen.sh, and that's it?
>>
>
> Yes.


Konrad -

Thanks for taking over here. I'm back (sort of -- still too busy!) and happy
for you to keep doing what you're doing. Let me know if you want me to test
anything.

Bennett

Re: Preparing for rc1

[Bennett Helm]

On Fri, Aug 1, 2008 at 2:39 PM, José Matos <[EMAIL PROTECTED]> wrote:

>I would like to release a first candidate to rc1 next Monday, this
> follows
> our agreed schedule where RC1 was planned for today. If all goes well I
> would
> like to release on Tuesday or Wednesday.


I won't be able to do anything for the next couple of weeks. Perhaps Konrad
or Anders could produce the binary for Mac and package it up.

In case someone can, I've put 2 files on my server to help:

LyX-1.6.x-Mac.sparse..>
ReadMe-160b4.lyx 

The first is a zipped sparseimage template for the LyX/Mac binary package.
Simply unzip, open it, and copy over the compiled binary. You should also
take the second file -- the readme file used for 1.6.0b4 -- and update it
for rc1 and put the resulting .pdf into the sparseimage volume. Then, using
Disk Utility, convert the sparseimage to a *compressed* .dmg, naming it
LyX-1.6.0rc1-Mac-Universal.dmg.

Bennett

Re: Crash on Launch with Sessions

[Bennett Helm]

On Fri, Aug 1, 2008 at 12:02 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> I have LyX-1.6svn set to open files from the last session, and currently
>> it
>> is set to open 3 files. There are a number of bugs with the way this
>> works,
>> as I have reported in the past. One bug is that although I last quit LyX
>> with these files open in separate windows, on relaunch, LyX opens them in
>> one window with tabs. (On Mac this is a problem because in 1.6
>> does not work to switch among these tabs; this is a regression from 1.5.)
>> Another bug is that LyX now opens them with the source view and outline
>> view
>> visible, which it should not (given that they were not visible when LyX
>> was
>> last quit.) I mention these problems because it seems they may be relevant
>> to the current crash I'm getting.
>>
>
> Yeah, sorry. Those bugs are in my todo list but they require a lot of
> debugging time. So for now I prefer to concentrate on easy to fix and major
> bugs. Maybe I should not have introduce this multiwindow and session thing
> after all ;-)


No need to apologize! No sane person should be using 1.6 yet anyway. And
multiwindow LyX makes it feel like a *real* (=Mac) application, so that's
got to be good! (It is Friday, isn't it? Can I start an OS holy war?)

Currently, with these 3 files set to open in the sessions file, LyX crashes
>> on launch soon after displaying the document window. If I delete the
>> sessions file, LyX launches with no problem, and I am able to open these 3
>> files individually. When I quit (with these files open) and relaunch, I
>> again get the crash.
>>
>> Here's the backtrace.
>>
>>
> It does reveal anything I'm afraid.


So can I do anything more to help track it down? (It had better be quick,
though: I'll be out of contact for a couple weeks starting tomorrow)

Bennett

Crash on Launch with Sessions

[Bennett Helm]

I have LyX-1.6svn set to open files from the last session, and currently it
is set to open 3 files. There are a number of bugs with the way this works,
as I have reported in the past. One bug is that although I last quit LyX
with these files open in separate windows, on relaunch, LyX opens them in
one window with tabs. (On Mac this is a problem because in 1.6 
does not work to switch among these tabs; this is a regression from 1.5.)
Another bug is that LyX now opens them with the source view and outline view
visible, which it should not (given that they were not visible when LyX was
last quit.) I mention these problems because it seems they may be relevant
to the current crash I'm getting.

Currently, with these 3 files set to open in the sessions file, LyX crashes
on launch soon after displaying the document window. If I delete the
sessions file, LyX launches with no problem, and I am able to open these 3
files individually. When I quit (with these files open) and relaunch, I
again get the crash.

Here's the backtrace.

Bennett



Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x72894000
0x96eb8c4f in CUIRenderer::DrawSlider ()
(gdb)
(gdb) bt
#0  0x96eb8c4f in CUIRenderer::DrawSlider ()
#1  0x96ec3f0a in CUIRenderer::Draw ()
#2  0x92b11c3e in _HIThemeDrawTrackTickMarksInternal ()
#3  0x92b11eb0 in HIThemeDrawTrackTickMarks ()
#4  0x00832b4d in QMacStyle::drawComplexControl () at ext/new_allocator.h:94
#5  0x00931649 in QSlider::paintEvent () at ext/new_allocator.h:94
#6  0x005f267f in QWidget::event () at ext/new_allocator.h:94
#7  0x008a7498 in QAbstractSlider::event () at ext/new_allocator.h:94
#8  0x009315a1 in QSlider::event () at ext/new_allocator.h:94
#9  0x005b396f in QApplicationPrivate::notify_helper () at
ext/new_allocator.h:94
#10 0x005b9c1c in QApplication::notify () at ext/new_allocator.h:94
#11 0x00371671 in lyx::frontend::GuiApplication::notify (this=0x202d1d0,
receiver=0x41e8, event=0x41e8) at GuiApplication.cpp:1185
#12 0x00b6bf34 in QCoreApplication::notifyInternal () at
ext/new_allocator.h:94
#13 0x0061b35d in QWidgetPrivate::qt_widget_event () at
ext/new_allocator.h:94
#14 0x92974763 in DispatchEventToHandlers ()
#15 0x92973b9d in SendEventToEventTargetInternal ()
#16 0x92973a02 in SendEventToEventTargetWithOptions ()
#17 0x92997421 in HIView::SendDraw ()
#18 0x92996f0e in HIView::RecursiveDrawComposited ()
#19 0x92997072 in HIView::RecursiveDrawComposited ()
#20 0x92997072 in HIView::RecursiveDrawComposited ()
#21 0x92997072 in HIView::RecursiveDrawComposited ()
#22 0x92997072 in HIView::RecursiveDrawComposited ()
#23 0x9299630c in HIView::DrawComposited ()
#24 0x9299601f in HIView::Draw ()
#25 0x92995f6f in HIView::Render ()
#26 0x9299e867 in FlushWindowObject ()
#27 0x9299e27e in FlushAllBuffers ()
#28 0x90fd59c2 in __CFRunLoopDoObservers ()
#29 0x90fd6bf2 in CFRunLoopRunSpecific ()
#30 0x90fd7cf8 in CFRunLoopRunInMode ()
#31 0x9299cda4 in RunCurrentEventLoopInMode ()
#32 0x9299caf6 in ReceiveNextEventCommon ()
#33 0x92adfaf3 in ReceiveNextEvent ()
#34 0x0060a0b4 in QEventDispatcherMac::processEvents () at
ext/new_allocator.h:94
#35 0x00b6b641 in QEventLoop::processEvents () at ext/new_allocator.h:94
#36 0x00b6b76a in QEventLoop::exec () at ext/new_allocator.h:94
#37 0x00b6e461 in QCoreApplication::exec () at ext/new_allocator.h:94
#38 0x001197e9 in lyx::LyX::exec (this=0xb258, [EMAIL PROTECTED],
argv=0xb2a0) at LyX.cpp:343
#39 0x3069 in main (argc=1, argv=0xb2a0) at main.cpp:46

Re: File->Open... dialogue on Mac

[Bennett Helm]

On Wed, Jul 30, 2008 at 9:49 AM, Anders Ekberg <[EMAIL PROTECTED]> wrote:

> In the current trunk on Mac (OS X 10.5) the File->Open...  dialogue has in
> the Enable-pop-up menu first the entry LyX Documents and then three x
> Documents entries. Is this intentional as placeholders or a bug?


Looks like a bug to me. Perhaps you should file it in bugzilla so that it's
not forgotten.

Bennett

Re: "Could not move temporary file" error (FileName.cpp)

[Bennett Helm]

On Wed, Jul 30, 2008 at 3:35 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Tue, Jul 29, 2008 at 4:47 PM, Richard Heck<[EMAIL PROTECTED]>  wrote
>>
>>
>>> I think it may have something to do with empty FileName objects behaving
>>> badly. Try the attached, just as a wild guess.
>>>
>>
> I verified that comparing two empty QFileInfo returned false so your guess
> was right nevertheless.
>
>   If that doesn't work, we'll
>>> try something else.
>>>
>>>
>>
>>
>> No go. Here's the new backtrace.
>>
>>
>
> This doesn't seem to be related... Or the backtrace is truncated. Could you
> please revert Richard's patch and svn up again?


Reverting and updating seems to fix the problem -- thanks.

Bennett

Re: "Could not move temporary file" error (FileName.cpp)

[Bennett Helm]

On Tue, Jul 29, 2008 at 4:47 PM, Richard Heck <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Tue, Jul 29, 2008 at 3:22 PM, Richard Heck <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Bennett Helm wrote:
>>>
>>>
>>>
>>>> I can see I'm too late to respond. I did just update svn, and now LyX
>>>> crashes on launch. Does this have something to do with this commit?
>>>>
>>>>  Hard to know. Can you see if reverting to 25987 or 25988 fixes it? If
>>>>
>>>>
>>> so
>>>
>>>
>>
>>
>> 25987 is fine.  25988 crashes. I blame Abdel (for the second time today!).
>> I
>> just hope he doesn't start spamming me ;)
>>
>>
>>
> Actually, that was Abdel's implementation of an idea of mine, so I'm at
> least half at fault.



>
>
> I think it may have something to do with empty FileName objects behaving
> badly. Try the attached, just as a wild guess. If that doesn't work, we'll
> try something else.


No go. Here's the new backtrace.

Bennett

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x57a8c000
0x96eb8c4f in CUIRenderer::DrawSlider ()
(gdb) bt
#0  0x96eb8c4f in CUIRenderer::DrawSlider ()
#1  0x96ec3f0a in CUIRenderer::Draw ()
#2  0x92b11c3e in _HIThemeDrawTrackTickMarksInternal ()
#3  0x92b11eb0 in HIThemeDrawTrackTickMarks ()
#4  0x00831c2d in QMacStyle::drawComplexControl ()
#5  0x00930729 in QSlider::paintEvent ()
#6  0x005f175f in QWidget::event ()
#7  0x008a6578 in QAbstractSlider::event ()
#8  0x00930681 in QSlider::event ()
#9  0x005b2a4f in QApplicationPrivate::notify_helper ()
#10 0x005b8cfc in QApplication::notify ()
#11 0x00370791 in lyx::frontend::GuiApplication::notify (this=0x142d140,
receiver=0x41e8, event=0x41e8) at GuiApplication.cpp:1185
#12 0x00b6b014 in QCoreApplication::notifyInternal () at qatomic_i386.h:134
#13 0x0061a43d in QWidgetPrivate::qt_widget_event () at crc.hpp:531
#14 0x92974763 in DispatchEventToHandlers ()
#15 0x92973b9d in SendEventToEventTargetInternal ()
#16 0x92973a02 in SendEventToEventTargetWithOptions ()
#17 0x92997421 in HIView::SendDraw ()
#18 0x92996f0e in HIView::RecursiveDrawComposited ()
#19 0x92997072 in HIView::RecursiveDrawComposited ()
#20 0x92997072 in HIView::RecursiveDrawComposited ()
#21 0x92997072 in HIView::RecursiveDrawComposited ()
#22 0x92997072 in HIView::RecursiveDrawComposited ()
#23 0x9299630c in HIView::DrawComposited ()
#24 0x9299601f in HIView::Draw ()
#25 0x92995f6f in HIView::Render ()
#26 0x9299e867 in FlushWindowObject ()
#27 0x9299e27e in FlushAllBuffers ()
#28 0x90fd59c2 in __CFRunLoopDoObservers ()
#29 0x90fd6bf2 in CFRunLoopRunSpecific ()
#30 0x90fd7cf8 in CFRunLoopRunInMode ()
#31 0x9299cda4 in RunCurrentEventLoopInMode ()
#32 0x9299caf6 in ReceiveNextEventCommon ()
#33 0x92adfaf3 in ReceiveNextEvent ()
#34 0x00609194 in QEventDispatcherMac::processEvents () at crc.hpp:531
#35 0x00b6a721 in QEventLoop::processEvents () at qatomic_i386.h:134
#36 0x00b6a84a in QEventLoop::exec () at qatomic_i386.h:134
#37 0x00b6d541 in QCoreApplication::exec () at qatomic_i386.h:134
#38 0x00119069 in lyx::LyX::exec (this=0xb258, [EMAIL PROTECTED],
argv=0xb2a0) at LyX.cpp:343
#39 0x2929 in main (argc=1, argv=0xb2a0) at main.cpp:46

Re: "Could not move temporary file" error (FileName.cpp)

[Bennett Helm]

On Tue, Jul 29, 2008 at 3:22 PM, Richard Heck <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> I can see I'm too late to respond. I did just update svn, and now LyX
>> crashes on launch. Does this have something to do with this commit?
>>
>>  Hard to know. Can you see if reverting to 25987 or 25988 fixes it? If
> so


25987 is fine.  25988 crashes. I blame Abdel (for the second time today!). I
just hope he doesn't start spamming me ;)

Bennett

Re: "Could not move temporary file" error (FileName.cpp)

[Bennett Helm]

On Tue, Jul 29, 2008 at 2:16 PM, Richard Heck <[EMAIL PROTECTED]> wrote:

> Abdelrazak Younes wrote:
>
>> Richard Heck wrote:
>>
>>> I saw the same problem Bennett did, by the way, on Linux. It occurred to
>>> me that it might be another manifestation of the refresh() issue. So I did
>>> the attached, and it works for me. Bennett?
>>>
>>
>> Aha... well spotted. But this is not due to the refresh bug as Windows was
>> also affected. It simply means that those temporary files being moved all
>> other the place needed a refresh.
>>
>>  OK. I've committed that. I wonder if there are other times we need to
> refresh


I can see I'm too late to respond. I did just update svn, and now LyX
crashes on launch. Does this have something to do with this commit?

Here's the complete output from gdb:

dvipng warning: at (1,0) ignored header \special{! /DvipsToPDF { 72.27 mul
Resolution div } def /PDFToDvips { 72.27 div Resolution mul } def
/HyperBorder { 1 PDFToDvips } def /H.V [EMAIL PROTECTED] [EMAIL PROTECTED] 
null} def /H.B
{/[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] def 
/H.S { currentpoint HyperBorder
add /[EMAIL PROTECTED] exch def dup DvipsToPDF /[EMAIL PROTECTED] exch def 
HyperBorder sub
/[EMAIL PROTECTED] exch def } def /H.L { 2 sub dup /HyperBasePt exch def 
PDFToDvips
/HyperBaseDvips exch def currentpoint HyperBaseDvips sub /[EMAIL PROTECTED] 
exch def
/[EMAIL PROTECTED] exch def } def /H.A { H.L currentpoint exch pop vsize 72 sub 
exch
DvipsToPDF HyperBasePt sub sub /[EMAIL PROTECTED] exch def } def /H.R { 
currentpoint
HyperBorder sub /[EMAIL PROTECTED] exch def HyperBorder add /[EMAIL PROTECTED] 
exch def
currentpoint exch pop vsize 72 sub exch DvipsToPDF sub /[EMAIL PROTECTED] exch 
def }
def systemdict /pdfmark known { userdict /?pdfmark systemdict /exec get put
}{ userdict /?pdfmark systemdict /pop get put userdict /pdfmark systemdict
/cleartomark get put } ifelse } dvipng warning: at (1,0) unimplemented
\special{ps:SDict begin /product where{pop product(Distiller)search{pop pop
pop version(.)search{exch pop exch pop(3011)eq{gsave newpath 0 0 moveto
closepath clip/Courier findfont 10 scalefont setfont 72 72 moveto(.)show
grestore}if}{pop}ifelse}{pop}ifelse}if end} dvipng warning: at (1,0)
unimplemented \special{ps:SDict begin [ /Producer (dvips + Distiller) /Title
() /Subject () /Creator (LaTeX with hyperref package) /Author () /Keywords
() /DOCINFO pdfmark end} dvipng warning: at (1,-1) unimplemented
\special{ps:SDict begin /product where{pop product(Distiller)search{pop pop
pop version(.)search{exch pop exch pop(3011)eq{gsave newpath 0 0 moveto
closepath clip/Courier findfont 10 scalefont setfont 72 72 moveto(.)show
grestore}if}{pop}ifelse}{pop}ifelse}if end} dvipng warning: at (0,-1)
unimplemented \special{ps:SDict begin /product where{pop
product(Distiller)search{pop pop pop version(.)search{exch pop exch
pop(3011)eq{gsave newpath 0 0 moveto closepath clip/Courier findfont 10
scalefont setfont 72 72 moveto(.)show grestore}if}{pop}ifelse}{pop}ifelse}if
end} dvipng warning: at (1,-1) unimplemented \special{ps:SDict begin
/product where{pop product(Distiller)search{pop pop pop
version(.)search{exch pop exch pop(3011)eq{gsave newpath 0 0 moveto
closepath clip/Courier findfont 10 scalefont setfont 72 72 moveto(.)show
grestore}if}{pop}ifelse}{pop}ifelse}if end} Assertion triggered in T*
boost::shared_ptr::operator->() const [with T = lyx::graphics::CacheItem]
by failing check "px != 0" in file ../boost/boost/shared_ptr.hpp:315

Program received signal SIGABRT, Aborted.
0x92ce4b9e in __kill ()
(gdb) dvipng warning: at (-1,0) ignored header \special{! /DvipsToPDF {
72.27 mul Resolution div } def /PDFToDvips { 72.27 div Resolution mul } def
/HyperBorder { 1 PDFToDvips } def /H.V [EMAIL PROTECTED] [EMAIL PROTECTED] 
null} def /H.B
{/[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] def 
/H.S { currentpoint HyperBorder
add /[EMAIL PROTECTED] exch def dup DvipsToPDF /[EMAIL PROTECTED] exch def 
HyperBorder sub
/[EMAIL PROTECTED] exch def } def /H.L { 2 sub dup /HyperBasePt exch def 
PDFToDvips
/HyperBaseDvips exch def currentpoint HyperBaseDvips sub /[EMAIL PROTECTED] 
exch def
/[EMAIL PROTECTED] exch def } def /H.A { H.L currentpoint exch pop vsize 72 sub 
exch
DvipsToPDF HyperBasePt sub sub /[EMAIL PROTECTED] exch def } def /H.R { 
currentpoint
HyperBorder sub /[EMAIL PROTECTED] exch def HyperBorder add /[EMAIL PROTECTED] 
exch def
currentpoint exch pop vsize 72 sub exch DvipsToPDF sub /[EMAIL PROTECTED] exch 
def }
def systemdict /pdfmark known { userdict /?pdfmark systemdict /exec get put
}{ userdict /?pdfmark systemdict /pop get put userdict /pdfmark systemdict
/cleartomark get put } ifelse } dvipng warning: at (-1,0) unimplemented
\special{ps:SDict begin /product where{pop product(Distiller)search{pop pop
pop version(.)search{exch pop exch pop(3011)eq{gsave newpath 0 0 moveto
closepath clip/Courier findfont 10 scalefont setfont 72 72 moveto(.)show

Re: "Could not move temporary file" error (FileName.cpp)

[Bennett Helm]

On Tue, Jul 29, 2008 at 10:33 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> OK, fixed.
>

Works for me -- thanks!

Bennett

"Could not move temporary file" error (FileName.cpp)

[Bennett Helm]

The first time I typeset a file, everything works. If I subsequently modify
the document and then typeset again, I get an error:

Could not copy a temporary file from
/Users/bennett/tmp/lyx_tmpdir.J82124/lyx_tmpbuf3/test.pdf to
/Users/bennett/tmp/lyx_tmpdir.J82124/lyx_tmpbuf3/test.pdf.

The terminal shows:

FileName.cpp(204): FileName::copyTo(): Could not copy file
/Users/bennett/tmp/lyx_tmpdir.J82124/lyx_tmpbuf3/test.pdf to
/Users/bennett/tmp/lyx_tmpdir.J82124/lyx_tmpbuf3/test.pdf
Error: Cannot convert file

Could this be a problem with r25960? (It didn't happen yesterday.)

Bennett

Wiki password

[Bennett Helm]

Has the password for editing the wiki changed since 1.5.5? The one I've been
using doesn't seem to work currently.
Could someone send me the current password?

Thanks.

Bennett

Re: [ANNOUNCE] LyX 1.5.6 is released

[Bennett Helm]

On Mon, Jul 28, 2008 at 9:02 AM, Bennett Helm <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 28, 2008 at 2:22 AM, Jürgen Spitzmüller <
> [EMAIL PROTECTED]> wrote:
>
>> Public release of LyX version 1.5.6
>> 
>>
>> We are pleased to announce the release of LyX 1.5.6. This is the fifth
>> maintenance release in the 1.5.x cycle that has been started exactly
>> one year ago. The aim of this release was to make LyX even more robust
>> and to solve some long-standing annoyances. Also, further translation
>> efforts have been made, and LyX now ships in 23 languages.
>
>
> I've put a Mac binary here:
>
> LyX-1.5.x-Mac-Univer..><http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.5.x-Mac-Universal.dmg>
>
> It's been tested on 1 Intel Mac (10.5) and 1 PPC Mac (10.4), though it
> likely will be problematic for the same people who had troubles before.
>
> Please upload it to the server.
>

Oops -- I just noticed that I failed to rename it properly -- should be
LyX-1.5.6-Mac-Universal.dmg (with a "6" instead of the "x"). I've renamed it
on my server, so the location is now:

LyX-1.5.6-Mac-Univer..><http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.5.6-Mac-Universal.dmg>

(If you've already grabbed it, simply rename it yourself -- no need to
download again.)

Thanks ... and sorry for the hassle.

Bennett

Re: [ANNOUNCE] LyX 1.5.6 is released

[Bennett Helm]

On Mon, Jul 28, 2008 at 2:22 AM, Jürgen Spitzmüller <
[EMAIL PROTECTED]> wrote:

> Public release of LyX version 1.5.6
> 
>
> We are pleased to announce the release of LyX 1.5.6. This is the fifth
> maintenance release in the 1.5.x cycle that has been started exactly
> one year ago. The aim of this release was to make LyX even more robust
> and to solve some long-standing annoyances. Also, further translation
> efforts have been made, and LyX now ships in 23 languages.


I've put a Mac binary here:

LyX-1.5.x-Mac-Univer..>

It's been tested on 1 Intel Mac (10.5) and 1 PPC Mac (10.4), though it
likely will be problematic for the same people who had troubles before.

Please upload it to the server.

Bennett

Re: tmpdir problem

[Bennett Helm]

On Thu, Jul 24, 2008 at 5:20 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> rgheck wrote:
>
>> Enrico Forestieri wrote:
>>
>>> With latest svn, LyX is not able to create the tmpdir:
>>>
>>> $ lyx
>>> ../../../src/support/filetools.cpp(328): LyX could not create temporary
>>> directory in /tmp'
>>>
>>> $ lyx -dbg files
>>> Setting debug level to files
>>> Debugging `files' (Files used by LyX)
>>> ../../../src/support/filetools.cpp(322): createTmpDir: tempdir=`/tmp'
>>> createTmpDir:mask=`lyx_tmpdir'
>>> ../../../src/support/FileName.cpp(375): Unable to create temporary file
>>> with following template: /lyx_tmpdir
>>> ../../../src/support/filetools.cpp(328): LyX could not create temporary
>>> directory in /tmp'
>>>
>>> Abdel, I see that you recently touched that.
>>>
>>>  I'm not seeing any problem on Linux. But mine looks like this:
>>
>> Debugging `files' (Files used by LyX)
>> filetools.cpp(322): createTmpDir: tempdir=`/tmp/'
>> createTmpDir: mask=`lyx_tmpdir'
>> FileName.cpp(371): Temporary file `/tmp/lyx_tmpdir.J21987' created.
>>
>> Note the trailing slash: /tmp/. Also, the template is wrong. It should be:
>> /tmp/lyx_tmpdir, not just /lyx_tmpdir.
>>
>> The problem is here:
>>
>> FileName FileName::tempName(FileName const & temp_dir, string const &
>> mask)
>> {
>> QFileInfo tmp_fi(temp_dir.d->fi.absoluteDir(), toqstr(mask));
>> return FileName(createTempFile(tmp_fi.absoluteFilePath()));
>> }
>>
>> tmp_fi.absoluteFilePath() is doing the wrong thing with "/tmp". It's
>> giving us the path to where /tmp is---viz, /---not the path to /tmp itself,
>> since the trailing slash is missing. Hence the /lyx_tmpdir, and the failure.
>>
>> Replacing absoluteDir() there with absoluteFilePath() may do the trick.
>>
>
> That's what I did yes.


It seems this fixes bug 5085 (at least I'm not seeing the problem there
anymore):

http://bugzilla.lyx.org/show_bug.cgi?id=5085

Could you take a look and close it if appropriate?

Thanks.

Bennett

Re: File ModTime Bug: Please Check Your Platforms!

[Bennett Helm]

On Tue, Jul 22, 2008 at 8:49 AM, Enrico Forestieri <[EMAIL PROTECTED]>
wrote:

> On Tue, Jul 22, 2008 at 08:21:15AM -0400, Bennett Helm wrote:
>
> > Thanks, Enrico; that's helping, but I now have problems linking.
>
> You need other options on the command line. Try locating in
> /Users/bennett/lyx/qt-4.4-install/lib a file named QtCore.prl or
> QtCore.pc. If you find QtCore.prl, look at the line
> QMAKE_PRL_LIBS = ...
> and append the ... options to your command.
> Otherwise, if you find QtCore.pc, look at the line
> Libs: ...
> and again append those ... options.
> If everything fails, use the same switches that are used for linking
> the lyx executable. However, I think that you must have at least
> the QtCore.prl file.


That fixes it. Running Richard's test, I get printout indicating
modification times everytime I touch /tmp/testfile. Running Enrico's test2,
I get nothing.

Bennett

Re: File ModTime Bug: Please Check Your Platforms!

[Bennett Helm]

On Tue, Jul 22, 2008 at 5:12 AM, Enrico Forestieri <[EMAIL PROTECTED]>
wrote:

> On Mon, Jul 21, 2008 at 03:15:09PM -0400, Bennett Helm wrote:
>
> > I'm not setting things up right. I run:
> >
> > g++ -o test test.cpp -Wall -I
> > /Users/bennett/lyx/qt-4.4-install/include/QtCore/ -L /usr/lib64 -lQtCore
> >
> > and get many instances of:
> >
> > In file included from
> > /Users/bennett/lyx/qt-4.4-install/include/QtCore/QDateTime:1,
> >  from test.cpp:1:
> > /Users/bennett/lyx/qt-4.4-install/include/QtCore/qdatetime.h:47:28:
> error:
> > QtCore/qstring.h: No such file or directory
> > /Users/bennett/lyx/qt-4.4-install/include/QtCore/qdatetime.h:48:31:
> error:
> > QtCore/qnamespace.h: No such file or directory
> >
> > (That is the right directory for QtCore.) I even tried setting QT4DIR
> > explicitly, but that didn't affect it.
> >
> > What am I doing wrong?
>
> Try:
>
> g++ -o test test.cpp -Wall -I/Users/bennett/lyx/qt-4.4-install/include \
> -I/Users/bennett/lyx/qt-4.4-install/include/QtCore -L/usr/lib64 -lQtCore
>
> and I suspect that you also have to replace -L/usr/lib64 by
> -L/Users/bennett/lyx/qt-4.4-install/lib


Thanks, Enrico; that's helping, but I now have problems linking.

Here's what I get:

08:17:52 | bennett:~/Downloads> g++ -o test2 test2.cpp -Wall
-I/Users/bennett/lyx/qt-4.4-install/include
-I/Users/bennett/lyx/qt-4.4-install/include/QtCore -L/usr/lib64 -lQtCoreld:
library not found for -lQtCore
collect2: ld returned 1 exit status

So then I try (as you suggested):

08:18:24 | bennett:~/Downloads> g++ -o test2 test2.cpp -Wall
-I/Users/bennett/lyx/qt-4.4-install/include
-I/Users/bennett/lyx/qt-4.4-install/include/QtCore
-L/Users/bennett/lyx/qt-4.4-install/lib -lQtCore
ld: warning QDebug::operator<<(char const*)has different visibility (1) in
/Users/bennett/lyx/qt-4.4-install/lib/libQtCore.a(qdatetime.o) and (2) in
/var/folders/VG/VG2LIQzQE74x-kW7xUGeWTI/-Tmp-//ccoKuHZL.o
ld: warning QString::QString()has different visibility (1) in
/Users/bennett/lyx/qt-4.4-install/lib/libQtCore.a(qvariant.o) and (2) in
/var/folders/VG/VG2LIQzQE74x-kW7xUGeWTI/-Tmp-//ccoKuHZL.o
ld: warning QByteArray::~QByteArray()has different visibility (1) in
/Users/bennett/lyx/qt-4.4-install/lib/libQtCore.a(qvariant.o) and (2) in
/var/folders/VG/VG2LIQzQE74x-kW7xUGeWTI/-Tmp-//ccoKuHZL.o
ld: warning QDebug::~QDebug()has different visibility (1) in
/Users/bennett/lyx/qt-4.4-install/lib/libQtCore.a(qvariant.o) and (2) in
/var/folders/VG/VG2LIQzQE74x-kW7xUGeWTI/-Tmp-//ccoKuHZL.o
Undefined symbols:
  "_CFBundleCreate", referenced from:
  QProcessPrivate::startProcess()   in libQtCore.a(qprocess_unix.o)
  "_kCFDateFormatterShortMonthSymbols", referenced from:
  _kCFDateFormatterShortMonthSymbols$non_lazy_ptr in
libQtCore.a(qlocale.o)
  "_CFStringCreateWithCharacters", referenced from:
  QCFString::toCFStringRef(QString const&) in libQtCore.a(qcore_mac.o)
  "_CFDataGetBytePtr", referenced from:
  qtValue(void const*)in libQtCore.a(qsettings_mac.o)
  "_kCFAllocatorDefault", referenced from:
  _kCFAllocatorDefault$non_lazy_ptr in libQtCore.a(qstring.o)
  _kCFAllocatorDefault$non_lazy_ptr in libQtCore.a(qlocale.o)
  _kCFAllocatorDefault$non_lazy_ptr in libQtCore.a(qsettings_mac.o)
  "_kCFTypeDictionaryKeyCallBacks", referenced from:
  _kCFTypeDictionaryKeyCallBacks$non_lazy_ptr in
libQtCore.a(qsettings_mac.o)
  "_CFStringCreateWithPascalString", referenced from:
  qt_mac_from_pascal_string(unsigned char const*)in
libQtCore.a(qglobal.o)
  "_CFNumberIsFloatType", referenced from:
  qtValue(void const*)in libQtCore.a(qsettings_mac.o)
  "_CFDateFormatterCreateStringWithDate", referenced from:
  QSystemLocale::query(QSystemLocale::QueryType, QVariant) constin
libQtCore.a(qlocale.o)
  QSystemLocale::query(QSystemLocale::QueryType, QVariant) constin
libQtCore.a(qlocale.o)
  "_CFBooleanGetTypeID", referenced from:
  qtValue(void const*)in libQtCore.a(qsettings_mac.o)
  "_kCFTypeArrayCallBacks", referenced from:
  _kCFTypeArrayCallBacks$non_lazy_ptr in libQtCore.a(qsettings_mac.o)
  "_CFDictionaryGetCount", referenced from:
  qtValue(void const*)in libQtCore.a(qsettings_mac.o)
  QConfFileSettingsPrivate::readPlistFile(QString const&,
QMap*) constin libQtCore.a(qsettings_mac.o)
  "_FSResolveAliasFile", referenced from:
  QFSFileEngine::fileName(QAbstractFileEngine::FileName) const   in
libQtCore.a(qfsfileengine_unix.o)
  "_CFDateFormatterCopyProperty", referenced from:
  QSystemLocale::query(QSystemLocale::QueryType, QVariant) constin
libQtCore.a(qlocale.o)
  QSystemLocale::query(QS

Re: File ModTime Bug: Please Check Your Platforms!

[Bennett Helm]

On Mon, Jul 21, 2008 at 4:44 PM, rgheck <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Mon, Jul 21, 2008 at 2:43 PM, rgheck <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>> This time with the attachment.
>>>
>>>  Does not work for me on Mac with Qt-4.4.0. (I only checked bibliography
>>>
>>>
>>>> updating.)
>>>>
>>>>  OK. The bug exists on Mac, too. See if you can verify that with the
>>>>
>>>>
>>> attached program. Compile via
>>>  g++ -o test test.cpp -Wall -I /usr/include/QtCore/ -L /usr/lib64
>>> -lQtCore
>>> adjusting for your library locations as necessary. You'll probably also
>>> need to adjust the file location from /cvs/testfile. Start the program,
>>> then run:
>>>  touch /tmp/testfile
>>>
>>> or whatever and see if you get any output.
>>>
>>>
>>>
>>
>> I don't think I have lib64 on my system, but I assume that doesn't matter
>> (right?).
>>
>> I'm not setting things up right. I run:
>>
>> g++ -o test test.cpp -Wall -I
>> /Users/bennett/lyx/qt-4.4-install/include/QtCore/ -L /usr/lib64 -lQtCore
>>
>> and get many instances of:
>>
>> In file included from
>> /Users/bennett/lyx/qt-4.4-install/include/QtCore/QDateTime:1,
>> from test.cpp:1:
>> /Users/bennett/lyx/qt-4.4-install/include/QtCore/qdatetime.h:47:28: error:
>> QtCore/qstring.h: No such file or directory
>> /Users/bennett/lyx/qt-4.4-install/include/QtCore/qdatetime.h:48:31: error:
>> QtCore/qnamespace.h: No such file or directory
>>
>> (That is the right directory for QtCore.) I even tried setting QT4DIR
>> explicitly, but that didn't affect it.
>>
>>
>>
> Maybe drop the QtCore bit. And you may need to set -L to /usr/lib, or
> whatever. Wherever libQt* lives.


I have Qt 4.4 installed at ~/lyx/qt-4.4-install/, and I point QTDIR and
QT4DIR there, I try setting explicitly the paths in the -I, -L, and -l
options, and I still can't get g++ to recognize these files' locations. I'm
lost.

Bennett

Re: File ModTime Bug: Please Check Your Platforms!

[Bennett Helm]

On Mon, Jul 21, 2008 at 2:43 PM, rgheck <[EMAIL PROTECTED]> wrote:

>
> This time with the attachment.
>
>  Does not work for me on Mac with Qt-4.4.0. (I only checked bibliography
>> updating.)
>>
>>  OK. The bug exists on Mac, too. See if you can verify that with the
> attached program. Compile via
>   g++ -o test test.cpp -Wall -I /usr/include/QtCore/ -L /usr/lib64
> -lQtCore
> adjusting for your library locations as necessary. You'll probably also
> need to adjust the file location from /cvs/testfile. Start the program,
> then run:
>   touch /tmp/testfile
>
> or whatever and see if you get any output.
>

I don't think I have lib64 on my system, but I assume that doesn't matter
(right?).

I'm not setting things up right. I run:

g++ -o test test.cpp -Wall -I
/Users/bennett/lyx/qt-4.4-install/include/QtCore/ -L /usr/lib64 -lQtCore

and get many instances of:

In file included from
/Users/bennett/lyx/qt-4.4-install/include/QtCore/QDateTime:1,
 from test.cpp:1:
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qdatetime.h:47:28: error:
QtCore/qstring.h: No such file or directory
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qdatetime.h:48:31: error:
QtCore/qnamespace.h: No such file or directory

(That is the right directory for QtCore.) I even tried setting QT4DIR
explicitly, but that didn't affect it.

What am I doing wrong?

Bennett

Re: File ModTime Bug: Please Check Your Platforms!

[Bennett Helm]

On Mon, Jul 21, 2008 at 12:43 PM, rgheck <[EMAIL PROTECTED]> wrote:

>
> Bug 5075 concerns a problem with QFileInfo::lastModtime() that causes
> failures in graphics and bibliography updates that have been confirmed on
> Linux with Qt 4.3.5 and Qt 4.4.something. A fix was committed at r25773,
> with conditional compilation for Linux and Qt >= 4.3.0. I'd appreciate it
> if people would check their platforms and Qt versions and help us make sure
> that this is the right check. That is: Using r25773 or later, does the
> Citation dialog update with changes to your bibfile when you make them? If
> not, please let me know platform and Qt version.


Does not work for me on Mac with Qt-4.4.0. (I only checked bibliography
updating.)

Bennett

Re: Approaching LyX 1.5.6

[Bennett Helm]

On Fri, Jul 18, 2008 at 8:40 AM, Konrad Hofbauer <[EMAIL PROTECTED]>
wrote:

>
>
> Bennett Helm wrote:
>
>> I won't guess a to what the source of the problem is. For all I know it's
>> a
>> bug in Qt-4.4, but it may well be our build procedure.
>>
>
> You think it IS a Qt-bug? That means you tested compiling with "all the
> same, but Qt-4.3" and then it worked for those people ???


No: I haven't done that, but it's a possibility -- for all I know (that is,
I just don't know).

Bennett

Re: Approaching LyX 1.5.6

[Bennett Helm]

On Fri, Jul 18, 2008 at 4:03 AM, Jürgen Spitzmüller <
[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
> > I really have no idea what the problem is or how to fix it, and I really
> > don't have time now to go digging into things I don't understand. Perhaps
> > Konrad has some ideas.
>
> If I recall correctly, the concerned binary was not built by you, but by
> Konrad, due to your computer problems, right?
>
> Is it possible that this (a different build procedure) is the source of the
> trouble?


The issue was not computer problems for me but rather my upgrading to Mac OS
X 10.5, which using my normal build procedure resulted in a binary that
could not run on other systems. Konrad eventually figured out new settings
that would let me create the binary. But, although the new binary seems to
work on most systems (including 10.4 and PPC), for some reason we don't
understand it has the screen drawing issues on some (but not all) 10.5-Intel
Macs -- the same system as mine, for all we can tell.

I won't guess a to what the source of the problem is. For all I know it's a
bug in Qt-4.4, but it may well be our build procedure.

Bennett

Re: Approaching LyX 1.5.6

[Bennett Helm]

On Thu, Jul 17, 2008 at 12:43 PM, Jürgen Spitzmüller <
[EMAIL PROTECTED]> wrote:

> One major thing I'd like to address with 1.5.6 are the Mac issues (screen
> redrawing issues) that forced some people to stick with 1.5.4. I hope
> these
> are build problems we can solve this time. In any case, the Mac binaries
> should be checked by people who were affected by the problems (I remember
> Georg being one of them).


I really have no idea what the problem is or how to fix it, and I really
don't have time now to go digging into things I don't understand. Perhaps
Konrad has some ideas.

Bennett

Re: sub-figures and labelling on 1.6.0beta4 + the-wheel-of-doom

[Bennett Helm]

On Tue, Jul 15, 2008 at 6:53 PM, Christopher Reeve <[EMAIL PROTECTED]>
wrote:




> -lables renaming-
> I often comment out text which I don't think I need, but don't want to
> delete. To do this I select the text, including any figures or sections and
> labels, and click the note button.
>
> If I decide I want the text and desolve the note then LyX thinks that it
> has
> found a duplicate of the labels and renames them. This problem also occurs
> of course if I just copy and past some of the commented out text back into
> my main text again.
>
> Perhaps LyX should *ask* whether it should change the label and even give
> the option for the user to create an alternative name themselves? Otherwise
> I would suggest that LyX does not recognise a commented out label, which is
> probably best because a user might be tempted to link to it resulting in a
> broken reference in their pdf.


I agree: this is a problem. There are legitimate reasons to want to have the
same label twice in a document, as when the labels are in different
branches.

LyX should warn of the potential problem and offer to rename, but allow the
user to decide what to do. (There already is the "DUPLICATE:" warning on the
labels, which is reasonable and which makes it easy to find the labels when
using outline view.) When typesetting, LyX should again warn when there are
duplicate labels in the produced LaTeX file, since otherwise there may be
unexpected results. But LyX shouldn't presume that it knows better than the
user. (That's one reason I can't stand Word.)


> -the wheel of doom-
> This is not specific to beta4. Is there any way that when a document is
> compiled that the GUI can continue running uninterrupted? You know,
> without showing the wheel of doom with a mac, or the dreaded hour
> glass on wondoze? Even one chapter can take an age to compile and
> sometimes I need to check if a table etc looks ok when it is compiled.
> It would be nice to continue working while the LaTeX compiler does its
> thing.


This has been mentioned before, though I couldn't find a enhancement request
in bugzilla after a quick search.

Bennett

Re: Slow saving on current trunk

[Bennett Helm]

On Tue, Jul 15, 2008 at 11:21 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
wrote:

> "Bennett Helm" <[EMAIL PROTECTED]> writes:
> >> And nowadays it would be: configure with --with-build-type=rel.
> >
> > Where is this documented?
>
> In INSTALL. There is even a nice table showing what this does.


That is nice. I wonder, though, whether something should be added to the
output of configure --help.

Bennett

Re: Slow saving on current trunk

[Bennett Helm]

On Tue, Jul 15, 2008 at 11:16 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
wrote:

> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > But side question for Bennett: are you sure you didn't configured with
> > stdlibdebug?
>
> And nowadays it would be: configure with --with-build-type=rel.


Where is this documented?

Bennett

Re: Slow saving on current trunk

[Bennett Helm]

On Tue, Jul 15, 2008 at 10:52 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Abdelrazak Younes wrote:
>
>> Abdelrazak Younes wrote:
>>
>>> Bennett Helm wrote:
>>>
>>>> save-profile.txt.zip<
>>>> http://edisk.fandm.edu/bennett.helm/LyX/save-profile.txt.zip>
>>>>
>>>>
>>> Out of 14.2 s taken by Paragraph::write()
>>>
>>> - 4.6 s is taken by FontList::fontIterator(int) or more exactly 4.1 s by
>>> matchFT()
>>>
>>> - 4.6 s is taken by to_utf8() among which 3.6 s for basic_string and
>>> vector allocations!!!
>>>
>>
>> Side note: I've been saying for a long long time that this conversion orgy
>> between basic_string and vector is a waste of time...
>>
> Side side note: the real conversion ucs4_to_utf8() takes only 0.44 s out of
> the above 4.6 second!
>
> But side question for Bennett: are you sure you didn't configured with
> stdlibdebug?


I didn't have it explicitly disabled, which I guess means that it was used.
(I had completely changed build settings trying to get cross-compilation to
work once beta4 came out, and apparently didn't fully restore my old
settings.) Having now recompiled with it disabled, I find save and open
times to be back to normal.

Sorry for the noise

Bennett

Re: Slow saving on current trunk

[Bennett Helm]

On Tue, Jul 15, 2008 at 9:07 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> With 1.6-beta4, saving large files took what seemed to be a reasonable
>> amount of time -- under a second. With current svn, I get save times of
>> longer than 10 seconds on the same files. What happened?
>>
>>
> I don't know but if that is still the case, I think it is worth
> investigating... A profile maybe?


I've created 2 profiles -- one for opening a file, and one for saving it.
You can find them here:

open-profile.txt.zip<http://edisk.fandm.edu/bennett.helm/LyX/open-profile.txt.zip>

save-profile.txt.zip<http://edisk.fandm.edu/bennett.helm/LyX/save-profile.txt.zip>

Bennett

Re: Problems with window size, source and outline view -- status?

[Bennett Helm]

On Tue, Jul 15, 2008 at 9:07 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Shall I create some bugzilla entries for these so that they don't get
>> forgotten?
>>
>>
> Yes, please do that.


Done:

http://bugzilla.lyx.org/show_bug.cgi?id=5048

http://bugzilla.lyx.org/show_bug.cgi?id=5049

Bennett

Re: LyX version 1.6.0 (beta 4) is released

[Bennett Helm]

On Tue, Jul 15, 2008 at 4:33 AM, José Matos <[EMAIL PROTECTED]> wrote:

> On Monday 14 July 2008 17:43:10 Bennett Helm wrote:
> > José - Can you upload the Universal binary to the server and delete the
> > Intel binary (so there's no confusion)? It's located here:
> >
> > http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.0b4-Mac-Universal.dmg
>
> Done. :-)


Thanks. Sorry for the hassle.

Bennett

Re: LyX version 1.6.0 (beta 4) is released

[Bennett Helm]

On Mon, Jul 14, 2008 at 12:29 PM, Konrad Hofbauer <[EMAIL PROTECTED]>
wrote:

> Bennett Helm wrote:
>
>> OK -- compiled this time with the right script, and it works on 1 Intel
>> and
>> 1 PPC Mac I've tried.
>>
>
> +1 Intel (Tiger).
>
>
>  I've placed the universal binary here:
>>
>> LyX-1.6.0b4-Mac-Univ..><
>> http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.0b4-Mac-Universal.dmg>
>>
>> Konrad -- please test, and assuming it works I'll ask that it be posted on
>> the server.
>>
>
>
> A minor remark (but we can ship it as is):
>
> The URLs in Section 4 of the included readme are mixed up (i.e. URL to
> wiki-page instead of users-list). Also, would you want to include a link to
> http://www.tug.org/mactex/ ?


Thanks, Konrad.

I don't think it's worth changing the ReadMe now, but I've made the URL
change in the .lyx document so that I won't forget. Adding something for
MacTeX would be good, but I can't do it now.

José - Can you upload the Universal binary to the server and delete the
Intel binary (so there's no confusion)? It's located here:

http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.0b4-Mac-Universal.dmg

Bennett

Slow saving on current trunk

[Bennett Helm]

With 1.6-beta4, saving large files took what seemed to be a reasonable
amount of time -- under a second. With current svn, I get save times of
longer than 10 seconds on the same files. What happened?
Bennett

Re: LyX version 1.6.0 (beta 4) is released

[Bennett Helm]

On Mon, Jul 14, 2008 at 10:31 AM, Konrad Hofbauer <[EMAIL PROTECTED]>
wrote:

> Hi Bennett,
>
> I did not run into the same problems as you did.
> Find a universal binary (only the application, without your installer) at
> <
> http://www2.spsc.tugraz.at/people/hofbauer/lyx/LyX-1.6.0b4-Mac-Universal-AppOnly.zip
> >


OK -- compiled this time with the right script, and it works on 1 Intel and
1 PPC Mac I've tried. I've placed the universal binary here:

LyX-1.6.0b4-Mac-Univ..>

Konrad -- please test, and assuming it works I'll ask that it be posted on
the server.

Thanks.

Bennett

Re: Freeze for beta4

[Bennett Helm]

On Mon, Jul 14, 2008 at 10:40 AM, Konrad Hofbauer <[EMAIL PROTECTED]>
wrote:


> Questions:
>
> 1) Why no -isysroot and -isyslibroot as we had it before?
>
> 2) Why specify --host AND --target? That is IMHO not how it is meant to be
> used. Sepcify --host as you have it, and --build with whatever
> ${LyxSourceDir}/config/config.guess tells you (on Leopard something like
> i686-apple-darwin9).
>
> See my (I thought: our) script attached in the email from a few minutes
> ago.


That's what I get for having too little time and duplicate files on my
computer: I used an old (1.5) version of the script. I'm currently compiling
now to see what happens. If that doesn't work, I'll take your version and
package it up.

Bennett

Re: LyX version 1.6.0 (beta 4) is released

[Bennett Helm]

On Mon, Jul 14, 2008 at 5:50 AM, José Matos <[EMAIL PROTECTED]> wrote:

> Public release of LyX version 1.6.0 (beta 4)
> ===
>
> We are glad to announce the release of LyX 1.6.0 (beta 4).


I've put a binary for Mac-Intel here:

LyX-1.6.0b4-Mac-Inte..>


As I've noted in another thread, I still cannot cross-compile for PPC, and
I'm not able to spend much more time working on it. If someone else is able
to produce a PPC binary, I can create the universal binary and post the
result.

Bennett

Re: Freeze for beta4

[Bennett Helm]

On Sat, Jul 12, 2008 at 2:55 AM, Konrad Hofbauer <[EMAIL PROTECTED]>
wrote:

> This error means that the (mac-specific) LinkBack stuff does not get
> re-compiled for PPC. The linker only finds the Intel stuff (even though you
> are compiling for PPC) and complains.
>
> Could it be that distclean misses to delete the LinkBack stuff?
> You could try to re-start from a fresh tar-ball after compiling Intel
> (instead of a make distclean) to see if that is the problem.


That doesn't help: I get the same error.


> Do you send me the build script you use right now?


Here's the relevant part:

export CFLAGS="-arch ppc"
export CXXFLAGS="-arch ppc"
export LDFLAGS="$LDFLAGS -arch ppc"
./configure --prefix="$LyxAppDir" --with-version-suffix=-1.6
--with-qt4-dir="$QtInstallDir" --without-aiksaurus --without-aspell
--without-pspell --enable-optimization=-Os --without-x
--with-included-gettext --host=ppc-apple-darwin8.8.1
--target=ppc-apple-darwin8.8.1
make -j3

This means that as of now, I cannot produce a universal binary.

Bennett

Re: Crash on quit

[Bennett Helm]

On Sat, Jul 12, 2008 at 6:33 AM, Uwe Stöhr <[EMAIL PROTECTED]> wrote:

> > Recently I've been getting occasional crashes on quit.
>
> I see this here too on Windows. Could you please report this at bugzilla so
> that this won't be forgotten?
>
> regards Uwe
>

Done:

http://bugzilla.lyx.org/show_bug.cgi?id=5026

Bennett

Re: Freeze for beta4

[Bennett Helm]

On Fri, Jul 11, 2008 at 12:00 PM, José Matos <[EMAIL PROTECTED]> wrote:

> On Friday 11 July 2008 13:37:44 José Matos wrote:
> > configure.ac has changed in trunk to reflect the beta 4 eminent release.
>
> The first attempt to have a release out of door can be found here:
>
> http://www.lyx.org/~jamatos/lyx-1.6
>
> If this works for the supported platforms I tag svn as beta4 and I will
> remove
> the freeze.
>
> Please test. As usual it works for me under rawhide (to be F10).


I'm getting a genuine problem on Mac when I try cross compiling for PPC. I'm
doing exactly what I did for 1.6 beta 3, but now I get this:

Making install in support
make  install-am
/bin/sh ../../libtool --tag=CXX   --mode=link g++  -arch ppc
-L/Users/bennett/lyx/qt-4.4-install/lib   -framework Carbon -framework
OpenGL -framework AGL -framework QuickTime -framework Cocoa -arch ppc -o
liblyxsupport.la  FileMonitor.lo convert.lo debug.lo docstream.lo
docstring.lo environment.lo FileName.lo filetools.lo ForkedCalls.lo
gettext.lo gzstream.lo kill.lo lassert.lo lstrings.lo lyxtime.lo lyxsum.lo
Messages.lo os.lo Path.lo Package.lo qstring_helpers.lo socktools.lo
Systemcall.lo SignalSlot.lo SignalSlotPrivate.lo Timeout.lo userinfo.lo
unicode.lo LinkBack.lo LinkBackProxy.lo LinkBackServer.lo  -lQtCore -lz -lm

rm -fr  .libs/liblyxsupport.a
ar cru .libs/liblyxsupport.a  FileMonitor.o convert.o debug.o docstream.o
docstring.o environment.o FileName.o filetools.o ForkedCalls.o gettext.o
gzstream.o kill.o lassert.o lstrings.o lyxtime.o lyxsum.o Messages.o os.o
Path.o Package.o qstring_helpers.o socktools.o Systemcall.o SignalSlot.o
SignalSlotPrivate.o Timeout.o userinfo.o unicode.o LinkBack.o
LinkBackProxy.o LinkBackServer.o
ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does
not match previous archive members cputype (18) (all members must match)
ranlib: archive member: .libs/liblyxsupport.a(LinkBackProxy.o) cputype (7)
does not match previous archive members cputype (18) (all members must
match)
ranlib: archive member: .libs/liblyxsupport.a(LinkBackServer.o) cputype (7)
does not match previous archive members cputype (18) (all members must
match)
ranlib .libs/liblyxsupport.a
ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does
not match previous archive members cputype (18) (all members must match)
ranlib: archive member: .libs/liblyxsupport.a(LinkBackProxy.o) cputype (7)
does not match previous archive members cputype (18) (all members must
match)
ranlib: archive member: .libs/liblyxsupport.a(LinkBackServer.o) cputype (7)
does not match previous archive members cputype (18) (all members must
match)
make[5]: *** [liblyxsupport.la] Error 1
make[4]: *** [install] Error 2
make[3]: *** [install-recursive] Error 1
make[2]: *** [install] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install-strip] Error 2
lipo: can't open input file:
/Users/bennett/Desktop/LyX.app/Contents/MacOS/ppc-apple-darwin8.8.1-lyx (No
such file or directory)
lipo: can't open input file:
/Users/bennett/Desktop/LyX.app/Contents/MacOS/ppc-apple-darwin8.8.1-lyxclient
(No such file or directory)
lipo: can't open input file:
/Users/bennett/Desktop/LyX.app/Contents/MacOS/ppc-apple-darwin8.8.1-tex2lyx
(No such file or directory)


Am I doing something wrong? (Note that I do make distclean before
configuring for cross compilation, so I'm not sure why I'm getting the
"cputype does not match previous archive members cputype" error ... whatever
that means.)

Bennett

Re: Freeze for beta4

[Bennett Helm]

On Fri, Jul 11, 2008 at 12:52 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
> > make[4]: *** Waiting for unfinished jobs
>
> do you use some paralelizing?


I guess I didn't look closely enough. Yes: I ran make -j3 install. Does that
explain it?

Bennett

Re: Freeze for beta4

[Bennett Helm]

On Fri, Jul 11, 2008 at 12:00 PM, José Matos <[EMAIL PROTECTED]> wrote:

> On Friday 11 July 2008 13:37:44 José Matos wrote:
> > configure.ac has changed in trunk to reflect the beta 4 eminent release.
>
> The first attempt to have a release out of door can be found here:
>
> http://www.lyx.org/~jamatos/lyx-1.6
>
> If this works for the supported platforms I tag svn as beta4 and I will
> remove
> the freeze.
>
> Please test. As usual it works for me under rawhide (to be F10).


Configure and make went fine for me on Mac. However, make install the
*first* time produced this:

Making install in config
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in development
Making install in MacOSX
Making install in spotlight
make[4]: Nothing to be done for `install-exec-am'.
test -z
"/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents"
|| ../../../config/install-sh -c -d
"/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents"
test -z
"/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/MacOS"
|| ../../../config/install-sh -c -d
"/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/MacOS"
test -z
"/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/Resources"
|| ../../../config/install-sh -c -d
"/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/Resources"
mkdir:
/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents:
File exists
make[4]: *** [install-dist_spotlightDATA] Error 1
make[4]: *** Waiting for unfinished jobs
 /usr/bin/install -c -m 644 'schema.xml'
'/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/Resources/schema.xml'
 /usr/bin/install -c -m 644 'LyX-Metadata'
'/Users/bennett/Desktop/LyX-16b4.app/Contents/Library/Spotlight/LyX-Metadata.mdimporter/Contents/MacOS/LyX-Metadata'
make[3]: *** [install-am] Error 2
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1


I tried it a second time, and everything worked. Not sure what happened.

In any case, the resulting binary works.

Bennett

Crash on quit

[Bennett Helm]

Recently I've been getting occasional crashes on quit. Using gdb, I see
multiple messages like this when LyX is running:


lyx(98256,0xa019dfa0) malloc: *** mmap(size=1206730752) failed (error
code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug


After I quit LyX I get the crash, and I look at the gdb output and see:


QObject: Do not delete object, 'unnamed', during its event handler!
QObject: Do not delete object, 'unnamed', during its event handler!
2008-07-11 12:00:39.845 lyx[98256:813] *** _NSAutoreleaseNoPool(): Object
0x1444e40 of class NSCFArray autoreleased with no pool in place - just
leaking
Stack: (0x90e4acdf 0x90d57562 0x931551b8 0x58063a 0x3a58de 0x3a59b3 0x3a5ee4
0x3a610b 0xb74bdd 0xa90a02 0x5b7278 0x60042d 0x367140 0x1107fd 0x117d3b
0x2129 0x2096)
2008-07-11 12:00:39.847 lyx[98256:813] *** _NSAutoreleaseNoPool(): Object
0x1080bf30 of class NSCFArray autoreleased with no pool in place - just
leaking
Stack: (0x90e4acdf 0x90d57562 0x92874867 0x92874557 0x58066a 0x3a58de
0x3a59b3 0x3a5ee4 0x3a610b 0xb74bdd 0xa90a02 0x5b7278 0x60042d 0x367140
0x1107fd 0x117d3b 0x2129 0x2096)
2008-07-11 12:00:39.847 lyx[98256:813] *** _NSAutoreleaseNoPool(): Object
0x10633fa0 of class NSCFSet autoreleased with no pool in place - just
leaking
Stack: (0x90e4acdf 0x90d57562 0x9287493e 0x92874557 0x58066a 0x3a58de
0x3a59b3 0x3a5ee4 0x3a610b 0xb74bdd 0xa90a02 0x5b7278 0x60042d 0x367140
0x1107fd 0x117d3b 0x2129 0x2096)
FileName.cpp(498): Could not delete
/Users/bennett/tmp/lyx_tmpdir98256yVijKo/lyx_tmpbuf5

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x6163697c
std::_Rb_tree,
std::_Select1st >,
std::less, std::allocator > >::lower_bound (this=0xb464, [EMAIL PROTECTED]) at
LyX.cpp:2190
2190{ return __lhs.compare(__rhs) < 0; }


(Note that I'm not sure if this output appears before or after I attempt to
quit.)

Here's the backtrace for the crash:


#0  std::_Rb_tree,
std::_Select1st >,
std::less, std::allocator > >::lower_bound (this=0xb464, [EMAIL PROTECTED]) at
LyX.cpp:2190
#1  0x00120d74 in std::map, std::allocator > >::operator[] (this=0xb460, [EMAIL PROTECTED]) at
LyX.cpp:2190
#2  0x0010f1b4 in lyx::getGuiMessages () at LyX.cpp:2190
warning: .o file
"/Users/bennett/lyx/lyx-devel/src/support/.libs/liblyxsupport.a(gettext.o)"
more recent than executable timestamp
#3  0x00566cef in lyx::_ ([EMAIL PROTECTED]) at LyX.cpp:2190
#4  0x0001592f in lyx::Buffer::~Buffer (this=0xefd148) at LyX.cpp:2190
#5  0x916dffdc in __cxa_finalize ()
#6  0x916dfed0 in exit ()
#7  0x209f in start ()


Bennett

Problems with window size, source and outline view -- status?

[Bennett Helm]

I'm not sure whether I'm about to reiterate problems I've mentioned before
with document windows that are on someone's list to fix, or whether these
problems have been forgotten, or whether they are thought to have been fixed
but in fact are not. So with apologies if I'm just making noise ...:
On Mac, at least, window sizes are often not remembered, though it's
inconsistent. This is true not only when opening existing documents but also
when opening new document windows. Jean-Marc had mentioned in a thread last
week that new windows should work like Firefox; I agree. Currently, though,
all new windows open with the same size, no matter how much I try to
readjust them.

Sometimes (again, it's inconsistent) windows open with source and outline
views open, even though these were not open the last time the document was
closed. This is true not only of existing documents but also of new
documents.

Shall I create some bugzilla entries for these so that they don't get
forgotten?

Bennett

Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...

[Bennett Helm]

On Tue, Jul 8, 2008 at 5:22 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
wrote:

> "Bennett Helm" <[EMAIL PROTECTED]> writes:
> > Yes -- with "\mac_like_word_movement true". I even moved aside my LyX
> user's
> > folder just to make sure.
>
> Could you try again?


That did it -- thanks!

Bennett

Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...

[Bennett Helm]

On Mon, Jul 7, 2008 at 5:39 PM, <[EMAIL PROTECTED]> wrote:

> "Bennett Helm" <[EMAIL PROTECTED]> writes:
> > I'm not sure what the status of this is now, but having just updating
> 1.6svn
> > after a week of being away, I notice that moving by word stops at *both*
> > word beginnings and word endings, whether moving forwards or backwards.
> Am I
> > missing something?
>
> Did you install the updated lyxrc.dist?


Yes -- with "\mac_like_word_movement true". I even moved aside my LyX user's
folder just to make sure.

Bennett

Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...

[Bennett Helm]

On Tue, Jun 24, 2008 at 9:25 AM, Bennett Helm <[EMAIL PROTECTED]> wrote:

> On Tue, Jun 24, 2008 at 8:52 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
> wrote:
>
>> > This is candidate for branch too. More problems remain in work
>> > skipping, but eating insets was the worst.
>>
>> With this additional patch, word movement should be closer to what the
>> mac does. It works through a lyxrc setting word_forward_goes_to_end
>> (!) that is not associated to a UI element but can be set in
>> lyxrc.dist.
>
>
I'm not sure what the status of this is now, but having just updating 1.6svn
after a week of being away, I notice that moving by word stops at *both*
word beginnings and word endings, whether moving forwards or backwards. Am I
missing something?

Bennett

Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...

[Bennett Helm]

On Tue, Jun 24, 2008 at 8:52 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
wrote:

> > This is candidate for branch too. More problems remain in work
> > skipping, but eating insets was the worst.
>
> With this additional patch, word movement should be closer to what the
> mac does. It works through a lyxrc setting word_forward_goes_to_end
> (!) that is not associated to a UI element but can be set in
> lyxrc.dist.


Yay! -- Thanks!


> An alternative to this would be to add a parameter ("mac" or whatever)
> to word-(|delete-)(for|back)ward, and get the right UI by changing
> mac.bind. The advantage is that scripting would be more robust.


Would this cause confusion with shortcuts preferences?

What would you prefer?
>
> Problems that remain:
>
> - cursor should stop at paragraph boundary.


Yes.


> - single quote should be part of words (but not at boundary?)


That's correct. That is, apostrophes (as in "don't") are treated as letters,
but single quotes (as in "'Hello'") are treated as spaces. So in the
sentence

 'Don't' is a good word.

when moving forward by words, the cursor should jump from the the beginning
of the line to just after the "t" and then to just after the "s". When
moving backwards, it should jump from the end to just before the "w" to just
before the "g" to just before the "a" to just before the "i" to just before
the "D".

Bennett

- we probably have to handle both the words-are-strings-of-letters
>  word-are-separated-by-spaces semantics.
>
> Other?
>
> JMarc
>
>

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 4:49 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> Nope: it still crashes on window close. Here's the new backtrace.
>>
>
> Better now?


 Yes.

I'm not sure I see a clear pattern to what is happening. The problem with
Document > Outline being checked but not visible is still there. Sometimes
in opening a new document, the source widget is visible, sometimes not.
Always new windows have the 3 toolbars visible, until I hide them ... for
each window id individually.

Is there a way to set toolbar behavior for all new windows, regardless of
which window id? (I tried, for example, setting templates/defaults.lyx
window how I like it, closing that window, and then opening new documents,
but the settings didn't stick.)

At any rate, it's getting better -- thanks! (Now when's dinner?)

Bennett

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 1:31 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote
>
>> 2. The first time a document is opened, it has too much visible: TOC,
>>>>> source, and the standard, extra, and view update toolbars. Wouldn't it
>>>>> be
>>>>> better to use document defaults for opening new windows?
>>>>>
>>>>>
>>>>
> This should be fixed now.


(I won't comment on this yet -- see below.)


> OK -- a more serious blemish. I just updated to r25326 (from 25325), and I
> get a crash on closing a window. Here's the backtrace:
>
>
And this too.


Nope: it still crashes on window close. Here's the new backtrace.

QObject: Do not delete object, 'unnamed', during its event handler!

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x0ea27c10 in ?? ()
(gdb) bt
#0  0x0ea27c10 in ?? ()
#1  0x001252b0 in lyx::LyXFunc::setLyXView (this=0x142cef0, lv=0xea27574) at
LyXFunc.cpp:212
#2  0x00b63987 in QCoreApplicationPrivate::sendThroughObjectEventFilters ()
#3  0x005ab26f in QApplicationPrivate::notify_helper ()
#4  0x005b151c in QApplication::notify ()
#5  0x0036beb1 in lyx::frontend::GuiApplication::notify (this=0x142d440,
receiver=0xea27560, event=0xea27560) at GuiApplication.cpp:1142
#6  0x00b63834 in QCoreApplication::notifyInternal () at qatomic_i386.h:134
#7  0x005af56d in QApplication::setActiveWindow () at crc.hpp:531
#8  0x005fa377 in QApplicationPrivate::globalEventProcessor () at
crc.hpp:531
#9  0x946d6763 in DispatchEventToHandlers ()
#10 0x946d5b9d in SendEventToEventTargetInternal ()
#11 0x946d5a02 in SendEventToEventTargetWithOptions ()
#12 0x9475af0d in PostActivateEvent ()
#13 0x9475a99b in HiliteAndActivateWindow ()
#14 0x94998135 in AdjustToNewWindowActivation ()
#15 0x9475bba8 in PotentiallyAdjustToNewWindowActivation ()
#16 0x9475baf2 in BringToFrontAndActivateWindow ()
#17 0x9475b9af in WindowData::SelectWindow ()
#18 0x0061060c in QWidget::activateWindow () at crc.hpp:531
#19 0x005fa8b8 in QApplicationPrivate::globalEventProcessor () at
crc.hpp:531
#20 0x946d6763 in DispatchEventToHandlers ()
#21 0x946d5b9d in SendEventToEventTargetInternal ()
#22 0x946d5a02 in SendEventToEventTargetWithOptions ()
#23 0x9470483c in ToolboxEventDispatcherHandler ()
#24 0x946d6b1c in DispatchEventToHandlers ()
#25 0x946d5b9d in SendEventToEventTargetInternal ()
#26 0x946f24ee in SendEventToEventTarget ()
#27 0x005f55a1 in qt_mac_send_event () at crc.hpp:531
#28 0x00601a42 in QEventDispatcherMac::processEvents () at crc.hpp:531
#29 0x00b62f41 in QEventLoop::processEvents () at qatomic_i386.h:134
#30 0x00b6306a in QEventLoop::exec () at qatomic_i386.h:134
#31 0x00b65d61 in QCoreApplication::exec () at qatomic_i386.h:134
#32 0x001164c9 in lyx::LyX::exec (this=0xb378, [EMAIL PROTECTED],
argv=0xb3bc) at LyX.cpp:442
#33 0x2379 in main (argc=1, argv=0xb3bc) at main.cpp:46


Bennett

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 12:11 PM, Bennett Helm <[EMAIL PROTECTED]> wrote:

> On Thu, Jun 19, 2008 at 12:04 PM, Abdelrazak Younes <[EMAIL PROTECTED]>
> wrote:
>
>>OK, I polished a few things there. It is very hard to get all the
>>>
>> use cases right so please do some testing and report back. The
>>>good news is that I've uniformised the behaviour for all platforms.
>>>
>>>
>>> With quick testing, it looks like a very nice present -- so shiny! A
>>> couple of blemishes, though:
>>>
>>> 1. TOC doesn't work properly. (I'm guessing now that this is an
>>> independent bug, which was the cause of my thinking before that I didn't
>>> have TOC open when profiling, though the profile indicated I did.) When I
>>> open the TOC and then close the document and reopen, the TOC drawer is not
>>> visible. However Document > Outline *is* checked, and selecting it unchecks
>>> it without altering the appearance of the window. Only selecting it a second
>>> time results in the TOC being viewed.
>>>
>>
>> Yes, somewhat related but something else.
>>
>>
>>> 2. The first time a document is opened, it has too much visible: TOC,
>>> source, and the standard, extra, and view update toolbars. Wouldn't it be
>>> better to use document defaults for opening new windows?
>>>
>>
>> Sure. And would you like some milk with your tea? That should be
>> fixable...
>
>
> And some sugar, too, please! Oh, and how about dinner to follow? 5 courses
> sounds about right. ...
>

OK -- a more serious blemish. I just updated to r25326 (from 25325), and I
get a crash on closing a window. Here's the backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x244489e5
0x244489e5 in ?? ()
(gdb) bt
#0  0x244489e5 in ?? ()
#1  0x001261bd in lyx::LyXFunc::getStatus (this=0x142cef0, [EMAIL PROTECTED])
at LyXFunc.cpp:388
#2  0x0010bd2a in lyx::getStatus ([EMAIL PROTECTED]) at LyX.cpp:1213
#3  0x004d348e in lyx::frontend::GuiView::updateToolbars (this=0xea275b0) at
GuiView.cpp:929
#4  0x004d3b88 in lyx::frontend::GuiView::updateDialogs (this=0xea275b0) at
GuiView.cpp:2271
#5  0x004d91a3 in lyx::frontend::GuiView::event (this=0xea275b0,
e=0xbfffdd78) at GuiView.cpp:751
#6  0x005ab26f in QApplicationPrivate::notify_helper () at LyX.cpp:1303
#7  0x005b151c in QApplication::notify () at LyX.cpp:1303
#8  0x0036bf01 in lyx::frontend::GuiApplication::notify (this=0x142d440,
receiver=0x244489e5, event=0x244489e5) at GuiApplication.cpp:1142
#9  0x00b63834 in QCoreApplication::notifyInternal () at LyX.cpp:1303
#10 0x005af56d in QApplication::setActiveWindow () at LyX.cpp:1303
#11 0x005fa377 in QApplicationPrivate::globalEventProcessor () at
LyX.cpp:1303
#12 0x946d6763 in DispatchEventToHandlers ()
#13 0x946d5b9d in SendEventToEventTargetInternal ()
#14 0x946d5a02 in SendEventToEventTargetWithOptions ()
#15 0x9475af0d in PostActivateEvent ()
#16 0x9475a99b in HiliteAndActivateWindow ()
#17 0x94998135 in AdjustToNewWindowActivation ()
#18 0x9475bba8 in PotentiallyAdjustToNewWindowActivation ()
#19 0x9475baf2 in BringToFrontAndActivateWindow ()
#20 0x9475b9af in WindowData::SelectWindow ()
#21 0x0061060c in QWidget::activateWindow () at LyX.cpp:1303
#22 0x005fa8b8 in QApplicationPrivate::globalEventProcessor () at
LyX.cpp:1303
#23 0x946d6763 in DispatchEventToHandlers ()
#24 0x946d5b9d in SendEventToEventTargetInternal ()
#25 0x946d5a02 in SendEventToEventTargetWithOptions ()
#26 0x9470483c in ToolboxEventDispatcherHandler ()
#27 0x946d6b1c in DispatchEventToHandlers ()
#28 0x946d5b9d in SendEventToEventTargetInternal ()
#29 0x946f24ee in SendEventToEventTarget ()
#30 0x005f55a1 in qt_mac_send_event () at LyX.cpp:1303
#31 0x00601a42 in QEventDispatcherMac::processEvents () at LyX.cpp:1303
#32 0x00b62f41 in QEventLoop::processEvents () at LyX.cpp:1303
#33 0x00b6306a in QEventLoop::exec () at LyX.cpp:1303
#34 0x00b65d61 in QCoreApplication::exec () at LyX.cpp:1303
#35 0x00116519 in lyx::LyX::exec (this=0xb378, [EMAIL PROTECTED],
argv=0xb3bc) at LyX.cpp:442
#36 0x23c9 in main (argc=1, argv=0xb3bc) at main.cpp:46

Bennett

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 12:04 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

>OK, I polished a few things there. It is very hard to get all the
>>
>use cases right so please do some testing and report back. The
>>good news is that I've uniformised the behaviour for all platforms.
>>
>>
>> With quick testing, it looks like a very nice present -- so shiny! A
>> couple of blemishes, though:
>>
>> 1. TOC doesn't work properly. (I'm guessing now that this is an
>> independent bug, which was the cause of my thinking before that I didn't
>> have TOC open when profiling, though the profile indicated I did.) When I
>> open the TOC and then close the document and reopen, the TOC drawer is not
>> visible. However Document > Outline *is* checked, and selecting it unchecks
>> it without altering the appearance of the window. Only selecting it a second
>> time results in the TOC being viewed.
>>
>
> Yes, somewhat related but something else.
>
>
>> 2. The first time a document is opened, it has too much visible: TOC,
>> source, and the standard, extra, and view update toolbars. Wouldn't it be
>> better to use document defaults for opening new windows?
>>
>
> Sure. And would you like some milk with your tea? That should be fixable...


And some sugar, too, please! Oh, and how about dinner to follow? 5 courses
sounds about right. ...

Bennett

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 11:43 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Thu, Jun 19, 2008 at 10:04 AM, Abdelrazak Younes <[EMAIL 
>> PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>
>>You mean "close the window showing file1.lyx" right? This trick
>>won't work if you only close the file.
>>
>>
>> Yes -- on Mac, closing the last document in a window automatically closes
>> the window. (Just to make sure this isn't affecting things, I tried it again
>> by clicking on the close-window widget rather than using File > Close, and
>> got the same behavior.)
>>
>
> OK, I polished a few things there. It is very hard to get all the use cases
> right so please do some testing and report back. The good news is that I've
> uniformised the behaviour for all platforms.


With quick testing, it looks like a very nice present -- so shiny! A couple
of blemishes, though:

1. TOC doesn't work properly. (I'm guessing now that this is an independent
bug, which was the cause of my thinking before that I didn't have TOC open
when profiling, though the profile indicated I did.) When I open the TOC and
then close the document and reopen, the TOC drawer is not visible. However
Document > Outline *is* checked, and selecting it unchecks it without
altering the appearance of the window. Only selecting it a second time
results in the TOC being viewed.

2. The first time a document is opened, it has too much visible: TOC,
source, and the standard, extra, and view update toolbars. Wouldn't it be
better to use document defaults for opening new windows?

Bennett

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 10:04 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Thu, Jun 19, 2008 at 7:30 AM, Abdelrazak Younes <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Abdelrazak Younes wrote:
>>>
>>>
>>>
>>>> The session entry is indexed with the window id. This id is simply an
>>>> integer which is simply incremented each time you open a window. Now, if
>>>> the
>>>> preference is set to have one window per document, I could use the
>>>> filename
>>>> instead. This solution would not be bullet proof but will work as long
>>>> as
>>>> you keep working with one window per document. The moment you use tabs,
>>>> it
>>>> won't.
>>>>
>>>>
>>>>
>>> FYI, I implement that.
>>>
>>>
>>
>>
>> That's a nice looking present, but it seems as though the box is empty!
>>
>>
>
> Hey, that's not Christmas time, what were you expecting? The present is the
> box!
>
>  -- That is, I don't notice any change in behavior. In particular, if I
>> open
>> file1.lyx, set the toolbars, close file1.lyx,
>>
>
> You mean "close the window showing file1.lyx" right? This trick won't work
> if you only close the file.


Yes -- on Mac, closing the last document in a window automatically closes
the window. (Just to make sure this isn't affecting things, I tried it again
by clicking on the close-window widget rather than using File > Close, and
got the same behavior.)


>  open newfile1.lyx, then
>> newfile1.lyx has the toolbars set the way they were for file1.lyx.
>> Moreover,
>> if I now (without first closing newfile1.lyx) open file1.lyx again, the
>> toolbars aren't set. The same is true of window location and size. In
>> short,
>> it looks like toolbars and window location and size are still married to
>> window id rather than filename.
>>
>> Am I doing something wrong?
>>
>>
> Are you sure you svn updated to rev > 25320?


Yes -- 25322.


> It seems to work fine for me on Windows if I uncheck "Open document in
> tabs".


I have that unchecked as well.

Bennett

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Thu, Jun 19, 2008 at 7:30 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Abdelrazak Younes wrote:
>
>> The session entry is indexed with the window id. This id is simply an
>> integer which is simply incremented each time you open a window. Now, if the
>> preference is set to have one window per document, I could use the filename
>> instead. This solution would not be bullet proof but will work as long as
>> you keep working with one window per document. The moment you use tabs, it
>> won't.
>>
>
> FYI, I implement that.


That's a nice looking present, but it seems as though the box is empty!
-- That is, I don't notice any change in behavior. In particular, if I open
file1.lyx, set the toolbars, close file1.lyx, open newfile1.lyx, then
newfile1.lyx has the toolbars set the way they were for file1.lyx. Moreover,
if I now (without first closing newfile1.lyx) open file1.lyx again, the
toolbars aren't set. The same is true of window location and size. In short,
it looks like toolbars and window location and size are still married to
window id rather than filename.

Am I doing something wrong?

Bennett

Re: Scrolling and painting is incredibly slow these days

[Bennett Helm]

On Wed, Jun 18, 2008 at 10:44 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>>
>> OK ... did I do something different (I tried not to), or is this the
>> effect
>> of your revision? -- The profile this time is ~300x shorter when
>> compressed.
>>
>>
>
> That's because you had the TocWidget opened for the first profile and
> closed for the second one.


Hmm... I don't believe I did.

One more thing, perhaps related: since R25305 (but possibly before),
fullscreen view is messed up in ways that seem to involve outline view:
without outline view showing, when I switch to fullscreen, it seems like the
outline drawer wants to reveal itself on its own, but then hides itself --
there's a flickering on the right side, and the column of text jumps to the
left a bit and then back to the center. Typing, scrolling, etc. are
impossible because on every keystroke the flicker and jump happens, and most
keystrokes get eaten (by outline view?).

Bennett

Re: Scrolling and painting is incredibly slow these days

[Bennett Helm]

On Wed, Jun 18, 2008 at 10:21 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Wed, Jun 18, 2008 at 9:58 AM, Abdelrazak Younes <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Yes -- it works without it. Here's the profile, though it
>>looks like I must be doing something wrong since it's not as
>>detailed as ones I'm used to getting.
>>
>>
>>Indeed. But could you try to expand the redrawAll() node anyway?
>>
>>
>> OK -- I figured out the problem. Here's a link to the compressed file
>> (which itself is almost 900K).
>>
>> users-guide-pgdown-p..> <
>> http://edisk.fandm.edu/bennett.helm/LyX/users-guide-pgdown-profile.txt.zip
>> >
>>
>
> Thanks but sorry, I just made a change that should impact performance at
> rev 25305. Could you generate a new report with that revision? The
> comparison will be interesting.


OK ... did I do something different (I tried not to), or is this the effect
of your revision? -- The profile this time is ~300x shorter when compressed.

users-guide-pgdown-p..><http://edisk.fandm.edu/bennett.helm/LyX/users-guide-pgdown-profile2.txt.zip>

Bennett

Re: Scrolling and painting is incredibly slow these days

[Bennett Helm]

On Wed, Jun 18, 2008 at 9:58 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Yes -- it works without it. Here's the profile, though it looks like I must
>> be doing something wrong since it's not as detailed as ones I'm used to
>> getting.
>>
>
> Indeed. But could you try to expand the redrawAll() node anyway?


OK -- I figured out the problem. Here's a link to the compressed file (which
itself is almost 900K).

users-guide-pgdown-p..>

Bennett

Re: Scrolling and painting is incredibly slow these days

[Bennett Helm]

On Wed, Jun 18, 2008 at 9:10 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> On Wed, Jun 18, 2008 at 7:58 AM, Abdelrazak Younes <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Could someone produce a profile with the UserGuide test* please?
>>
>>
>>Abdel.
>>
>>* Hold the PageDown key pressed to scroll the UserGuide
>>
>>
>> I tried, but running the test produces a crash. Here's the backtrace:
>>
>
> It seems that you have the pixmap cache enabled. I'll try to fix that if I
> can reproduce. In the mean time, could you try again after disabling it (in
> Look&Feel -> Screen Font)?


Yes -- it works without it. Here's the profile, though it looks like I must
be doing something wrong since it's not as detailed as ones I'm used to
getting.

+ 9195.6 ms main (lyx)

| + 3833.9 ms lyx::frontend::WorkAreaManager::redrawAll() (lyx)

| |   1.0 ms lyx::from_ascii(std::basic_string,
std::allocator > const&) (lyx)

|   4.0 ms lyx::to_utf8(std::basic_string, std::allocator > const&) (lyx)

| + 2.0 ms lyx::from_utf8(std::basic_string,
std::allocator > const&) (lyx)

| |   2.0 ms lyx::utf8_to_ucs4(std::basic_string, std::allocator > const&,
std::basic_string,
std::allocator >&) (lyx)

|   1.0 ms lyx::utf8_to_ucs4(std::basic_string,
std::allocator > const&, std::basic_string, std::allocator >&) (lyx)

|   1.0 ms
boost::signals::detail::signal_base::signal_base[not-in-charge](boost::function2 > const&, boost::any const&) (lyx)

+ 3833.9 ms lyx::frontend::WorkAreaManager::redrawAll() (lyx)

|   1.0 ms lyx::from_ascii(std::basic_string,
std::allocator > const&) (lyx)

  4.0 ms lyx::to_utf8(std::basic_string,
std::allocator > const&) (lyx)

  3.0 ms lyx::utf8_to_ucs4(std::basic_string,
std::allocator > const&, std::basic_string, std::allocator >&) (lyx)

+ 2.0 ms lyx::from_utf8(std::basic_string,
std::allocator > const&) (lyx)

|   2.0 ms lyx::utf8_to_ucs4(std::basic_string,
std::allocator > const&, std::basic_string, std::allocator >&) (lyx)

  1.0 ms lyx::from_ascii(std::basic_string,
std::allocator > const&) (lyx)

  1.0 ms
boost::signals::detail::signal_base::signal_base[not-in-charge](boost::function2 > const&, boost::any const&) (lyx)



Bennett

Re: Scrolling and painting is incredibly slow these days

[Bennett Helm]

On Wed, Jun 18, 2008 at 7:58 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Could someone produce a profile with the UserGuide test* please?
>
>
> Abdel.
>
> * Hold the PageDown key pressed to scroll the UserGuide


I tried, but running the test produces a crash. Here's the backtrace:

pplatex: Process input file 0lyxpreview.dvi
pplatex: Copy data to 0lyxpreview.dvi
dvipng warning: at (0,13) unimplemented \special{html:} dvipng warning: at (0,13) unimplemented
\special{html:} dvipng warning: at (-1,-8) unimplemented
\special{html:} dvipng warning: at (-1,-8)
unimplemented \special{html:} dvipng warning: at (0,11) unimplemented
\special{html:} dvipng warning: at (0,11)
unimplemented \special{html:} dvipng warning: at (-3,22) unimplemented
\special{html:} dvipng warning: at (-3,22)
unimplemented \special{html:} Qt: QPixmap: Invalid pixmap parameters
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] : Unable to
create bitmap delegate device
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
createBitmapContext: failed to create delegate.
QPaintDevice: Unable to create context for pixmap (-2/17/0)
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextTranslateCTM: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextScaleCTM: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineCap: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineWidth: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineJoin: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineDash: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetStrokeColorWithColor: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineCap: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineWidth: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineJoin: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineDash: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetStrokeColorWithColor: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetShouldAntialias: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetInterpolationQuality: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetShouldSmoothFonts: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineCap: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineWidth: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineJoin: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineDash: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetStrokeColorWithColor: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetFillColorWithColor: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetShouldAntialias: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetFontSize: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextGetTextMatrix: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetTextMatrix: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetTextDrawingMode: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetFont: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetTextPosition: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextShowGlyphsWithAdvances: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetTextMatrix: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetShouldAntialias: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineCap: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineWidth: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineJoin: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetLineDash: invalid context
Wed Jun 18 08:47:27 dhcp-155-68-79-92.fandm.edu lyx[2953] :
CGContextSetStrokeColorWithColor: invalid context
Qt: QPixmap: Invalid pixmap parameters

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfff7
0x0ac4 in __memcpy ()
(gdb) bt
#0  0x0ac4 in __memc

GuiWorkArea - bottom 1/3 of window all grey

[Bennett Helm]

Abdel -
Your last change to GuiWorkArea leaves the bottom 1/3 of document windows
all grey -- even if there's text there. (Of course, this is true for me on
Mac.)

Bennett

Re: r25238 compile failure

[Bennett Helm]

On Thu, Jun 12, 2008 at 1:34 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Should be fixed now.


Yep -- and the bug is fixed, too. Thanks!
Bennett

r25238 compile failure

[Bennett Helm]

if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../..  -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src
-I../../../src/frontends -I../../../images
-I/Users/bennett/lyx/qt-4.4-install/include
-I/Users/bennett/lyx/qt-4.4-install/include/QtGui
-I/Users/bennett/lyx/qt-4.4-install/include/QtCore   -I../../../boost
 -Wextra -Wall-g -O3 -MT TocModel.lo -MD -MP -MF ".deps/TocModel.Tpo" -c
-o TocModel.lo TocModel.cpp; \
then mv -f ".deps/TocModel.Tpo" ".deps/TocModel.Plo"; else rm -f
".deps/TocModel.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DQT_NO_STL -DQT_NO_KEYWORDS
-I../../../src -I../../../src/frontends -I../../../images
-I/Users/bennett/lyx/qt-4.4-install/include
-I/Users/bennett/lyx/qt-4.4-install/include/QtGui
-I/Users/bennett/lyx/qt-4.4-install/include/QtCore -I../../../boost -Wextra
-Wall -g -O3 -MT TocModel.lo -MD -MP -MF .deps/TocModel.Tpo -c TocModel.cpp
-o TocModel.o
TocModel.cpp: In member function 'QModelIndex
lyx::frontend::TocModel::modelIndex(const lyx::DocIterator&) const':
TocModel.cpp:50: error: call of overloaded 'QVariant(const size_t&)' is
ambiguous
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:214: note:
candidates are: QVariant::QVariant(Qt::GlobalColor) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:193: note:
  QVariant::QVariant(const QChar&)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:190: note:
  QVariant::QVariant(const QString&) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:188: note:
  QVariant::QVariant(const QByteArray&) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:185: note:
  QVariant::QVariant(const char*) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:183: note:
  QVariant::QVariant(double)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:182: note:
  QVariant::QVariant(bool)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:181: note:
  QVariant::QVariant(qulonglong)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:180: note:
  QVariant::QVariant(qlonglong)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:179: note:
  QVariant::QVariant(uint)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:178: note:
  QVariant::QVariant(int)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:172: note:
  QVariant::QVariant(const QVariant&)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:170: note:
  QVariant::QVariant(QVariant::Type) 
TocModel.cpp: In constructor 'lyx::frontend::TocModel::TocModel(const
lyx::Toc&)':
TocModel.cpp:77: error: conversion from 'size_t' to 'const QVariant' is
ambiguous
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:214: note:
candidates are: QVariant::QVariant(Qt::GlobalColor) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:185: note:
  QVariant::QVariant(const char*) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:183: note:
  QVariant::QVariant(double)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:182: note:
  QVariant::QVariant(bool)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:181: note:
  QVariant::QVariant(qulonglong)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:180: note:
  QVariant::QVariant(qlonglong)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:179: note:
  QVariant::QVariant(uint)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:178: note:
  QVariant::QVariant(int)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:170: note:
  QVariant::QVariant(QVariant::Type) 
TocModel.cpp: In member function 'void
lyx::frontend::TocModel::populate(size_t&, const QModelIndex&)':
TocModel.cpp:114: error: conversion from 'long unsigned int' to 'const
QVariant' is ambiguous
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:214: note:
candidates are: QVariant::QVariant(Qt::GlobalColor) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:185: note:
  QVariant::QVariant(const char*) 
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:183: note:
  QVariant::QVariant(double)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:182: note:
  QVariant::QVariant(bool)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:181: note:
  QVariant::QVariant(qulonglong)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:180: note:
  QVariant::QVariant(qlonglong)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:179: note:
  QVariant::QVariant(uint)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:178: note:
  QVariant::QVariant(int)
/Users/bennett/lyx/qt-4.4-install/include/QtCore/qvariant.h:170: note:
  QVariant::QVariant(QVariant::Type) 
make[4]: *** [TocModel.lo

Re: Dock status tied to documents rather than windows?

[Bennett Helm]

On Wed, Jun 11, 2008 at 6:41 PM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:

> Bennett Helm wrote:
>
>> So, having ranted a bit (sorry!), let me now raise the question: how do we
>> want LyX to behave? If my views here aren't shared, would it be easy to
>> have
>> LyX's behavior on Mac conform more closely to Mac users' expectations in
>> this case?
>>
>
> The moment I put this comment on bugzilla I knew you will strike back ;-)


I figured behavior that crazy had to be intentional! ;P


> I understand your position and if possible we should accommodate the
> session behaviour to Mac one window per document standard.



> But I for one don't like to have tens of windows opened, I like tabs; I
> will most likely have a maximum of three windows. Just like with Firefox.
> IOW I don't want the Outline to close when I am clicking on another tab. I
> guess I am not alone in that case...
>
> But to answer your question, it should not be hard technically to
> optionally come closer to Mac standards, it would just require some work,
> see below.
>
>  Bennett
>>
>> By the way, where do we store information about dock status, dialog
>> locations, etc.?
>>
>>
> We (well, I) use Qt tools (QSettings, etc). But for file oriented session
> management we still use the home-grown Session class which I would like to
> kill someday.


I was actually asking where the data were stored: in the LyX user's folder?
somewhere else? (I've looked, but can't find it.)


> But this is very low priority for me, sorry.


Completely understandable.

Bennett