Peter Kuemmel wrote:
> >
> > what is your vision howto proceed with those 'other calls'?
> >
>
> I've found some errors in my code, but have also the impression
> QProcess in buggy on Linux (Kubuntu Qt 4.5.1)
>
> 1. QProcess::waitForFinished() sometimes crashes
> 2. QProcess::waitForFinished(
On Sat, Jun 6, 2009 at 4:35 PM, Jean-Marc Lasgouttes wrote:
> Le 6 juin 09 à 16:56, BH a écrit :
>>
>> So it looks like either spelling is disabled on Mac (for compatibility
>> with those who don't have aspell installed), or we bundle aspell libs
>> into LyX.app. Is there a way to do the latter, at
Peter Kuemmel wrote:
> > > I've found some errors in my code, but have also the impression
> > > QProcess in buggy on Linux (Kubuntu Qt 4.5.1)
> > >
> > > 1. QProcess::waitForFinished() sometimes crashes
> > > 2. QProcess::waitForFinished() sometimes does not return (splash does
> > not disappea
Original-Nachricht
> Datum: Sat, 6 Jun 2009 22:20:10 +0200
> Von: Pavel Sanda
> An: lyx-devel@lists.lyx.org
> Betreff: Re: GuiProgess
> Peter Kuemmel wrote:
> > >
> > > what is your vision howto proceed with those 'other calls'?
> > >
> >
> > I've found some errors in my code
Le 6 juin 09 à 16:56, BH a écrit :
So it looks like either spelling is disabled on Mac (for compatibility
with those who don't have aspell installed), or we bundle aspell libs
into LyX.app. Is there a way to do the latter, at least on Mac? (Or am
I missing some third option?)
How did you build
Peter Kuemmel wrote:
> >
> > what is your vision howto proceed with those 'other calls'?
> >
>
> I've found some errors in my code, but have also the impression
> QProcess in buggy on Linux (Kubuntu Qt 4.5.1)
>
> 1. QProcess::waitForFinished() sometimes crashes
> 2. QProcess::waitForFinished(
>
> what is your vision howto proceed with those 'other calls'?
>
I've found some errors in my code, but have also the impression
QProcess in buggy on Linux (Kubuntu Qt 4.5.1)
1. QProcess::waitForFinished() sometimes crashes
2. QProcess::waitForFinished() sometimes does not return (splash doe
rgheck schrieb:
This would make it impossible for me to keep the docs up to date.
Imagine Georg adds something about label translation, 3 hours later
Jürgen adds something about thesaurus. Result: When Jürgen would
accept the changes, I will loose Georg's changes.
No, you don't, because the
On Sat, Jun 06, 2009 at 02:00:03PM -0400, rgheck wrote:
> Uwe Stöhr wrote:
> > rgheck schrieb:
> >
> Here's another suggestion: ct should always be used when editing docs,
> >
> > Yes, this is already the policy.
> >
> but then anyone who edits the file again should accept all changes
>
Uwe Stöhr wrote:
rgheck schrieb:
Here's another suggestion: ct should always be used when editing docs,
Yes, this is already the policy.
but then anyone who edits the file again should accept all changes
before doing anything else.
This would make it impossible for me to keep the docs up
On Sat, Jun 06, 2009 at 04:39:40PM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > I was just waiting to know whether I should use change tracking or
> > not. It seems that I should not? I vote for not to use it, because
> > after a few changes to the same place things start becomi
Pavel Sanda wrote:
rgh...@lyx.org wrote:
Author: rgheck
Date: Sat Jun 6 16:29:24 2009
New Revision: 29997
URL: http://www.lyx.org/trac/changeset/29997
Log:
Add a note about docbook() problems.
while we are it - i just quickly browsed through the few links about hacking
docbook
outpu
Uwe Stöhr wrote:
> > And who is going to accept the changes? You? And when? And you wouldn't
> > do
>
> > that for Extended.lyx, right?
>
> I will accept all changes for Intro, Tutorial, UserGuide, Math, and
> EmbeddedObjects.
And then? Do you tell the translators what has changed? Or do you assu
> And who is going to accept the changes? You? And when? And you wouldn't do
> that for Extended.lyx, right?
I will accept all changes for Intro, Tutorial, UserGuide, Math, and
EmbeddedObjects.
regards Uwe
Pavel Sanda wrote:
> Peter Kuemmel wrote:
>>> back to the patch - i didn't get what you intend with this splash?
>> For long operations lyx is simply death, and the idea was to show at
>> least a bit of information what's going on.
>
> aha. so at least it should be automatically closed after proce
Pavel Sanda schreef:
Richard Heck wrote:
I have a very hard time seeing how this might be implemented reliably. What
would be easy, however, would be a kind of "expert" mode, where LyX does
not output ANY preamble other than the one specified by the user. This
could be toggled on and off, a
Uwe Stöhr wrote:
> This would make it impossible for me to keep the docs up to date. Imagine
> Georg adds something about label translation, 3 hours later Jürgen adds
> something about thesaurus. Reusult: When Jürgen would accept the changes, I
> will loose Georg's changes.
And who is going to acc
rgheck schrieb:
Here's another suggestion: ct should always be used when editing docs,
Yes, this is already the policy.
but then anyone who edits the file again should accept all changes
before doing anything else.
This would make it impossible for me to keep the docs up to date. Imagine G
rgh...@lyx.org wrote:
> Author: rgheck
> Date: Sat Jun 6 16:29:24 2009
> New Revision: 29997
> URL: http://www.lyx.org/trac/changeset/29997
>
> Log:
> Add a note about docbook() problems.
while we are it - i just quickly browsed through the few links about hacking
docbook
output of lyx listed i
Georg Baum wrote:
> > i just grep -i thread of our sources and havent seen a single occurence of
> > thread related code. can't this introduce some performance penalties?
>
> In theory yes. In practice I don't think so, qt is not available without
> thread support since version 4, and the single t
Jürgen Spitzmüller wrote:
rgheck wrote:
Here's another suggestion: ct should always be used when editing docs,
but then anyone who edits the file again should accept all changes
before doing anything else. This leaves an intelligible trail for
translators and maintainers, who can update from
On Sat, Jun 6, 2009 at 6:36 AM, Jean-Marc Lasgouttes wrote:
>
> Le 6 juin 09 à 01:23, BH a écrit :
>
>> On Fri, Jun 5, 2009 at 5:41 PM, Jean-Marc Lasgouttes
>> wrote:
And how can I tell that? (I'm using the libraries provided by
cocoAspell, which I'd guess most people would do. ... (
rgheck wrote:
> Here's another suggestion: ct should always be used when editing docs,
> but then anyone who edits the file again should accept all changes
> before doing anything else. This leaves an intelligible trail for
> translators and maintainers, who can update from svn one revision at a
>
Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
I was just waiting to know whether I should use change tracking or
not. It seems that I should not? I vote for not to use it, because
after a few changes to the same place things start becoming hardly
readable (and prone to formatting errors)
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
I thought Uwe is the principal documentation maintainer?
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg144789.html
Well, I completely missed that. Do we have maintainers for the other docs?
I really think we need a clear, c
Richard Heck wrote:
> I have a very hard time seeing how this might be implemented reliably. What
> would be easy, however, would be a kind of "expert" mode, where LyX does
> not output ANY preamble other than the one specified by the user. This
> could be toggled on and off, and people could cu
Pavel Sanda wrote:
John McCabe-Dansted wrote:
However I was wondering if this sounds like a good feature for LyX itself?
http://www.lyx.org/trac/ticket/5031
http://www.lyx.org/trac/ticket/5366
I have a very hard time seeing how this might be implemented reliably.
What would be eas
Enrico Forestieri wrote:
> Jürgen, may I also add it to branch?
Yes.
Jürgen
Enrico Forestieri wrote:
> I was just waiting to know whether I should use change tracking or
> not. It seems that I should not? I vote for not to use it, because
> after a few changes to the same place things start becoming hardly
> readable (and prone to formatting errors).
As said, I think it's
On Sat, Jun 06, 2009 at 10:19:41AM -0400, BH wrote:
> On Sat, Jun 6, 2009 at 6:38 AM, Enrico Forestieri wrote:
> > On Fri, Jun 05, 2009 at 07:52:58PM -0400, BH wrote:
> >
> >> It works when renamed to lyxeditor from lyxeditor.sh. (Skim.app --
> >> which I'm guessing is the most widely used .pdf vi
Pavel Sanda wrote:
> > I thought Uwe is the principal documentation maintainer?
>
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg144789.html
Well, I completely missed that. Do we have maintainers for the other docs?
I really think we need a clear, coherent policy. I also think our trans
Pavel Sanda wrote:
> Georg Baum wrote:
>> That depends. If the subset of boost that LyX uses is inherently
>> threadsafe, or if LyX does not use boost in two threads at the same time,
>> it could work
>
> i just grep -i thread of our sources and havent seen a single occurence of
> thread related
On Sat, Jun 06, 2009 at 04:24:40PM +0200, Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> >thats the convetion for the manuals Uwe maintains. but it doesn't cover
> >customization and additional features manual. for the rest it is kind of
> > chaos now.
>
> I thought Uwe is the principal documen
Jürgen Spitzmüller wrote:
> I thought Uwe is the principal documentation maintainer?
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg144789.html
Pavel Sanda wrote:
>thats the convetion for the manuals Uwe maintains. but it doesn't cover
>customization and additional features manual. for the rest it is kind of
> chaos now.
I thought Uwe is the principal documentation maintainer?
> secondly it does inform that trunk has not been updated (wh
Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Hmm... there's a risk of shipping the document in that state if you
> > forgot to accept the changes. I find that ldiff does a good job in
> > showing differences between two versions of the same document, if
> > you are interested in what wa
On Sat, Jun 6, 2009 at 6:38 AM, Enrico Forestieri wrote:
> On Fri, Jun 05, 2009 at 07:52:58PM -0400, BH wrote:
>
>> It works when renamed to lyxeditor from lyxeditor.sh. (Skim.app --
>> which I'm guessing is the most widely used .pdf viewer that can do
>> reverse search on Mac -- has a LyX setting
Enrico Forestieri wrote:
> Hmm... there's a risk of shipping the document in that state if you
> forgot to accept the changes. I find that ldiff does a good job in
> showing differences between two versions of the same document, if
> you are interested in what was changed.
I got the impression tha
On Sat, Jun 06, 2009 at 02:45:59PM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > BTW, you seem to have forgotten to accept the changes before
> > committing.
>
> This was intended, so others can more easily see what I've changed.
Hmm... there's a risk of shipping the document i
On Sat, Jun 06, 2009 at 01:42:32PM +0200, Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > The advantage of synctex is that it is part of the pdftex core. You do not
> > need to have to call a package for each and every document, not care about
> > PDF
> > vs. DVI output, but just change the
> The attached patch changes that along the same lines as the AMS theorem
> translations:
>
> \providecommand{\algorithmname}{Algorithm}
> \floatname{algorithm}{\protect\Algorithm}
>
> where \algorithmname is redefined by babel if needed. OK to go in?
Looks good and should also go to branch if Jü
> you have to create an account by Register link. maybe this link
> could be put more visible in login page (or even tracker home?)
The bug is that
http://www.lyx.org/trac/newticket
only states a meaningless error message
"TICKET_CREATE privileges are required to perform this operation"
If possib
Peter Kuemmel wrote:
> > back to the patch - i didn't get what you intend with this splash?
>
> For long operations lyx is simply death, and the idea was to show at
> least a bit of information what's going on.
aha. so at least it should be automatically closed after process finished?
dont we use
Currently, LyX does not translate the names of automatically generated
floats. It creates code like
\floatname{algorithm}{Algorithm}
The attached patch changes that along the same lines as the AMS theorem
translations:
\providecommand{\algorithmname}{Algorithm}
\floatname{algorithm}{\protect\Alg
Georg Baum wrote:
> That depends. If the subset of boost that LyX uses is inherently threadsafe,
> or if LyX does not use boost in two threads at the same time, it could work
i just grep -i thread of our sources and havent seen a single occurence of
thread
related code. can't this introduce some
Georg Baum wrote:
> > So let's wait. If we put the patch in early in the 1.6.4 cycle, we have
> > at least the chance to test it.
>
> I put it in now.
OK, thanks. So external-boost people, please give it a try.
Jürgen
Pavel Sanda wrote:
> Georg Baum wrote:
>> I don't know what happens if you
>> link against a true single threaded boost, you might be lucky, or get
>> spurious problems at runtime).
>
> btw are we supposed to link against the multithreaded version? i just
> checked that i have 1.6 linked against
Original-Nachricht
> Datum: Sat, 6 Jun 2009 14:33:46 +0200
> Von: Pavel Sanda
> An: lyx-devel@lists.lyx.org
> Betreff: Re: GuiProgess
> Peter Kuemmel wrote:
> > > > fixed, it was a QtGui header.
> > >
> > > don't beat me, i'm innocent :)
> >
> > Have you removed the new files
Enrico Forestieri wrote:
> Fine, but until LyX cannot take advantage of the extended precision granted
> by synctex, using it or pdfsync is a matter of personal taste, IMHO.
> Unless you incur in the above problems, of course :)
Granted, but that's why we should document both and outline the pros
Enrico Forestieri wrote:
> You did an excellent job, but there are some formatting glitches to
> be corrected. If you like, I could try to correct them.
Yes.
> BTW, you seem to have forgotten to accept the changes before
> committing.
This was intended, so others can more easily see what I've ch
Jean-Marc Lasgouttes wrote:
> I added it.
Thanks (I also asked Lars in the meantime)
> Do you want to be trac_admin? There is no way to grant
> specifically
> the right to add versions.
Yes, why not.
Jürgen
Peter Kuemmel wrote:
> > > fixed, it was a QtGui header.
> >
> > don't beat me, i'm innocent :)
>
> Have you removed the new files (git -f clean) before patching again?
removing the new files and adding them back helped indeed.
so you can beat me :D
back to the patch - i didn't get what you i
Original-Nachricht
> Datum: Sat, 6 Jun 2009 13:10:06 +0200
> Von: Pavel Sanda
> An: lyx-devel@lists.lyx.org
> Betreff: Re: GuiProgess
> Peter Kümmel wrote:
> > Pavel Sanda wrote:
> > > Peter Kuemmel wrote:
> > >> Attached a patch which makes use of the new QProgress support in
Vincent van Ravesteijn - TNW wrote:
> I regularly check out the latest modified bugs, and now I'm too often
> disappointed (after waiting minutes for trac) that the only change has
we can make compromise that i'll do this only once at late night so you are
not annoyed to often during the day ;)
>
Jürgen Spitzmüller wrote:
> The advantage of synctex is that it is part of the pdftex core. You do not
> need to have to call a package for each and every document, not care about
> PDF
> vs. DVI output, but just change the converter to
>
> pdflatex -synctex=1 $$i
anyway would it be worth to a
Pavel Sanda wrote:
> Peter Kümmel wrote:
>> Pavel Sanda wrote:
>>> Peter Kuemmel wrote:
Attached a patch which makes use of the new QProgress support in
Systemcall.
>>> Systemcall.cpp:28:24: error: QApplication: No such file or directory
>>> Systemcall.cpp: In member function 'int
>>> l
John McCabe-Dansted wrote:
> However I was wondering if this sounds like a good feature for LyX itself?
http://www.lyx.org/trac/ticket/5031
http://www.lyx.org/trac/ticket/5366
Le 6 juin 09 à 13:24, Jean-Marc Lasgouttes a écrit :
I did not find a way to do it (yet), but any link is welcome (I do
not know much more than
anyone else, actually...)
This might be useful for french-speaking people. On what do we want to
color BTW?
http://www.lefinnois.net/wp/index.php
Le 5 juin 09 à 17:35, Vincent van Ravesteijn - TNW a écrit :
Isn't it a better idea to color the tables based on severity ?
Jean-Marc, is there a default for this in the settings ?
I did not find a way to do it (yet), but any link is welcome (I do not
know much more than
anyone else, actual
On Sat, Jun 06, 2009 at 09:32:14AM +0200, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > > > Shall I update the docs?
> > >
> > > Yes, please.
> >
> > done (in branch).
>
> I've done some further revisions, because I found the current description
> rather technical and slightly unstru
On Sat, Jun 06, 2009 at 07:33:50AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > > Shall I update the docs?
> >
> > Yes, please.
>
> done (in branch).
>
> > > BTW2 we should also mention synctex in the docs, since it is about to
> > > supersede pdfsync (I don't know if any of t
Peter Kümmel wrote:
> Pavel Sanda wrote:
> > Peter Kuemmel wrote:
> >> Attached a patch which makes use of the new QProgress support in
> >> Systemcall.
> >
> > Systemcall.cpp:28:24: error: QApplication: No such file or directory
> > Systemcall.cpp: In member function 'int
> > lyx::support::Syst
Le 5 juin 09 à 17:21, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
I used that in the past to mark bugs that must be fixed before a
release
(since "blocker" on bugzilla had a different meaning).
So, do you want it? It is up to you.
Yes, please add it.
done.
BTW. do you know
On Fri, Jun 05, 2009 at 07:52:58PM -0400, BH wrote:
> It works when renamed to lyxeditor from lyxeditor.sh. (Skim.app --
> which I'm guessing is the most widely used .pdf viewer that can do
> reverse search on Mac -- has a LyX setting predefined for the former,
> and it would be better to avoid ch
Le 6 juin 09 à 01:23, BH a écrit :
On Fri, Jun 5, 2009 at 5:41 PM, Jean-Marc Lasgouttes> wrote:
And how can I tell that? (I'm using the libraries provided by
cocoAspell, which I'd guess most people would do. ... (Would there
be
a way of bundling this into LyX.app?)
What do you find in /usr
On Saturday 06 June 2009 02:02:25 am John McCabe-Dansted wrote:
> Often proceedings give authors sample .tex files to demonstrate how a
> paper should be formatted. I generally want to make my preamble as
> close as possible the sample. Usually I can trick LyX into generating
> something pretty clo
Russ Woodroofe wrote:
> In any case, it looks closer to the output.
I committed it.
Jürgen
Jürgen Spitzmüller wrote:
> > > Shall I update the docs?
> >
> > Yes, please.
>
> done (in branch).
I've done some further revisions, because I found the current description
rather technical and slightly unstructured. The revision is the attempt to
structure it a bit. It adds some more explanati
Pavel Sanda wrote:
> Peter Kuemmel wrote:
>> Attached a patch which makes use of the new QProgress support in Systemcall.
>
> Systemcall.cpp:28:24: error: QApplication: No such file or directory
> Systemcall.cpp: In member function 'int
> lyx::support::Systemcall::startscript(lyx::support::System
69 matches
Mail list logo
