Angus Leeming wrote:
Milton Woods wrote:
Greetings,
I have attempted to compile LyX version 1.3.3 (with xforms-1.0) on a
fresh install of the latest release of Cygwin (1.5.5-1) and gcc
(3.3.1-2). The configure script runs without a hitch (with the flag
--with-extra-lib=/usr/local/lib:/usr/bin)
On Mon, Oct 13, 2003 at 02:34:45AM +0200, Lars Gullik Bj?nnes wrote:
> | What do you mean ?
>
> Actuall compiler messages.
I'll back out my patch when the box is next up and I have some time and
post the messages for you.
regards
john
--
Khendon's Law:
If the same point is made twice by the s
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 02:23:43AM +0200, Lars Gullik Bj?nnes wrote:
>
>> | Feel free. You note I didn't apply the patch.
>>
>> thanks.
>
| Well, it's up to you, or somebody else ... or it can stay broken. I'm
| not too bothered ...
yeah I have noticed...
On Mon, Oct 13, 2003 at 02:23:43AM +0200, Lars Gullik Bj?nnes wrote:
> | Feel free. You note I didn't apply the patch.
>
> thanks.
Well, it's up to you, or somebody else ... or it can stay broken. I'm
not too bothered ...
> | It was ambiguous overloads in the first place
>
> What then?
What d
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 12:01:18AM +0200, Lars Gullik Bj?nnes wrote:
>
>> Ok, you fix the sympthoms. I do not think that this should be fixed
>> with cases, but by using correct types.
>>
>> beginningOfBody should probably return a pos_type.
>
| Feel free.
On Mon, Oct 13, 2003 at 12:01:18AM +0200, Lars Gullik Bj?nnes wrote:
> Ok, you fix the sympthoms. I do not think that this should be fixed
> with cases, but by using correct types.
>
> beginningOfBody should probably return a pos_type.
Feel free. You note I didn't apply the patch.
> using casts
Angus Leeming <[EMAIL PROTECTED]> writes:
| Cached variables are a royal pain in the butt.
>
| Writing explicit copy constructors simply so that we don't copy
| mutable int xo_;
| is a real bore. I'm sure that the author of formulabase.[Ch] would
| agree with me there ;-)
>
| Why don't w
John Levon <[EMAIL PROTECTED]> writes:
| This is what I needed to compile LyX on IA-64
>
| Mostly int != long stuff.
Ok, you fix the sympthoms. I do not think that this should be fixed
with cases, but by using correct types.
beginningOfBody should probably return a pos_type.
using casts with to
Angus Leeming <[EMAIL PROTECTED]> writes:
| Index: src/lyxtext.h
| - InsetOld::RESULT dispatch(FuncRequest const & cmd);
| Does this mean you can remove #include "insets/insetbase.h" from
| lyxtext.h?
I have no idea. Not part of the exercise.
| Index: src/insets/insetbase.h
| +protected:
Cached variables are a royal pain in the butt.
Writing explicit copy constructors simply so that we don't copy
mutable int xo_;
is a real bore. I'm sure that the author of formulabase.[Ch] would
agree with me there ;-)
Why don't we have a CachedVar class template. Something as simple as
I have just committed code that minimizes the use of that nasty
BufferView cache. The only classes left using it are InsetExternal,
InsetFormula, InsetGraphic and InsetInclude that all need to tell the
BufferView that they should be redrawn now that the graphic has been
loaded.
In all cases th
On Sun, Oct 12, 2003 at 08:08:48PM +0300, Martin Vermeer wrote:
> So, again, did anything you wrote earlier in this thread constitute an
> objection to this patch? (If I understood you correctly, no.)
You understand me correctly
john
--
Khendon's Law:
If the same point is made twice by the sam
On Sun, Oct 12, 2003 at 05:27:40PM +0100, John Levon spake thusly:
> On Sun, Oct 12, 2003 at 07:41:21PM +0300, Martin Vermeer wrote:
>
> > Yes, I remember the discussion on that, or rather, about what the End
> > key did/should do.
> >
> > But does this patch make it worse?
>
> No, which is wh
On Sun, Oct 12, 2003 at 07:41:21PM +0300, Martin Vermeer wrote:
> Yes, I remember the discussion on that, or rather, about what the End
> key did/should do.
>
> But does this patch make it worse?
No, which is why I said "then ..."
john
--
Khendon's Law:
If the same point is made twice by the
On Sun, Oct 12, 2003 at 05:06:22PM +0100, John Levon spake thusly:
> On Sun, Oct 12, 2003 at 07:14:39PM +0300, Martin Vermeer wrote:
>
> > Cursor placement problems? Where? Connected to this problem/patch?
>
> That placing the cursor on the end of a line ends up on the next line
> etc.
Yes, I
On Sun, Oct 12, 2003 at 07:14:39PM +0300, Martin Vermeer wrote:
> Cursor placement problems? Where? Connected to this problem/patch?
That placing the cursor on the end of a line ends up on the next line
etc.
> "Assertion triggered in const class LyXFont
> Paragraph::getFontSettings(const Buffer
On Sun, Oct 12, 2003 at 04:35:49PM +0100, John Levon spake thusly:
> On Sun, Oct 12, 2003 at 04:29:41PM +, Angus Leeming wrote:
>
> > >> Okay, the attached patch fixes the reported problem of
> > >> previous-line stetch -- but for footnote only -- and does nothing
> > >> more. (I did change th
On Sun, Oct 12, 2003 at 04:29:41PM +, Angus Leeming wrote:
> >> Okay, the attached patch fixes the reported problem of
> >> previous-line stetch -- but for footnote only -- and does nothing
> >> more. (I did change the name to display() :-) Please test it.
> >
> > Now all you need is to reint
John Levon wrote:
> On Sun, Oct 12, 2003 at 06:13:52PM +0300, Martin Vermeer wrote:
>
>> Okay, the attached patch fixes the reported problem of
>> previous-line stetch -- but for footnote only -- and does nothing
>> more. (I did change the name to display() :-) Please test it.
>
> Now all you ne
On Sun, Oct 12, 2003 at 06:13:52PM +0300, Martin Vermeer wrote:
> Okay, the attached patch fixes the reported problem of previous-line
> stetch -- but for footnote only -- and does nothing more. (I did
> change the name to display() :-) Please test it.
Now all you need is to reintroduce the curso
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
> Why not call breakLineBefore() display() and break the line after too?
> Then there would be no need to fudge the width. The width is needed
> as-is when trying to render a pixmap image on the screen I think...
Okay, the a
On Sun, Oct 12, 2003 at 10:13:55AM +, Angus Leeming wrote:
> Does the compilation actually fail or do you just get warnings? (Just
> interested. On the Dec I just get warnings.)
Failures. There's no max(one_type, different_type) which iis what it is
on 64 bit, etc.
john
--
Khendon's Law:
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
> > 584 InsetOld * inset = pit->getInset(z);
> > 585 if (inset->breakLineBefore()) // bool to be
> > impl
> > 586 // suppress filling of line
> > 587 f
Joao Luis Meloni Assirati wrote:
> What is the best way to compile both lyx-qt and lyx-xforms in the latest
> development version? Is there a way to do this without reconfiguring the
> source code?
Try passing the option --with-frontend="qt xforms" to configure.
Regards, Alfredo
Hello
What is the best way to compile both lyx-qt and lyx-xforms in the latest
development version? Is there a way to do this without reconfiguring the
source code?
Regards,
João.
John Levon wrote:
> Finally :
>
> mv: cannot stat `xfonts/fonts.dir': No such file or directory
> mv: cannot stat `xfonts/fonts.dir.new': No such file or directory
This is something to do with (or close to) the makespres block of code
in lib/configure.
--
Angus
John Levon wrote:
> This is what I needed to compile LyX on IA-64
> Mostly int != long stuff.
Does the compilation actually fail or do you just get warnings? (Just
interested. On the Dec I just get warnings.)
Ok this is a fail. I think we should go back to a template tostr.
Things like this ar
Lars Gullik Bjønnes wrote:
> Please have a look.
I wish you'd get rid of whitespace cruft before asking us to look.,,
Index: po/POTFILES.in
+src/support/path_defines.C
while (true) {
You add it;
I remove it;
}
Could we add a check for whether file.C.in exists before adding
fil
Martin Vermeer wrote:
> On Fri, Oct 10, 2003 at 12:39:44PM +0100, John Levon spake thusly:
>>
>> On Fri, Oct 10, 2003 at 08:57:03AM +, Angus Leeming wrote:
>>
>> > I attach Martin's original patch, 1147 lines. Could people look
>> > it over again in the light of our current experience and co
29 matches
Mail list logo
