> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
>> And the users directory exists?
Joost> That makes no difference, it doesn't work in both cases. LyX
Joost> automatically creates the users directory for me.
Joost> I expect it to run configure, but it won't do so unless I put
Joost> s
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> (BTW, can win/auto-view go in?)
We are getting closer, I think. I still have to find time to make up
my mind about non/auto/"".
Patience ;)
JMarc
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Yes. I simply put the lastopenedfiles to the command line. That
Bo> was the easiest solution.
OK, here is the good solution. We need first a cleanup patch: if you
look at lyx_gui::start, you will find it is in 4 parts in all
frontends
1. crea
Jean-Marc Lasgouttes wrote:
> Juergen, if seems to me that the following code
> +void InsetInclude::updateBibfilesCache(Buffer const & buffer)
> +{
> + if (loadIfNeeded(buffer, params_)) {
> [...]
> + }
> +}
> +
> +std::vector const &
> +InsetInclude::getBibfilesCache(Buff
Abdelrazak Younes wrote:
Sorry, I don't have the time to review the patch but if you say you have
tested it and it works I trust you :-)
i of course tested it and found no issues (not that i am infallible
though... ;-)
it is in. thanks
ed.
On Thu, 04 May 2006 08:55:03 +0200
Georg Baum <[EMAIL PROTECTED]> wrote:
> Abdelrazak Younes wrote:
>
> > Bo Peng a écrit :
> >> What do you think?
> >
> > Great Job!
> > I am convinced and I will certainly use with minimal capability
> > (building LyX is enough).
>
> I fear you both underestim
[EMAIL PROTECTED] wrote:
> The problem is that building on a multiplatform (win32 + OSX etc... ) is a
> pain with autotools. With scons, you just have to install python and scons
> and thats it. You build your project with only one command, on every
> platform, and better with the same SConstruct
Abdelrazak Younes wrote:
// more tricky?
QLyXKeySym.C:#include
Maybe not.
the attached works for me
Index: src/frontends/qt4/QLyXKeySym.C
===
--- src/frontends/qt4/QLyXKeySym.C (revision 13796)
+++ src/frontends/qt4/QLyXKe
Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
>> Juergen, if seems to me that the following code
>> +void InsetInclude::updateBibfilesCache(Buffer const & buffer)
>> +{
>> + if (loadIfNeeded(buffer, params_)) {
>> [...]
>> + }
>> +}
>> +
>> +std::vector const &
>> +InsetInclude
Georg Baum a écrit :
Abdelrazak Younes wrote:
Bo Peng a écrit :
What do you think?
Great Job!
I am convinced and I will certainly use with minimal capability
(building LyX is enough).
I fear you both underestimate the amount of work that is needed to replace
the auto stuff. After all, there
Georg Baum a écrit :
Abdelrazak Younes wrote:
The way I am using QPixmap and QImage is probably not very optimal on
X11 when the server and the client is on the same machine but it should
be very efficient when they are not.
I don't think so. AFAIK the X server and client can use shared memor
Edwin Leuven a écrit :
Abdelrazak Younes wrote:
// more tricky?
QLyXKeySym.C:#include
Maybe not.
the attached works for me
[...]
- Q3CString tmpstr = codec->fromUnicode(str);
- char const * tmpcstr = tmpstr;
+ char const * tmpcstr = codec->fromUnicode(str).data();
May
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Edwin> the attached works for me
Edwin> -Q3CString tmpstr = codec->fromUnicode(str);
Edwin> -char const * tmpcstr = tmpstr;
Edwin> +char const * tmpcstr = codec->fromUnicode(str).data();
Abdel> Maybe:
Abdel> return codec->fromU
On Wed, 2006-05-03 at 22:05 +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | The attached was posted on bugzilla to fix the problem when people press
> | Enter before or after an inset (inside float) in the hope of getting a
> | caption in the right place. It is
Abdelrazak Younes wrote:
> Georg Baum a écrit :
>> I fear you both underestimate the amount of work that is needed to
>> replace the auto stuff. After all, there is a reson why it is so
>> complicated.
>
> I don't think we underestimate it.
So you are willing to work on nothing else for the next
Martin Vermeer wrote:
> If no objection, this goes in presently. Should not have any functional
> effects at present, with insetcaption disabled...
Note that you can opeen a file that contains an InsetCaption just fine, so
it is not entirely disabled.
Why is the mutable label needed?
Georg
Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Edwin> the attached works for me
Edwin> - Q3CString tmpstr = codec->fromUnicode(str);
Edwin> - char const * tmpcstr = tmpstr;
Edwin> + char const * tmpcstr = codec->fromUnicode(str).data();
Abdel> Maybe:
Abdel>
On Thu, 2006-05-04 at 11:24 +0200, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > If no objection, this goes in presently. Should not have any functional
> > effects at present, with insetcaption disabled...
>
> Note that you can opeen a file that contains an InsetCaption just fine, so
> it is n
Jean-Marc Lasgouttes wrote:
Is python available when you run LyX? It should be in the path at the
first run, I guess. If you added it to extra_path in lyxrc.dist, then
the fix would be to load lyxrc.dist before trying to reconfigure.
Does this make sense?
Python is available and has been add
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:
Joost> Python is available and has been added to path_prefix in
Joost> lyxrc.dist. What is the difference between path_prefix and
Joost> extra_path?
I meant path_prefix. The problem was that reconfiguration was done
before readong lyxrc.d
Georg Baum a écrit :
Abdelrazak Younes wrote:
Georg Baum a écrit :
I fear you both underestimate the amount of work that is needed to
replace the auto stuff. After all, there is a reson why it is so
complicated.
I don't think we underestimate it.
So you are willing to work on nothing else f
Martin Vermeer wrote:
> On Thu, 2006-05-04 at 11:24 +0200, Georg Baum wrote:
>> Why is the mutable label needed?
>
> Because it complains otherwise:
OK, I did not really ask what I wanted to know. Second try: Why do you need
to set the label in draw()? Why not set it in read() and whenever the
c
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Georg> I don't think I overestimate the number of files
Georg> that get added. I agree that it is not big, but:
Georg> If you have two lists to maintain this will either
Georg> not happen (again: look at development/Win32/lyx.vcproj),
Abdel> This one i
1. could become lyx_gui::create_view
2. can go back to lyx_main.C
3. can remain in lyx_gui::start
4. can go back to lyx_main.C
This will clean up the code, and then allow you to do session stuff
properly on top of that (and even to make it work for xforms and gtk).
Is that a plan?
I was do
Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Georg> I don't think I overestimate the number of files
Georg> that get added. I agree that it is not big, but:
Georg> If you have two lists to maintain this will either
Georg> not happen (again: look at development/Win32/lyx.v
Following my config.h analysis, this patch gets rid of
I am ready to do more of this but I would like to know first if this
kind of patch will be accepted.
Abdel.
Index: Bullet.C
===
--- Bullet.C(revision 13796)
+++ Bullet.C
Sorry for the missing title...
Abdelrazak Younes a écrit :
Following my config.h analysis, this patch gets rid of
in Bullet.C
I am ready to do more of this but I would like to know first if this
kind of patch will be accepted.
Abdel.
-
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> ...
Angus> It would be a useful exercise to create a list
Angus> of all the #defines that are actually used by LyX
Angus> (and Boost which #includes our config.h ...) and
Angus> see how to test for these things and generate a config.h
Angus> using th
Here is it (it was tedious...):
I think that only .C file in src/support directory should include
"config.h". This is mostly the case for those used macro:
Good work, Abdel. Now we see how much time we have wasted on that
./configure thing.
The biggest advantage of scons is that we can easily
On Thu, May 04, 2006 at 11:41:55AM +0200, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > On Thu, 2006-05-04 at 11:24 +0200, Georg Baum wrote:
> >> Why is the mutable label needed?
> >
> > Because it complains otherwise:
>
> OK, I did not really ask what I wanted to know. Second try: Why do you
Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
...
Really? They were at some point. Microsoft's equivalent of these POSIX function
(used by MSVS) have an underscore in front of their names.
Maybe in support, I'll check. But IMHO, in support/ is
acceptable.
Abdel>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Following my config.h analysis, this patch gets rid of
> I am ready to do more of this but I would like to know first if this
> kind of patch will be accepted.
The last time we thought about this, we decided that config.h should be
#included in *a
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Maybe in support, I'll check. But IMHO, in support/ is
> acceptable.
I think you shouldn't worry about which files #include . That'll be a
big political battle which you're likely to lose. I think you should ascertain
which preprocessor macros are
Uwe Stöhr wrote:
> That's the same as for SVG-images. But the bitmap looks readable.
> Nervertheless the Imagemagick people are working on a vector graphics
> rendering engine but this is at the moment "far from beeing complete".
> Also Acrobat can't handle WMF. Do you know a program that could
Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Maybe in support, I'll check. But IMHO, in support/ is
acceptable.
I think you shouldn't worry about which files #include . That'll be a
big political battle which you're likely to lose. I think you should ascertain
which p
Bo Peng wrote:
> I will be able to provide a working scons environment for myself
> (Linux) in about a week and post the result here. Abdel and/or Enrico
> can try it on their windows machine and make it work for win/cygwin.
> This will make our *own* lives easier. (If you have run ./configure
> u
I don't have any problem with putting the files in as long as you continue
to update the existing build system when you make changes, but then I am
not the one who decides that.
I can personally promise that (until we decide to remove auto*, which
may never happen). It is not terribly difficult
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Please find attached the updated analysis, recursive this time. There
> are still a whole lot of _unused_ macro.
Of course. Nobody claimed otherwise. However, you're now in a sound position to
go ahead and create a Scons-generated config.h.
Good wo
Bo Peng a écrit :
I don't have any problem with putting the files in as long as you
continue
to update the existing build system when you make changes, but then I am
not the one who decides that.
I can personally promise that (until we decide to remove auto*, which
may never happen). It is not
Hi,
I have just noticed something that made me smile. :-)
All templates and examples that lyx carries are in format 243. That
means
that since nobody complained lyx2lyx is working almost everywhere.
Jean-Marc may I convert the files for 1.4.2? FWIW I will not insist. ;-)
On Thu, May 04, 2006 at 07:29:11AM -0500, Bo Peng wrote:
> I will be able to provide a working scons environment for myself
> (Linux) in about a week and post the result here. Abdel and/or Enrico
> can try it on their windows machine and make it work for win/cygwin.
> This will make our *own* live
On Thu, May 04, 2006 at 03:34:59PM +0100, Jose' Matos wrote:
> Hi,
> I have just noticed something that made me smile. :-)
>
> All templates and examples that lyx carries are in format 243. That
> means
> that since nobody complained lyx2lyx is working almost everywhere.
Except for
I personally never had big problems with auto tools on
Windows.
I guess you have a reasonably quick machine. Looking the results
coming line by line from ./configure has been killing me, especially
when I know many of them are *not* needed.
Even not fully understanding them, I was always able
On Thu, May 04, 2006 at 10:08:28AM -0500, Bo Peng wrote:
> >I personally never had big problems with auto tools on
> Windows.
>
> I guess you have a reasonably quick machine. Looking the results
> coming line by line from ./configure has been killing me, especially
> when I know many of them are *
This patch will get rid of the test on "limit.h"
Any objection?
Abdel.
Index: qt3/moc/pch.h
===
--- qt3/moc/pch.h (revision 13796)
+++ qt3/moc/pch.h (working copy)
@@ -15,9 +15,7 @@
#include
#include
#include
-#i
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdel> This patch will get rid of the test on "limit.h"
No, it gets rid of the test on "limits.h".
Abdel> Any objection?
The question is, is climits defined everywhere even when limits.h is not?
Googling on "climits portability" pulls up this as the
On Tue, May 02, 2006 at 11:56:29PM -0500, Bo Peng wrote:
> >
> >I was able to configure LyX on Cygwin for the official qt3 by simply
> >
> >../configure --with-frontend=qt --with-qt-dir=/usr/lib/qt3 \
> > --with-qt-includes=/usr/include/qt3
> >
>
> Qt is indeed found. However, with this simple co
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Is that a plan?
Bo> I was doing a small trick, and now I need to clean up the whole
Bo> process. :-)
This is the whole point of the development process :)
JMarc
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Following my config.h analysis, this patch gets rid of
>> I am ready to do more of this but I would like to know first if
>> this kind of patch will be accepted.
Angus> The last ti
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> All templates and examples that lyx carries are in format 243.
Jose'> That means that since nobody complained lyx2lyx is working
Jose'> almost everywhere.
Jose'> Jean-Marc may I convert the files for 1.4.2? FWIW I will not
Jose'> i
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This patch will get rid of the test on "limit.h" Any
Abdelrazak> objection?
As Angus pointed out, I think this is not a very good idea.
There are reasons why these tests are there. And there are systems
(*BSD) which
On Thu, May 04, 2006 at 10:05:41AM +0200, Edwin Leuven wrote:
> - Q3CString tmpstr = codec->fromUnicode(str);
> - char const * tmpcstr = tmpstr;
> + char const * tmpcstr = codec->fromUnicode(str).data();
> return tmpcstr[0];
> }
fromUnicode() returns a temporary object that will
On Wed, May 03, 2006 at 03:08:12PM -0500, Bo Peng wrote:
> >Urm... does one need to shout all the time when talking to cmake?
> >
> >Pretty much looks like a argument with a senile FORTRAN compiler.
>
> You have to agree that the following (src/support/SConscript) at least
> looks better:
>
> [..
On Thu, May 04, 2006 at 09:37:49AM +0200, [EMAIL PROTECTED] wrote:
> With scons, you just have to install python and scons and thats it.
> You build your project with only one command, on every platform, and better
> with the same SConstruct file.
> The tweak to diferenciate platform is reduce to
On Wed, May 03, 2006 at 05:41:26PM -0500, Bo Peng wrote:
> Now, the biggest problem of lyx, to my understanding, is the
> portability. Building lyx on windows or cygwin has been a pain (my own
> experience), and this will certainly deter potential contributors and
> users. As lyx grows bigger (e.g.
Whohaey. So 'multiplatform' means 'runs on one Unix flavour (Linux, no
less...) and WinNT'? This is the kind of thing I would use a manual
Makefile for.
I agree with you and my 'multiplatform' does include other platforms.
However, do we ever achieve multiplatform even in this narrowed
definiti
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This patch will get rid of the test on "limit.h" Any
Abdelrazak> objection?
As Angus pointed out, I think this is not a very good idea.
There are reasons why these tests are there. And there
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdel> This patch will get rid of the test on "limit.h"
No, it gets rid of the test on "limits.h".
Yes.
Abdel> Any objection?
The question is, is climits defined everywhere even when limits.h is not?
Googling on "climits por
Abdelrazak Younes wrote:
In any case, IMNSHO, achieving good portability should be done via
_portable_ libraries and via c-ish macro. This is not a job for lyx.
and _not_ via c-ish macro. This is the job of the portable library.
Abdel.
Jean-Marc Lasgouttes wrote:
"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Following my config.h analysis, this patch gets rid of
I am ready to do more of this but I would like to know first if
this kind of patch will be accepted.
Andre Poenitz wrote:
On Thu, May 04, 2006 at 10:05:41AM +0200, Edwin Leuven wrote:
- Q3CString tmpstr = codec->fromUnicode(str);
- char const * tmpcstr = tmpstr;
+ char const * tmpcstr = codec->fromUnicode(str).data();
return tmpcstr[0];
}
fromUnicode() returns a tem
Edwin Leuven wrote:
Andre Poenitz wrote:
On Thu, May 04, 2006 at 10:05:41AM +0200, Edwin Leuven wrote:
-Q3CString tmpstr = codec->fromUnicode(str);
-char const * tmpcstr = tmpstr;
+char const * tmpcstr = codec->fromUnicode(str).data();
return tmpcstr[0];
}
fromUnicode() retu
Abdelrazak Younes wrote:
Andre Poenitz wrote:
fromUnicode() returns a temporary object that will be destoyed at the
end of the full expression. So tmpcstr will be invalid after that.
Accessing tmpcstr[0] after that will cause invalid behaviour (and almost
guaranteed a crash with the Qt4 equival
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
fromUnicode() returns a temporary object that will be destoyed at the
end of the full expression. So tmpcstr will be invalid after that.
Accessing tmpcstr[0] after that will cause invalid behaviour (and
almost
guaranteed a cra
Jean-Marc Lasgouttes writes:
Hello LyXers, under
https://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=9951
you can find the fixed version 2.01 of the windows installer for LyX 1.4.1.
The files are now on ftp.lyx.org, except the three readm files, that
are broken on ber
Bo Peng <[EMAIL PROTECTED]> writes:
> I agree with you and my 'multiplatform' does include other platforms.
> However, do we ever achieve multiplatform even in this narrowed
> definition?
Most definitely YES. LyX runs on every flavour of *nix under the sun (and there
are *lots* of flavours, includ
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Helping the port to Scons is just a side effect. The problem is that
> config.h is not only used for supposed portability but also to pass some
> settings that is used somewhere in the source code. For example, could
> you tell me why every source
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > In any case, IMNSHO, achieving good portability should be done via
> > _portable_ libraries and via c-ish macro. This is not a job for lyx.
> and _not_ via c-ish macro. This is the job of the portable library.
In an ideal world, yes. Please don't
Most definitely YES. LyX runs on every flavour of *nix under
the sun (and there
No, that's not true. "autoconf.sh; configure; make" works flawlessly
on
I have a feeling that we are talking about configure.m4 and
configure.py. It is definitely true that autotools are doing a decent
job
I just tried compiling with that simple configure and it succeeded.
I suggest that you update your cygwin installation to the latest
release as, IMHO, that is your problem.
I guess that is cygwin's problem. I did basically a fresh installation
of 1.5.18.
If you want, I could privately email yo
On Tue, 2 May 2006, Martin Vermeer wrote:
> On Tue, May 02, 2006 at 08:43:01PM +0200, [EMAIL PROTECTED] wrote:
> > On Tue, 2 May 2006, Richard Kleeman wrote:
> >
> > > Martin Vermeer wrote:
> > > > http://linuxcult.com/story/05012006/a_first_look_at_lyx/
> > > >
> > > > A bit thin...
> > > >
>
On Thu, 2006-05-04 at 15:26 +0300, Martin Vermeer wrote:
...
> I propose to just check this in (cannot harm) and take it from there.
>
> - Martin
It's in. Log:
Restore the caption inset to functionality on-screen
* insetcaption.[Ch]
(InsetCaption::draw): draw label wi
Bo Peng wrote:
> I have a feeling that we are talking about configure.m4 and
> configure.py. It is definitely true that autotools are doing a decent
> job now and is actually doing better than scons in some ways. However,
> when we talk about maintainability and extensibility, autotools are
> far
Abdelrazak Younes wrote:
> Perhaps but please look at the actual patch before making a decision. I
> am almost certain that this include is not needed at all. So a simpler
> patch would be to just erase them. "qttableview" in qt3 is some code
> stolen for Qt2 source code, it is not used at all in
74 matches
Mail list logo
