On Wed, 7 Mar 2001, Edwin Leuven wrote:
> > Na. We're following a sensible development cycle:
> > implement something with what facilities and manpower we have
> > see some common areas
> > isolate those areas and extract to common support code
> > write all new stuff using that
On Wed, Mar 07, 2001 at 12:09:32PM -0600, Brett Jones wrote:
> Small glitch in the citation dialog: OK/apply not enabled when "text
> after" field is changed. This leads to frustrating work-arounds.
> 1.1.6fix1 on RH 6.2 from rpm
This has been fixed in the CVS.
For the meantime, a simple workar
> > Does the fact that "boost::scoped_ptrs" etc are now appearing
> > everywhere mean that we are now using namespaces officially
> You could but why would you need namespace citation?
Maybe we should have some rules fixed first... like 'no caps' in the names
or how much should go in a namespace
> Na. We're following a sensible development cycle:
> implement something with what facilities and manpower we have
> see some common areas
> isolate those areas and extract to common support code
> write all new stuff using that better idea
> goto 1
>
Alan, just te
Small glitch in the citation dialog: OK/apply not enabled when "text
after" field is changed. This leads to frustrating work-arounds.
1.1.6fix1 on RH 6.2 from rpm
Offtopic comment - I think the project would be well served to change
the default bg color. That pasty beige makes the whole inter
On Wed, 7 Mar 2001, Angus Leeming wrote:
> Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean
> that we are now using namespaces officially and that I can write (for
> example):
>
> namespace frontends {
> namespace citation {
> ...
>
> }
> }
You could but why wo
Does the fact that "boost::scoped_ptrs" etc are now appearing everywhere mean
that we are now using namespaces officially and that I can write (for
example):
namespace frontends {
namespace citation {
...
}
}
?
Angus
On Tue, 6 Mar 2001, Angus Leeming wrote:
> On Tuesday 06 March 2001 16:43, John Levon wrote:
> > I was going to come out against encoding the different file selection
> operations
> > in the controller, but now I'm not so sure. Maybe you're right. And yes, we
> probably
> > should have a controll
Henner Zeller <[EMAIL PROTECTED]> writes:
| HI,
| On 7 Mar 2001, Lars Gullik Bjønnes wrote:
| LGBn| Can you redo this now with current cvs? I belive that most of them
| LGBn| should be fixed now. (I know there are some I did not fix...)
|
| Starting and stopping an empty lyx now causes only 852
HI,
On 7 Mar 2001, Lars Gullik Bjønnes wrote:
LGBn| Can you redo this now with current cvs? I belive that most of them
LGBn| should be fixed now. (I know there are some I did not fix...)
Starting and stopping an empty lyx now causes only 852 Bytes memory leak;
The last thing is interesting: the
> I think that exceptions can help make code better readable and I'd
> suggest using them if possible (since programmers tend to be used to
you mean 'necessary', do you?
> java as well, this is probably not a big proglem).
Java programmers tend to be a problem
* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010307 16:49]:
> > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>
> Baruch> This will provide the needed info that the exit is from an
> Baruch> assert without going through the hoops of using a macro to
> Baruch> provide the line and file.
>
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
Baruch> This will provide the needed info that the exit is from an
Baruch> assert without going through the hoops of using a macro to
Baruch> provide the line and file.
It seems to me that it says "aborted" instead of "segmentation fault"
Henner Zeller <[EMAIL PROTECTED]> writes:
| Hi,
| Sorry if I ask dumb questions. I've seen, that the code is compiled with
| -fno-exceptions. Is this, because some systems/compilers do not yet
| support exceptions well ? I think that exceptions can help make code
| better readable and I'd suggest
* Lars Gullik Bjønnes <[EMAIL PROTECTED]> [010307 16:28]:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | On 7 Mar 2001, Lars Gullik Bjønnes wrote:
> |
> | > Baruch Even <[EMAIL PROTECTED]> writes:
> | >
> | > | Hello,
> | > |
> | > | I believe we should add a printing to the Assert definition
On 06-Mar-2001 John Levon wrote:
> cvs add lib/images/file-open.xpm src/frontends/FileDialog.h
> src/frontends/xforms/FileDialog.C src/frontends/xforms/form_filedialog.*
> src/frontends/xforms/FormFiledialog.* src/frontends/xforms/forms/form_filedialog.fd
> src/frontends/kde/File*
>
> cvs delet
Hi,
Sorry if I ask dumb questions. I've seen, that the code is compiled with
-fno-exceptions. Is this, because some systems/compilers do not yet
support exceptions well ? I think that exceptions can help make code
better readable and I'd suggest using them if possible (since programmers
tend to b
On Wed, 7 Mar 2001, Allan Rae wrote:
> Then JOhn should have provided a backtrace as well which would have shown
> immediately that it was an Assert and where.
>
> Allan. (ARRae)
I didn't see the point in this case, he had to repeat it anyway to check his
fix fixed it.
john
--
"Faced with th
On Wed, 7 Mar 2001, Baruch Even wrote:
> Learning that it was a core dump doesn't help me to understand it.
> Knowing it's an assert that failed will give me more clues to decipher
> the reason.
Then JOhn should have provided a backtrace as well which would have shown
immediately that it was an A
John Levon <[EMAIL PROTECTED]> writes:
| On 7 Mar 2001, Lars Gullik Bjønnes wrote:
|
| > Baruch Even <[EMAIL PROTECTED]> writes:
| >
| > | Hello,
| > |
| > | I believe we should add a printing to the Assert definition so that it
| > | will be obvious when a core dump is caused by some assert,
* Lars Gullik Bjønnes <[EMAIL PROTECTED]> [010307 14:59]:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | Hello,
> |
> | I believe we should add a printing to the Assert definition so that it
> | will be obvious when a core dump is caused by some assert, it would be
> | great if it included the
On 7 Mar 2001, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | Hello,
> |
> | I believe we should add a printing to the Assert definition so that it
> | will be obvious when a core dump is caused by some assert, it would be
> | great if it included the line and file o
Baruch Even <[EMAIL PROTECTED]> writes:
| Hello,
|
| I believe we should add a printing to the Assert definition so that it
| will be obvious when a core dump is caused by some assert, it would be
| great if it included the line and file of the assert, and it would be
| best if it printed the as
On Wed, 7 Mar 2001, Baruch Even wrote:
> Hello,
>
> I believe we should add a printing to the Assert definition so that it
> will be obvious when a core dump is caused by some assert, it would be
> great if it included the line and file of the assert, and it would be
> best if it printed the ass
Hello,
I believe we should add a printing to the Assert definition so that it
will be obvious when a core dump is caused by some assert, it would be
great if it included the line and file of the assert, and it would be
best if it printed the assert condition itself, but I do not know how to
achie
This is just an assert I placed that goes off, this means that some
assumption of mine is incorrect.
The assumption is that the callers will destroy all information in the
graphics cache, this is not so apparently.
The quick fix is to destory everything on destruction, Actually this is
done alre
Henner Zeller <[EMAIL PROTECTED]> writes:
| Anyway, I just have a small note: I was curious and looked for memory
| leaks using the LeakTracer by Erwin Andreasen
Can you redo this now with current cvs? I belive that most of them
should be fixed now. (I know there are some I did not fix...)
On 7 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | > | Is this the meaning of the cryptic :
> | > |
> | > | 559 // We cannot use this function here
> | >
> | > nor this.
> |
> | Me neither ! This is in lyxfunc.C, what is the meaning of the
> |
John Levon <[EMAIL PROTECTED]> writes:
| > | Is this the meaning of the cryptic :
| > |
| > | 559 // We cannot use this function here
| >
| > nor this.
|
| Me neither ! This is in lyxfunc.C, what is the meaning of the
| > | comment ?
if getStatus(...) & Disable is true then the ly
On 6 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | Pressing any normal key for entering text gives lyxfunc::getStatus() fits
> | setting the minibuffer to "unknown action".
>
> I can't grok this.
Try typing a space twice, and try reading the helpful messag
John Levon <[EMAIL PROTECTED]> writes:
| Pressing any normal key for entering text gives lyxfunc::getStatus() fits
| setting the minibuffer to "unknown action".
I can't grok this.
|
|
| WorkArea: Key is `s' [115]
| WorkArea: Keysym is `s' [115]
| Workarea Diff: 2441
| KeySym is s[115] State is
Edwin Leuven <[EMAIL PROTECTED]> writes:
| ps. Lars: in case you think that it is a good idea, perhaps you give
| me write
| access to www-devel so I can stop bugging john who usually does this
| for me :)
Perhaps I should do that... :-)
Lgb
On Tue, 6 Mar 2001 [EMAIL PROTECTED] wrote:
> On Tue, 6 Mar 2001, John Levon wrote:
> > Why do we have this ? It seems a bit ad hoc. Is it just for
> > the convenience of the doc writers or something ?
>
> Put on your asbestos suit!
/me steps backwards slowly
;)
john
--
"We might be in for
On Tue, Mar 06, 2001 at 01:17:25PM -0800, [EMAIL PROTECTED] wrote:
...
> Date: Tue, 6 Mar 2001 13:17:25 -0800 (PST)
> From: <[EMAIL PROTECTED]>
> X-Sender: <[EMAIL PROTECTED]>
> To: LyX Developer List <[EMAIL PROTECTED]>
> Subject: Re: Menu Separator aka lyxarrow
> In-Reply-To: <[EMAIL PROTECTED]
On Mon, 5 Mar 2001, Angus Leeming wrote:
> > Please enlighten me why you think you have to implement it the way you
> > suggest.
>
> Ok, here goes. If I leave out the all important line in
> ButtonController::input():
>
> if (ButtonPolicy::SMI_NOOP == in) return;
>
> then the up,down,add,de
On 06-Mar-2001 Edwin Leuven wrote:
> Perhaps I should just keep my big mouth shut.
Why I think you're principally right! But think of this in developement.
While a tree is in development a lot of internal changes happen and noone
is using all of the frontends just the default frontend. Maybe on
36 matches
Mail list logo
