On 01/22/2011 07:07 PM, Ben Goodrich wrote:
Pavel Sanda lyx.org> writes:
most trivial patch would be something like
#ifdef linux
void fixdamnedext4(){fopen(f);fsync(f);fclose(f);}
#endif
and call it somewhere after saving file.
it would need some brave ext4 soul to test that this actually work
Pavel Sanda lyx.org> writes:
> most trivial patch would be something like
> #ifdef linux
> void fixdamnedext4(){fopen(f);fsync(f);fclose(f);}
> #endif
> and call it somewhere after saving file.
> it would need some brave ext4 soul to test that this actually works.
I have ext4 and a 2.6.37 kernel
Peter Kümmel wrote:
> Does this mean we have no Windows installer.
about official one the situation is even worse since no clear message was
written - either yes or no ;)
the currently alternative one can be done at march according to Uwe.
> What was the reason to have two installers?
unresolved
Pavel Sanda wrote:
> in principle i'm all for it. i would just rename the method to
> isOnTheDamnedExt4().
actually if we are going to code something specific for ext4 we could try
straight forward solution - really use fsync.
most trivial patch would be something like
#ifdef linux
void fixdamne
Enrico Forestieri wrote:
> On Sat, Jan 22, 2011 at 01:53:40AM +0100, Pavel Sanda wrote:
>
> > this patch should help at least for symlinks.
>
> Why not restricting the workaround to the case where the file actually
> is stored on an ext4 file system?
in principle i'm all for it. i would just ren
kuem...@lyx.org wrote:
> Author: kuemmel
> Date: Sat Jan 22 13:40:13 2011
> New Revision: 37300
> URL: http://www.lyx.org/trac/changeset/37300
>
> Log:
> cmake: make package_source work.
>
> 12M lyx-2.0.tar.bz2
note that we currently ship .xz instead of bz2 (9M).
> 15M lyx-2.0.tar.gz
> 18M lyx-
On 2011-01-22, Raymond Lillard wrote:
> This may be (probably is) my fault but anyhow this is a
> problem for me.
> From a recent thread with subject line:
>"Italic textual Greek with Palatino (mathpazo)"
> Liviu Andronic wrote:
>Interesting workaround, but I keep getting this error when
On 22.01.2011 18:28, Edwin Leuven wrote:
Peter Kümmel wrote:
We use a finished signal already in GuiView:
connect(&d.processing_thread_watcher_, SIGNAL(finished()), this,
SLOT(processingThreadFinished()));
assume there is also a started().
thanks, the attached patch
comments welcome as usual
+ QString fname = toqstr(libFileSearch("images",
"wait.gif").absFileName());
lyx::libFileSearch
or
lyx::support::libFileSearch
Merged build knows both at this place.
Peter
On 22.01.2011 20:08, Enrico Forestieri wrote:
On Sat, Jan 22, 2011 at 07:42:00PM +0100, Peter Kümmel wrote:
On 22.01.2011 18:28, Edwin Leuven wrote:
the attached patch includes the icon
No, it doesn't ;)
wget http://dl.dropbox.com/u/359550/busy.gif
Thanks, tried it only with Firefox.
Pe
On Sat, Jan 22, 2011 at 03:48:06PM +0100, Stephan Witt wrote:
> Am 22.01.2011 um 15:33 schrieb Enrico Forestieri:
>
> > On Sat, Jan 22, 2011 at 01:53:40AM +0100, Pavel Sanda wrote:
> >
> >> this patch should help at least for symlinks.
> >
> > Why not restricting the workaround to the case wher
On 22.01.2011 17:06, Abdelrazak Younes wrote:
On 22/01/2011 16:57, Peter Kümmel wrote:
On 22.01.2011 16:17, Abdelrazak Younes wrote:
I don't know, this looks like a good idea from the outside and Joost
and Uwe said they won't have time to do anything in the short term.
Oh, then we shoul
On 22.01.2011 16:17, Abdelrazak Younes wrote:
I don't know, this looks like a good idea from the outside and Joost
and Uwe said they won't have time to do anything in the short term.
Does this mean we have no Windows installer.
Had a look at development/Win32/packaging with lots of .nsh
On Sat, Jan 22, 2011 at 07:42:00PM +0100, Peter Kümmel wrote:
> On 22.01.2011 18:28, Edwin Leuven wrote:
> >the attached patch includes the icon
>
> No, it doesn't ;)
wget http://dl.dropbox.com/u/359550/busy.gif
mv busy.gif lib/images/wait.gif
--
Enrico
On 22.01.2011 14:36, Abdelrazak Younes wrote:
All cmake files should be globed in the CMakeList (so that they are
accessible from QtCreator and MSVC). I think lyxrc and ui/ files for
menubar and toolbars defintion should also be globed.
Added all files from lib/ui. But I could not find lyxrc.
On 22.01.2011 17:50, Stephan Witt wrote:
Am 22.01.2011 um 16:54 schrieb Peter Kümmel:
On 22.01.2011 16:46, Stephan Witt wrote:
Peter,
is it possible to add extra library/include file search paths?
If I want to debug the aspell/hunspell I have to use my private builds on Mac.
I want to pass
On 22.01.2011 18:28, Edwin Leuven wrote:
the attached patch includes the icon
No, it doesn't ;)
Peter Kümmel wrote:
> We use a finished signal already in GuiView:
>
> connect(&d.processing_thread_watcher_, SIGNAL(finished()), this,
> SLOT(processingThreadFinished()));
>
> assume there is also a started().
thanks, the attached patch includes the icon
comments welcome a
Am 22.01.2011 um 16:54 schrieb Peter Kümmel:
> On 22.01.2011 16:46, Stephan Witt wrote:
>> Peter,
>>
>> is it possible to add extra library/include file search paths?
>>
>> If I want to debug the aspell/hunspell I have to use my private builds on
>> Mac.
>>
>> I want to pass it as options from
On 22/01/2011 16:57, Peter Kümmel wrote:
On 22.01.2011 16:17, Abdelrazak Younes wrote:
I don't know, this looks like a good idea from the outside and Joost
and Uwe said they won't have time to do anything in the short term.
Oh, then we should try it. But without reading the doc it will n
On 22.01.2011 16:17, Abdelrazak Younes wrote:
I don't know, this looks like a good idea from the outside and Joost
and Uwe said they won't have time to do anything in the short term.
Oh, then we should try it. But without reading the doc it will not work ;)
http://cmake.org/cmake/help/cma
On 22.01.2011 16:46, Stephan Witt wrote:
Peter,
is it possible to add extra library/include file search paths?
If I want to debug the aspell/hunspell I have to use my private builds on Mac.
I want to pass it as options from command line, otherwise I have to change the
e. g. FindASPELL.cmake to
On 22.01.2011 16:36, Edwin Leuven wrote:
it is great that lyx is no longer frozen when compiling a document,
but i am missing some visual feedback that something is indeed
happening
i thought that it may be nice to hace a little spinning icon like
http://dl.dropbox.com/u/359550/busy.gif
Link
Am 22.01.2011 um 16:10 schrieb Peter Kümmel:
> On 22.01.2011 14:36, Abdelrazak Younes wrote:
>> On 22/01/2011 12:04, Peter Kümmel wrote:
>>> Before we set LyX 2.0 in stone by releasing it
>>> I've cleaned up a bit the LYX_ option naming,
>>> to make it more consistent:
>>>
>>> - only positive nam
it is great that lyx is no longer frozen when compiling a document,
but i am missing some visual feedback that something is indeed
happening
i thought that it may be nice to hace a little spinning icon like
http://dl.dropbox.com/u/359550/busy.gif
in the status bar when something is happening the
On 22/01/2011 16:10, Peter Kümmel wrote:
On 22.01.2011 14:36, Abdelrazak Younes wrote:
On 22/01/2011 12:04, Peter Kümmel wrote:
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBAL
On 22/01/2011 16:13, Peter Kümmel wrote:
On 22.01.2011 14:39, Abdelrazak Younes wrote:
On 22/01/2011 12:04, Peter Kümmel wrote:
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBAL
On 22.01.2011 14:39, Abdelrazak Younes wrote:
On 22/01/2011 12:04, Peter Kümmel wrote:
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBALE_ names)
- short names when it is clear w
On 22.01.2011 14:36, Abdelrazak Younes wrote:
On 22/01/2011 12:04, Peter Kümmel wrote:
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBALE_ names)
- short names when it is clear w
Am 22.01.2011 um 15:33 schrieb Enrico Forestieri:
> On Sat, Jan 22, 2011 at 01:53:40AM +0100, Pavel Sanda wrote:
>
>> this patch should help at least for symlinks.
>
> Why not restricting the workaround to the case where the file actually
> is stored on an ext4 file system?
It's copied for syml
On Sat, Jan 22, 2011 at 01:53:40AM +0100, Pavel Sanda wrote:
> this patch should help at least for symlinks.
Why not restricting the workaround to the case where the file actually
is stored on an ext4 file system?
We could introduce a fileName().isOnExt4() method for that purpose.
See the attach
On 22/01/2011 12:04, Peter Kümmel wrote:
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBALE_ names)
- short names when it is clear what the option means (no USE_)
- no redundant o
On 22/01/2011 12:04, Peter Kümmel wrote:
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBALE_ names)
- short names when it is clear what the option means (no USE_)
- no redundant o
Peter Kümmel wrote:
> Any ideas for other changes?
INSTALL.cmake ?
pavel
Before we set LyX 2.0 in stone by releasing it
I've cleaned up a bit the LYX_ option naming,
to make it more consistent:
- only positive names (replace NO_ and DISBALE_ names)
- short names when it is clear what the option means (no USE_)
- no redundant options, e.g. LYX_RELEASE=0 is a debug buil
On 22.01.2011 11:03, Pavel Sanda wrote:
Peter Kümmel wrote:
There could be other functions in doExport which are also called by other
threads
in particular?
I only saw that doExport is a long function with much calls.
Peter
Peter Kümmel wrote:
> There could be other functions in doExport which are also called by other
> threads
in particular?
pavel
Jim Oldfield wrote:
>
> Believe it or not, this actually affects me on Windows! My LyX files are in
if you desperately need it, lyx 1.6.4 is still without this problem.
> filename()). If the patch goes in I'll test in the RC and file a bug with QT
> if
> not.
that would be good. i wait for
I'm not sure I understand you here. Do you say, at some places we should
copy the Converters:
Converters converters = theConverters();
yes. and some place == buffer export as it was in the original patch.
does it make sense?
In Buffer::doExport I've introduced the copying of the Converters,
th
39 matches
Mail list logo
