Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
>
> | For trunk I propose to update the included boost to 1.34cvs, since boost
> | is in freeze and boost 1.34 will probably be released before LyX 1.5.0.
> | Lars wanted to do that last month, but then came unicode ;-)
>
> Ju
Michael Gerz wrote:
> Hi,
>
> I have a few LFUN-related questions:
>
> * Is LFUN_ERROR_NEXT still needed or can we remove it?
http://bugzilla.lyx.org/show_bug.cgi?id=2775
> * Does anybody know why we have word-find-backward, word-find-forward,
> and word-find (3 instead of 2 functions)?
I d
Hello,
I don't know if a standalone console lyx2tex (maybe with lyx2lyx) is too
farfetched...
I can imagine (myself, for instance) trying to convert a lyx document to latex,
withouth having to install/execute a full-fledged LyX.
Maybe stripping down all the display code is too much, but having t
Hello,
I just want to report that CygLyX-QtX11 1.4.2 runs perfectly fine on
Win98, save for the required xorg-x11-fscl package, overlooked by the
Wiki page on Cygwin. Without this package the program displays blank
squares; in fact, this package alone guarantees the installation of
Cygwin's X11 se
When starting a fresh build (i.e., just after running configure with an
initially empty build dir) I am getting the following error from make:
cp libgnuintl.h libintl.h
cp: cannot stat `libgnuintl.h': No such file or directory
make[1]: *** [libintl.h] Error 1
and I have to manually
cp /intl/libg
On Thu, Aug 24, 2006 at 06:47:22PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > I have compiled a Cygwin version of LyX/Qt4 using the native GUI (no X11)
> > and now I see the chinese characters mentioned by Abdel when I load
> > an old document. I also get a lot of messages on t
Le jeudi 24 août 2006 16:57, Lars Gullik Bjønnes a écrit :
> Félix-Antoine Bourbonnais <[EMAIL PROTECTED]> writes:
> | > No, that is not the problem. I found it out now: It is again the
> | > pollution of the global namespace in qt3 with the signals keyword. The
> | > attached patch (including m
Lars Gullik Bjønnes wrote:
| But now, I have an error on the final linking.
| The complete trace is attached.
./configure --disable-pch
This is biting people quite regularly. I think you should disable PCH by
default and enable it only for certain, known to work compilers. Like
yours ;-)
Félix-Antoine Bourbonnais <[EMAIL PROTECTED]> writes:
| > No, that is not the problem. I found it out now: It is again the pollution
| > of the global namespace in qt3 with the signals keyword. The attached
| > patch (including more cleanup) goes in now.
|
| Yes, the WorkArea problem seems to
Georg Baum <[EMAIL PROTECTED]> writes:
| For trunk I propose to update the included boost to 1.34cvs, since boost is
| in freeze and boost 1.34 will probably be released before LyX 1.5.0. Lars
| wanted to do that last month, but then came unicode ;-)
Just give me the "Go!" and I'll update boost
> So there's no compile error for qt4? The bug report seemed to imply
> otherwise... That's why I didn't think that was the reason.
Maybe I was wrong and that two problems were not linked.
--
Félix-Antoine Bourbonnais
http://www.rubico.info/
.
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > | But now, I have an error on the final linking.
| > | The complete trace is attached.
|
| > ./configure --disable-pch
|
| This is biting people quite regularly. I think you should disable PCH
| by default and enable it o
Am Donnerstag, 24. August 2006 21:53 schrieb Abdelrazak Younes:
> So there's no compile error for qt4?
No. gtk works fine, too.
> The bug report seemed to imply
> otherwise...
I don't see that. Maybe it is time to go to bed ;-)
Georg
Hi,
I have a few LFUN-related questions:
* Is LFUN_ERROR_NEXT still needed or can we remove it?
* Does anybody know why we have word-find-backward, word-find-forward,
and word-find (3 instead of 2 functions)?
* What is the purpose of paragraph-move-down and paragraph-move-up?
Thanks in ad
Georg Baum wrote:
Am Donnerstag, 24. August 2006 21:17 schrieb Abdelrazak Younes:
Georg Baum wrote:
Abdel, this problem in trunk appeared after your last commit:
http://bugzilla.lyx.org/show_bug.cgi?id=2792
I see it, too (with gcc 3.3.5 and 4.1, external boost 1.34cvs). Any
idea
what goes wr
Am Donnerstag, 24. August 2006 21:17 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > Abdel, this problem in trunk appeared after your last commit:
> > http://bugzilla.lyx.org/show_bug.cgi?id=2792
> > I see it, too (with gcc 3.3.5 and 4.1, external boost 1.34cvs). Any
idea
> > what goes wrong?
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
Enrico Forestieri wrote:
I think this not a big deal, but LyX/Qt4 is not really Qt3Support free
;-)
On my system it really is... Grepping for Q3 and Qt3 gives absolutely
nothing:
Enrico is right, it is not. Grep the build
Georg Baum wrote:
Abdel, this problem in trunk appeared after your last commit:
http://bugzilla.lyx.org/show_bug.cgi?id=2792
I see it, too (with gcc 3.3.5 and 4.1, external boost 1.34cvs). Any idea
what goes wrong?
Maybe a header include is missing, could you try to add this to WorkArea.h:
#i
Georg Baum wrote:
Abdel, this problem in trunk appeared after your last commit:
http://bugzilla.lyx.org/show_bug.cgi?id=2792
I see it, too (with gcc 3.3.5 and 4.1, external boost 1.34cvs). Any idea
what goes wrong?
I guess it's related to WorkArea now deriving from
boost::signals::trackable a
Georg Baum wrote:
Abdelrazak Younes wrote:
Enrico Forestieri wrote:
I think this not a big deal, but LyX/Qt4 is not really Qt3Support free
;-)
On my system it really is... Grepping for Q3 and Qt3 gives absolutely
nothing:
Enrico is right, it is not. Grep the build dir, and you will see it.
Abdel, this problem in trunk appeared after your last commit:
http://bugzilla.lyx.org/show_bug.cgi?id=2792
I see it, too (with gcc 3.3.5 and 4.1, external boost 1.34cvs). Any idea
what goes wrong?
Georg
Am Donnerstag, 24. August 2006 18:08 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> >> I do not think we should skip braces and spaces depending on what
> >> LyX outputs.
>
> Georg> Why not? My goal was to translate all spaces in such a way that
> Geo
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
You may be right indeed. But it seems that updateLayoutChoice
does a setLayout. Is it necessary to do another one?
Maybe not. Actually it may well be that the
Buffer
Hi all,
I found this link in Linux Weekly News:
Designing a book with LyX -
http://software.newsforge.com/article.pl?sid=06/08/15/1859251
It should be interesting to add to wiki. It is a good promotion of LyX's
abilities. :-)
Thanks to the authors for the text.
--
José Abílio
Enrico Forestieri wrote:
I have compiled a Cygwin version of LyX/Qt4 using the native GUI (no X11)
and now I see the chinese characters mentioned by Abdel when I load
an old document. I also get a lot of messages on the console:
Error returned from iconv
EILSEQ An invalid multibyte sequence has
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
>> Indeed and I am absolutely sure that the .h generated from .ui in
>> my system are completely free of Q3support.
Abdelrazak> I am absolutely sure that I was wrong!
After looking at the so
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> I do not think we should skip braces and spaces depending on what
>> LyX outputs.
Georg> Why not? My goal was to translate all spaces in such a way that
Georg> the resulting DVI of the original .tex file and that of the
Georg> generated
I have compiled a Cygwin version of LyX/Qt4 using the native GUI (no X11)
and now I see the chinese characters mentioned by Abdel when I load
an old document. I also get a lot of messages on the console:
Error returned from iconv
EILSEQ An invalid multibyte sequence has been encountered in the inp
Enrico Forestieri <[EMAIL PROTECTED]> writes:
| I think this not a big deal, but LyX/Qt4 is not really Qt3Support free ;-)
Actually it seems that it is...
could also be that we should change to the qt4 resource stuff...
perhaps that is why we get the qt3 header in the .ui->.h file.
--
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> This patch fixes bug 2786: tex2lyx does not know any of the
> Georg> spaces supported by InsetSpace except ~. The attached LyX file
> Georg> shows that the roundtrip LyX-> LaTeX->LyX->LaT
Abdelrazak Younes wrote:
Angus Leeming wrote:
Abdelrazak Younes wrote:
Maybe the ui files have something specific to qt3?
Maybe... I don't know if my local Qt4 was compiled with
-no-qt3support, I guess not.
Maybe the .ui -> .[hC] generator has a -no-qt3support flag that you
aren't using?
Enrico Forestieri wrote:
On Thu, Aug 24, 2006 at 04:47:25PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
[...]
I think this not a big deal, but LyX/Qt4 is not really Qt3Support free ;-)
On my system it really is... Grepping for Q3 and Qt3 gives absolutely
nothing:
[EMAIL PROTEC
Angus Leeming wrote:
Abdelrazak Younes wrote:
Maybe the ui files have something specific to qt3?
Maybe... I don't know if my local Qt4 was compiled with
-no-qt3support, I guess not.
Maybe the .ui -> .[hC] generator has a -no-qt3support flag that you
aren't using? It would be strange to be
Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
>> I think this not a big deal, but LyX/Qt4 is not really Qt3Support free
>> ;-)
>
> On my system it really is... Grepping for Q3 and Qt3 gives absolutely
> nothing:
Enrico is right, it is not. Grep the build dir, and you will see it. For
examp
On Thu, Aug 24, 2006 at 04:47:25PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
[...]
> > I think this not a big deal, but LyX/Qt4 is not really Qt3Support free ;-)
>
> On my system it really is... Grepping for Q3 and Qt3 gives absolutely
> nothing:
>
> [EMAIL PROTECTED] /cygdrive
Enrico Forestieri wrote:
On Thu, Aug 24, 2006 at 04:28:04PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
[...]
In the meantime I simply copied the Qt3Support header files to
the installation dir and reissued "make". Compilation is going
on smoothly until now.
Ah... then it was a
On Thu, Aug 24, 2006 at 04:28:04PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
[...]
> > In the meantime I simply copied the Qt3Support header files to
> > the installation dir and reissued "make". Compilation is going
> > on smoothly until now.
>
> Ah... then it was a Qt4 installa
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> That's because I created it :-). It was cut&paste from the
Abdelrazak> second part of the former BufferView::pimpl::setBuffer().
So it is not that I am getting old, then.
JMarc
Abdelrazak Younes wrote:
Maybe the ui files have something specific to qt3?
Maybe... I don't know if my local Qt4 was compiled with -no-qt3support,
I guess not.
Maybe the .ui -> .[hC] generator has a -no-qt3support flag that you
aren't using? It would be strange to be able to compile the Qt
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
You may be right indeed. But it seems that updateLayoutChoice
does a setLayout. Is it necessary to do another one?
Maybe not. Actually it may well be that the
Buffer
Enrico Forestieri wrote:
On Thu, Aug 24, 2006 at 04:04:25PM +0200, Abdelrazak Younes wrote:
Does it suffice that I manually copy the Qt3Support files (which are
present in the the qt4 build dir, but do not get installed) to the
qt4 installation dir, or should I enable support for qt3 when build
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
You may be right indeed. But it seems that updateLayoutChoice
does a setLayout. Is it necessary to do another one?
>>> Maybe not. Actually it may well be that the
>>> BufferView::Pim
On Thu, Aug 24, 2006 at 04:04:25PM +0200, Abdelrazak Younes wrote:
> > Does it suffice that I manually copy the Qt3Support files (which are
> > present in the the qt4 build dir, but do not get installed) to the
> > qt4 installation dir, or should I enable support for qt3 when building qt4?
>
> No
Abdelrazak Younes wrote:
You may be right indeed. But it seems that updateLayoutChoice does a
setLayout. Is it necessary to do another one?
Maybe not. Actually it may well be that the
BufferView::Pimpl::firstLayout() method can go altogether.
updateLayoutChoice() will set the layout that matc
Enrico Forestieri wrote:
I tried building qt4 with -no-qt3support, but when trying to build LyX
compilation fails as follows:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-DQ_CYGWIN_WIN -I../../../../s
On Thu, Aug 24, 2006 at 03:41:20PM +0200, Lars Gullik Bjønnes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
[...]
> | A quick check reveals that Qt3Support is seemingly still needed for
> | compiling LyX:
> |
> | $ grep -rl Qt3Support build/src/frontends/qt4
> | src/frontends/qt4/ui/Bibl
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
| > Abdelrazak Younes wrote:
| >>> I don't really get why you need a signal. Why can't a
| >>> BufferView.message function not call a WorkArea.message function?
| >>> There's a one-to-one corresponden
Angus Leeming wrote:
Abdelrazak Younes wrote:
So I'd rather do the other way around and switch back to function
calls if it turns out to be too heavy (which I don't think it will ;-)).
Agreed?
You're doing the work. I can only give you the "benefit" of my
advice. Either way, it's not a big
Enrico Forestieri <[EMAIL PROTECTED]> writes:
| I tried building qt4 with -no-qt3support, but when trying to build LyX
| compilation fails as follows:
|
| g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-D
I tried building qt4 with -no-qt3support, but when trying to build LyX
compilation fails as follows:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-DQ_CYGWIN_WIN -I../../../../src -I../../../../src/fronte
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> This patch fixes bug 2786: tex2lyx does not know any of the
Georg> spaces supported by InsetSpace except ~. The attached LyX file
Georg> shows that the roundtrip LyX-> LaTeX->LyX->LaTeX is perfect.
I do not think we should skip braces
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
| > Abdelrazak Younes wrote:
| >>> I don't really get why you need a signal. Why can't a
| >>> BufferView.message function not call a WorkArea.message function?
| >>> There's a one-to-one correspondence, no?
| >>
| >> For now yes
This patch fixes bug 2786: tex2lyx does not know any of the spaces supported
by InsetSpace except ~. The attached LyX file shows that the roundtrip
LyX->LaTeX->LyX->LaTeX is perfect.
This goes in tonight unless somebody objects. Jean-Marc, also for 1.4.3?
Georg
insetspace-test.lyx
Description:
Abdelrazak Younes wrote:
So I'd rather do the other way around and switch back to function calls
if it turns out to be too heavy (which I don't think it will ;-)).
Agreed?
You're doing the work. I can only give you the "benefit" of my
advice. Either way, it's not a big deal.
Angus
Angus Leeming wrote:
Abdelrazak Younes wrote:
I don't really get why you need a signal. Why can't a
BufferView.message function not call a WorkArea.message function?
There's a one-to-one correspondence, no?
For now yes but I can very well imagine multiple WorkArea using the
same BufferView.
Abdelrazak Younes wrote:
I don't really get why you need a signal. Why can't a
BufferView.message function not call a WorkArea.message function?
There's a one-to-one correspondence, no?
For now yes but I can very well imagine multiple WorkArea using the same
BufferView.
Use-case: a teacher
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
When creating a new document, I see: Trying to select non existent
layout type Standard
This is because LyXView::setBuffer sets the layou
Angus Leeming wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
The following messages are really Buffer dependant and not BufferView
dependant and should stay so IMHO:
lyx_cb.C(289): bv_.buffer()->message(_("Autosave failed!"));
lyx_cb.C(316): bv->buffer()->message(_("Autosaving curre
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
The following messages are really Buffer dependant and not BufferView
dependant and should stay so IMHO:
lyx_cb.C(289): bv_.buffer()->message(_("Autosave failed!"));
lyx_cb.C(316): bv->buffer()->message(_("Autosaving current
document..."));
l
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
When creating a new document, I see: Trying to select non existent
layout type Standard
This is because LyXView::setBuffer sets the layout before updating
layout l
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>> When creating a new document, I see: Trying to select non existent
>> layout type Standard
>>
>> This is because LyXView::setBuffer sets the layout before updating
>> layout list.
>>
>>
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> This is because LyXView::setBuffer sets the layout before updating
>> layout list.
>>
>> Abdel, is the following patch OK?
Abdelrazak> This seems fine.
OK, I applied it.
JMarc
Jean-Marc Lasgouttes wrote:
When creating a new document, I see:
Trying to select non existent layout type Standard
This is because LyXView::setBuffer sets the layout before updating
layout list.
Abdel, is the following patch OK?
Hum I atalked too fast, sorry.
updateLayoutChoice() is doing d
Jean-Marc Lasgouttes wrote:
When creating a new document, I see:
Trying to select non existent layout type Standard
This is because LyXView::setBuffer sets the layout before updating
layout list.
Abdel, is the following patch OK?
This seems fine.
Abdel.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| Lars, OK?
Lars> Yes, why not.
Applied.
JMarc
When creating a new document, I see:
Trying to select non existent layout type Standard
This is because LyXView::setBuffer sets the layout before updating
layout list.
Abdel, is the following patch OK?
JMarc
Index: src/frontends/LyXView.C
===
José Matos wrote:
On Wednesday 23 August 2006 23:17, Abdelrazak Younes wrote:
This patch fixes the crash caused by loading the attached empty
corrupted document.
Comments?
The patch looks sane but the lyx file is empty. :-)
Year, an empty document that crashed lyx...
Abdel.
On Wednesday 23 August 2006 23:17, Abdelrazak Younes wrote:
> This patch fixes the crash caused by loading the attached empty
> corrupted document.
>
> Comments?
The patch looks sane but the lyx file is empty. :-)
> Abdel.
--
José Abílio
Abdelrazak Younes wrote:
This patch fixes the crash caused by loading the attached empty
corrupted document.
Committed.
Abdelrazak Younes wrote:
The following messages are really Buffer dependant and not BufferView
dependant and should stay so IMHO:
lyx_cb.C(289): bv_.buffer()->message(_("Autosave failed!"));
lyx_cb.C(316): bv->buffer()->message(_("Autosaving current document..."));
lyx_cb.C(442): bv->buffer()->
Abdelrazak Younes wrote:
Angus Leeming wrote:
Abdelrazak Younes wrote:
Hello,
The subject says it all. This patch is obviously the right thing to
do so I will commit soon.
Is it really the right thing to do? Imagine that you have multiple
bufferviews on a buffer. If you perform some action
71 matches
Mail list logo
