On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some thread-releated fixme was left iirc)
and
On 23.02.2011 21:19, Peter Kümmel wrote:
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
bisect leads to r37749
http://www.lyx.org/trac/changeset/37749/lyx-devel/trunk
and -dgb
On 23.02.2011 21:52, Peter Kümmel wrote:
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
bisect leads to r37749
http://www.lyx.org/trac
On 23.02.2011 22:12, Stephan Witt wrote:
Am 23.02.2011 um 22:06 schrieb kuem...@lyx.org:
Author: kuemmel
Date: Wed Feb 23 22:06:15 2011
New Revision: 37778
URL: http://www.lyx.org/trac/changeset/37778
Log:
fix wrong preprocessor
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiKeySymbol.cpp
Peter, you were asked more than once from Joost how to handle this. But no
reaction.
It was send to kuem...@lyx.org. I don't have such a address.
How could I get it?
Peter
On 23.02.2011 12:06, Joost Verburg wrote:
"Peter Kümmel"<syntheti...@gmx.net> wrote in message
news:4d641864.1090...@gmx.net...
Here it breaks the merged build.
Any idea what's the cause of this issue? It must be related to a certain
file type not being set correctly. After
On 23.02.2011 19:46, Peter Kümmel wrote:
On 23.02.2011 12:06, Joost Verburg wrote:
"Peter Kümmel"<syntheti...@gmx.net> wrote in message
news:4d641864.1090...@gmx.net...
Here it breaks the merged build.
Any idea what's the cause of this issue? It must be related to a c
On 23.02.2011 19:53, Pavel Sanda wrote:
Peter Kümmel wrote:
Peter, you were asked more than once from Joost how to handle this. But no
reaction.
It was send to kuem...@lyx.org. I don't have such a address.
How could I get it?
there was message about this from Lars at Mon, 09 Mar 2009
On 23.02.2011 20:01, Joost Verburg wrote:
"Peter Kümmel"<syntheti...@gmx.net> wrote in message
news:4d655881.9090...@gmx.net...
Fixed: http://www.lyx.org/trac/changeset/37776/lyx-devel/trunk
Thanks! The text files are still C++ headers now but I guess MSVC ignores
those
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some thread-releated fixme was left iirc)
and
On 23.02.2011 21:19, Peter Kümmel wrote:
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
=> crash.
i got it now.p
bisect leads to r37749
http://www.lyx.org/trac/changeset/37749/lyx-devel/trunk
and -dgb
On 23.02.2011 21:52, Peter Kümmel wrote:
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
=> crash.
i got it now.p
bisect leads to r37749
http://www.lyx.org/t
On 23.02.2011 22:12, Stephan Witt wrote:
Am 23.02.2011 um 22:06 schrieb kuem...@lyx.org:
Author: kuemmel
Date: Wed Feb 23 22:06:15 2011
New Revision: 37778
URL: http://www.lyx.org/trac/changeset/37778
Log:
fix wrong preprocessor
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiKeySymbol.cpp
Peter, you were asked more than once from Joost how to handle this. But no
reaction.
Sorry, sometimes I enable a filter. But I could find nothing in the archive.
Peter
On 22.02.2011 14:59, Joost Verburg wrote:
Peter Kümmelsyntheti...@gmx.net wrote in message
news:4d636252.8070...@gmx.net...
is definitely wrong. Please revert. This macro is only to add files to
the IDE and these files should not influence the build process, therefore
the header only flag.
Peter, you were asked more than once from Joost how to handle this. But no
reaction.
Sorry, sometimes I enable a filter. But I could find nothing in the archive.
Peter
On 22.02.2011 14:59, Joost Verburg wrote:
"Peter Kümmel"<syntheti...@gmx.net> wrote in message
news:4d636252.8070...@gmx.net...
is definitely wrong. Please revert. This macro is only to add files to
the IDE and these files should not influence the build process, therefore
the
Joost,
http://www.lyx.org/trac/changeset/37702/lyx-devel/trunk/development/cmake
is definitely wrong. Please revert. This macro is only to add files to
the IDE and these files should not influence the build process, therefore
the header only flag.
When you have problems with some files it is
Joost,
http://www.lyx.org/trac/changeset/37702/lyx-devel/trunk/development/cmake
is definitely wrong. Please revert. This macro is only to add files to
the IDE and these files should not influence the build process, therefore
the header only flag.
When you have problems with some files it is
On 16.02.2011 00:11, Tommaso Cucinotta wrote:
# New file
KK: \Cn
# Find Advanced
KK: \CF
and assertion at FindAndReplace.cpp:58
51 /// Apply to buf the parameters supplied through bp
52 static void ApplyParams(Bufferbuf, BufferParams const bp) {
53ss \\end_header\n;
54
On 16.02.2011 00:11, Tommaso Cucinotta wrote:
# New file
KK: \Cn
# Find Advanced
KK: \CF
and assertion at FindAndReplace.cpp:58
51 /// Apply to buf the parameters supplied through bp
52 static void ApplyParams(Buffer, BufferParams const& bp) {
53ss<< "\\end_header\n";
54
In many dialogs I see descriptions abbreviated by ...
and even when there is a horizontal scrollbar it is not
possible to see the whole text without resizing the
complete dialog.
The ... could be suppressed by these two lines of code,
done here for the Module entry of the Document dialog:
On 14.02.2011 21:37, Pavel Sanda wrote:
Peter Kümmel wrote:
In many dialogs I see descriptions abbreviated by ...
and even when there is a horizontal scrollbar it is not
possible to see the whole text without resizing the
complete dialog.
The ... could be suppressed by these two lines of code
In many dialogs I see descriptions abbreviated by "..."
and even when there is a horizontal scrollbar it is not
possible to see the whole text without resizing the
complete dialog.
The "..." could be suppressed by these two lines of code,
done here for the Module entry of the Document dialog:
On 14.02.2011 21:37, Pavel Sanda wrote:
Peter Kümmel wrote:
In many dialogs I see descriptions abbreviated by "..."
and even when there is a horizontal scrollbar it is not
possible to see the whole text without resizing the
complete dialog.
The "..." could be suppresse
On 11.02.2011 11:02, Abdelrazak Younes wrote:
On 02/11/2011 01:08 AM, Vincent van Ravesteijn wrote:
Op 11-2-2011 1:02, Enrico Forestieri schreef:
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h
On 11.02.2011 10:18, Pavel Sanda wrote:
Peter Kümmel wrote:
Log:
seems the other have different compilers ;)
this works here in both normal and monolithic case. p
Is there also a monolithic build with auto tools?
./configure --enable-monolithic-build
Is this new? Since one year or so
No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as extern also in version.cpp.
You mean declaring it in the header as extern const int i is the same as
.h: const int i;
.cpp static int i;
No, I mean that if you want a
, 2011 at 12:49:22AM +0100, Peter Kümmel wrote:
On 11.02.2011 00:34, Enrico Forestieri wrote:
No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as extern also in version.cpp.
You mean declaring it in the header as extern const int
01:04 AM, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:49:22AM +0100, Peter Kümmel wrote:
On 11.02.2011 00:34, Enrico Forestieri wrote:
No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as extern also in version.cpp.
You
Great it is Friday!
So, no, nice tentative but we are not going to rewrite LyX in Vala! :-)
This was not my idea. I would create a new language similar to vala
and rewrite LyX in this language. :-)
Is there something like application specific programming language?
Peter
On 11.02.2011 11:02, Abdelrazak Younes wrote:
On 02/11/2011 01:08 AM, Vincent van Ravesteijn wrote:
Op 11-2-2011 1:02, Enrico Forestieri schreef:
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h
On 11.02.2011 10:18, Pavel Sanda wrote:
Peter Kümmel wrote:
Log:
seems the other have different compilers ;)
this works here in both normal and monolithic case. p
Is there also a monolithic build with auto tools?
./configure --enable-monolithic-build
Is this new? Since one year or so
No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as "extern" also in version.cpp.
You mean declaring it in the header as "extern const int i" is the same as
.h: const int i;
.cpp static int i;
No, I mean that if you want a
, 2011 at 12:49:22AM +0100, Peter Kümmel wrote:
On 11.02.2011 00:34, Enrico Forestieri wrote:
No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as "extern" also in version.cpp.
You mean declaring it in the header as &qu
01:04 AM, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:49:22AM +0100, Peter Kümmel wrote:
On 11.02.2011 00:34, Enrico Forestieri wrote:
No, const variables have internal linkage, so they will not be seen outside
their compile unit. Simply declare them as "extern" also in version.
Great it is Friday!
So, no, nice tentative but we are not going to rewrite LyX in Vala! :-)
This was not my idea. I would create a new language similar to vala
and rewrite LyX in this language. :-)
Is there something like "application specific programming language"?
Peter
On 11.02.2011 00:34, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591
Log:
compile.
Modified:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h to support to fix it.
Should I commit?
Peter
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py (revision 37592)
+++
On 11.02.2011 01:05, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 01:02:03AM +0100, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h to support to fix it.
Should I commit
On 11.02.2011 01:04, Pavel Sanda wrote:
Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h to support to fix it.
Should I commit?
It compiles and links fine here.
+1
isn't
On 11.02.2011 00:34, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591
Log:
compile.
Modified:
As long as variables are declared const, it's not a real problem I
guess. Technically, if they are const, they are no variables anymore.
At least one knows immediately that the global variables are
constants, otherwise we would have used functions for sure. And one
never knows whether a
On 11.02.2011 03:16, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Fri Feb 11 03:09:22 2011
New Revision: 37595
URL: http://www.lyx.org/trac/changeset/37595
Log:
seems the other have different compilers ;)
this works here in both normal and monolithic case. p
Is there
On 11.02.2011 00:34, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591
Log:
compile.
Modified:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h to support to fix it.
Should I commit?
Peter
Index: development/scons/scons_manifest.py
===
--- development/scons/scons_manifest.py (revision 37592)
+++
On 11.02.2011 01:05, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 01:02:03AM +0100, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h to support to fix it.
Should I commit
On 11.02.2011 01:04, Pavel Sanda wrote:
Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:54:02AM +0100, Peter Kümmel wrote:
Am I the only one where client does not build?
I have to move TexRow.cpp/.h to support to fix it.
Should I commit?
It compiles and links fine here.
+1
isn't
On 11.02.2011 00:34, Enrico Forestieri wrote:
On Fri, Feb 11, 2011 at 12:06:00AM +0100, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Thu Feb 10 23:57:41 2011
New Revision: 37591
URL: http://www.lyx.org/trac/changeset/37591
Log:
compile.
Modified:
As long as variables are declared const, it's not a real problem I
guess. Technically, if they are const, they are no variables anymore.
At least one knows immediately that the global "variables" are
constants, otherwise we would have used functions for sure. And one
never knows whether a
On 11.02.2011 03:16, Pavel Sanda wrote:
kuem...@lyx.org wrote:
Author: kuemmel
Date: Fri Feb 11 03:09:22 2011
New Revision: 37595
URL: http://www.lyx.org/trac/changeset/37595
Log:
seems the other have different compilers ;)
this works here in both normal and monolithic case. p
Is there
On 03.02.2011 20:04, Bill Hoffman wrote:
On 2/3/2011 12:20 PM, Peter Kümmel wrote:
On 03.02.2011 17:20, Peter Kümmel wrote:
Because good solution is not available
I've added the mentioned namespace support
to CMake:
namespace(string)
endnamespace()
With attached patch it is possible to write
On 03.02.2011 21:24, Peter Kümmel wrote:
This would be better discussed on the cmake-developers mailing list.
Indeed, this is the wrong list for this. Somehow I missed that there is a devel
list.
Sorry for the noise, bit it seems I'm on another list with such a idiotic reply
rule where I
So long, as it were not version 2.8.2. This one is buggy at generating debian
package. The verion 2.8.0 is ok though.
Tried cpack -G DEB --config CPackConfig.cmake with the current cmake (git)
master version and got no
errors, so there is hope.
Peter
On 03.02.2011 20:04, Bill Hoffman wrote:
On 2/3/2011 12:20 PM, Peter Kümmel wrote:
On 03.02.2011 17:20, Peter Kümmel wrote:
Because good solution is not available
I've added the mentioned namespace support
to CMake:
namespace()
endnamespace()
With attached patch it is possible to write
code
On 03.02.2011 21:24, Peter Kümmel wrote:
This would be better discussed on the cmake-developers mailing list.
Indeed, this is the wrong list for this. Somehow I missed that there is a devel
list.
Sorry for the noise, bit it seems I'm on another list with such a idiotic reply
rule where I
So long, as it were not version 2.8.2. This one is buggy at generating debian
package. The verion 2.8.0 is ok though.
Tried "cpack -G DEB --config CPackConfig.cmake" with the current cmake (git)
master version and got no
errors, so there is hope.
Peter
On 29.01.2011 13:24, Kornel wrote:
Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta:
insets/InsetTabular.cpp: In member function ‘int
lyx::Tabular::TeXTopHLine(lyx::otexstream, size_t, std::string) const’:
insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator’
in
On 29.01.2011 13:24, Kornel wrote:
> Am Samstag, 29. Januar 2011 schrieb Tommaso Cucinotta:
>> insets/InsetTabular.cpp: In member function ‘int
>> lyx::Tabular::TeXTopHLine(lyx::otexstream&, size_t, std::string) const’:
>> insets/InsetTabular.cpp:2068: error: ambiguous overload for ‘operator<<’
On 24.01.2011 11:32, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
It's really nice!
and pretty innocuous, so i put it in:
http://www.lyx.org/trac/changeset/37304/lyx-devel/trunk
I just can't get the icon to appear.
Anyone else having problems with it ?
worked here. but maybe you
On 23.01.2011 10:59, Pavel Sanda wrote:
Edwin Leuven wrote:
Peter Kümmel syntheti...@gmx.net wrote:
It's really nice!
and pretty innocuous, so i put it in:
Peter, wasn't there some hour-glass cursor switching
for background compilation, which is to be killed now?
Totally forgot
Peter,
This code you introduced looks a bit strange. It reintroduces the bug
again that the LaTeX Error dialog pops up on autosaving.
Sorry, was a cp bug, somehow my changes got lost.
Vincent
On 24.01.2011 14:12, Vincent van Ravesteijn wrote:
I've fixed cmake. But someone should update src/frontends/qt4/Makefile.am
Still no luck here.
The icon is in qrc_resources.cxx and Resources.qrc, but it doesn't
show in LyX :(.
Does this help?
Peter
Index:
On 24.01.2011 11:32, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
It's really nice!
>>>
>>> and pretty innocuous, so i put it in:
>>>
>>> http://www.lyx.org/trac/changeset/37304/lyx-devel/trunk
>>>
>>
>> I just can't get the icon to appear.
>>
>> Anyone else having problems with it ?
>
On 23.01.2011 10:59, Pavel Sanda wrote:
> Edwin Leuven wrote:
>> Peter Kümmel <syntheti...@gmx.net> wrote:
>>> It's really nice!
>>
>> and pretty innocuous, so i put it in:
>
> Peter, wasn't there some hour-glass cursor switching
> for back
> Peter,
>
> This code you introduced looks a bit strange. It reintroduces the bug
> again that the LaTeX Error dialog pops up on autosaving.
Sorry, was a c bug, somehow my changes got lost.
>
> Vincent
>
On 24.01.2011 14:12, Vincent van Ravesteijn wrote:
>>>
>>
>> I've fixed cmake. But someone should update src/frontends/qt4/Makefile.am
>>
>
> Still no luck here.
>
> The icon is in qrc_resources.cxx and Resources.qrc, but it doesn't
> show in LyX :(.
Does this help?
Peter
Index:
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,
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
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
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
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
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
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
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 ;)
On 22.01.2011 18:28, Edwin Leuven wrote:
the attached patch includes the icon
No, it doesn't ;)
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 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 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 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
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
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 18:28, Edwin Leuven wrote:
Peter Kümmelsyntheti...@gmx.net 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,
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,
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
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
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
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
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
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
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 ;)
On 22.01.2011 18:28, Edwin Leuven wrote:
the attached patch includes the icon
No, it doesn't ;)
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 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 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 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
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
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
601 - 700 of 4099 matches
Mail list logo
