On 09-Mar-2001 Allan Rae wrote:
The canvas abstraction shouldn't be as scary as everyone thinks it is.
That said, I haven't given that much thought because Lars and Asger had
been doing most of the work on that in the old tree.
Oh good ol'times. I remember the joyous cheers (with a beer)
On 09-Mar-2001 Allan Rae wrote:
> The canvas abstraction shouldn't be as scary as everyone thinks it is.
> That said, I haven't given that much thought because Lars and Asger had
> been doing most of the work on that in the old tree.
Oh good ol'times. I remember the joyous cheers (with a beer)
On Thu, 8 Mar 2001, Allan Rae wrote:
(asymptotically) especially once we get started on non-X based systems and
the curses/slang/whatever text system gets going.
Allan you are looking way ahead, I'm really more interested in the here and now.
Specifically, since we have nearly done the first
On Friday 09 March 2001 11:48, John Levon wrote:
What needs to be moved, what needs re-working etc.
I'm really clueless on this (like most things) and would appreciate some
perspective
I think that he's just saying that the first task is to get all GUI-stuff out
of the kernel. It doesn't
On Fri, 9 Mar 2001, Angus Leeming wrote:
I think that he's just saying that the first task is to get all GUI-stuff out
of the kernel. It doesn't really matter if the resultant code causes comments
because we're still on iteration 1 as far as the frontends are concerned
whilst the rest of
On Fri, 9 Mar 2001, John Levon wrote:
On Fri, 9 Mar 2001, Angus Leeming wrote:
I think that he's just saying that the first task is to get all GUI-stuff out
of the kernel. It doesn't really matter if the resultant code causes comments
because we're still on iteration 1 as far as the
On Thu, 8 Mar 2001, Allan Rae wrote:
> (asymptotically) especially once we get started on non-X based systems and
> the curses/slang/whatever text system gets going.
Allan you are looking way ahead, I'm really more interested in the here and now.
Specifically, since we have nearly done the
On Friday 09 March 2001 11:48, John Levon wrote:
> What needs to be moved, what needs re-working etc.
>
> I'm really clueless on this (like most things) and would appreciate some
perspective
I think that he's just saying that the first task is to get all GUI-stuff out
of the kernel. It
On Fri, 9 Mar 2001, Angus Leeming wrote:
> I think that he's just saying that the first task is to get all GUI-stuff out
> of the kernel. It doesn't really matter if the resultant code causes comments
> because we're still on iteration 1 as far as the frontends are concerned
> whilst the rest
On Fri, 9 Mar 2001, John Levon wrote:
> On Fri, 9 Mar 2001, Angus Leeming wrote:
>
> > I think that he's just saying that the first task is to get all GUI-stuff out
> > of the kernel. It doesn't really matter if the resultant code causes comments
> > because we're still on iteration 1 as far as
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 delete
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 controller like
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 tell me
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 better
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
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
> 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
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
Here it is
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 delete lib/images/buffer-open.xpm
On 06-Mar-2001 John Levon wrote:
Well here some comments:
-#\bind "M-f n" "buffer-open"
+#\bind "M-f n" "file-open"
Why did you have to do this? There are some lyx-server scripts using
this command and I really don't see why we should change it's name?
-#\bind
On Tuesday 06 March 2001 12:45, John Levon wrote:
John,
Insert-Insert_File-Ascii_as_lines
results in the error popup:
~/lines
No such file or directory
Similarly for Ascii_as_paragraphs.
File-Open is greyed out. Can't do it.
Everything else seems to work fine.
Angus
On Tue, 6 Mar 2001, Angus Leeming wrote:
John,
Insert-Insert_File-Ascii_as_lines
results in the error popup:
~/lines
No such file or directory
Similarly for Ascii_as_paragraphs.
File-Open is greyed out. Can't do it.
Probably you are using an old bind file in ~/.lyx
On Tue, 6 Mar 2001, Juergen Vigna wrote:
On 06-Mar-2001 John Levon wrote:
Well here some comments:
-#\bind "M-f n" "buffer-open"
+#\bind "M-f n" "file-open"
Why did you have to do this? There are some lyx-server scripts using
this command and I really
On Tuesday 06 March 2001 15:03, John Levon wrote:
On Tue, 6 Mar 2001, Angus Leeming wrote:
John,
Insert-Insert_File-Ascii_as_lines
results in the error popup:
~/lines
No such file or directory
Similarly for Ascii_as_paragraphs.
File-Open is greyed out.
On Tue, 6 Mar 2001, Angus Leeming wrote:
Note though that LyXFunc still launches the fileDialog explicitly, rather
than by emitting a signal in one "case" statement and receiving the result in
another. Is this to stay as it is, or should it be slated for change too? Me,
I'd vote to change
On Tuesday 06 March 2001 15:35, John Levon wrote:
On Tue, 6 Mar 2001, Angus Leeming wrote:
Note though that LyXFunc still launches the fileDialog explicitly,
rather than by emitting a signal in one "case" statement and
receiving the result in another. Is this to stay as it is, or should
On Tue, 6 Mar 2001, Angus Leeming wrote:
In this case, each inset controller has one View only. However, I'm picturing
a very similar scheme for the FileDialogs, but here a single FileDialog
Controller would control multiple Views, one for each NEW_FILE, OPEN_FILE etc
signal emitted by
"John" == John Levon [EMAIL PROTECTED] writes:
John Anyway the "mask" interface needs changing at some point to get
John on well with the KDE frontend.
John The KDE dialog expects something like :
John "*.ps|PostScript documents (*.ps)\n*.png|PNG files (*.png)\n"
John as a list of the
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 controller like that...
I'm not sure if it's the right thing
I'm not sure if it's the right thing to do here either, but Matthias
Ettrich really must have struck a chord with me when he complained about
how much each frontend had to implement. Just chewing the cud here...
Did I mention that a Tk frontend would buy us Mac and Windows users?
Not to
Here it is
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 delete lib/images/buffer-open.xpm
On 06-Mar-2001 John Levon wrote:
Well here some comments:
-#\bind "M-f n" "buffer-open"
+#\bind "M-f n" "file-open"
Why did you have to do this? There are some lyx-server scripts using
this command and I really don't see why we should change it's name?
-#\bind
On Tuesday 06 March 2001 12:45, John Levon wrote:
John,
Insert->Insert_File->Ascii_as_lines
results in the error popup:
~/lines
No such file or directory
Similarly for Ascii_as_paragraphs.
File->Open is greyed out. Can't do it.
Everything else seems to work fine.
Angus
On Tue, 6 Mar 2001, Angus Leeming wrote:
> John,
>
> Insert->Insert_File->Ascii_as_lines
>
> results in the error popup:
>
> ~/lines
> No such file or directory
>
> Similarly for Ascii_as_paragraphs.
>
> File->Open is greyed out. Can't do it.
Probably you are using an old bind
On Tue, 6 Mar 2001, Juergen Vigna wrote:
>
> On 06-Mar-2001 John Levon wrote:
> Well here some comments:
>
> -#\bind "M-f n" "buffer-open"
> +#\bind "M-f n" "file-open"
>
> Why did you have to do this? There are some lyx-server scripts using
> this command and
On Tuesday 06 March 2001 15:03, John Levon wrote:
> On Tue, 6 Mar 2001, Angus Leeming wrote:
>
> > John,
> >
> > Insert->Insert_File->Ascii_as_lines
> >
> > results in the error popup:
> >
> > ~/lines
> > No such file or directory
> >
> > Similarly for Ascii_as_paragraphs.
> >
> >
On Tue, 6 Mar 2001, Angus Leeming wrote:
> Note though that LyXFunc still launches the fileDialog explicitly, rather
> than by emitting a signal in one "case" statement and receiving the result in
> another. Is this to stay as it is, or should it be slated for change too? Me,
> I'd vote to
On Tuesday 06 March 2001 15:35, John Levon wrote:
> On Tue, 6 Mar 2001, Angus Leeming wrote:
>
> > Note though that LyXFunc still launches the fileDialog explicitly,
> > rather than by emitting a signal in one "case" statement and
> > receiving the result in another. Is this to stay as it is, or
On Tue, 6 Mar 2001, Angus Leeming wrote:
> In this case, each inset controller has one View only. However, I'm picturing
> a very similar scheme for the FileDialogs, but here a single FileDialog
> Controller would control multiple Views, one for each NEW_FILE, OPEN_FILE etc
> signal emitted
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> Anyway the "mask" interface needs changing at some point to get
John> on well with the KDE frontend.
John> The KDE dialog expects something like :
John> "*.ps|PostScript documents (*.ps)\n*.png|PNG files (*.png)\n"
John> as a list
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 controller like that...
I'm not sure if it's the right
> I'm not sure if it's the right thing to do here either, but Matthias
> Ettrich really must have struck a chord with me when he complained about
> how much each frontend had to implement. Just chewing the cud here...
Did I mention that a Tk frontend would buy us Mac and Windows users?
Not to
"John" == John Levon [EMAIL PROTECTED] writes:
John Here we go again ...
So, Lars, what should be done about this patch? Shall I apply it?
JMarc
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> Here we go again ...
So, Lars, what should be done about this patch? Shall I apply it?
JMarc
On Monday 26 February 2001 20:06, John Levon wrote:
Here we go again ...
Angus, I have to put in an ed hack into fdfix.sh. Unless you
have bright ideas for a clean way around the problem, now I am avoiding
a patch
Yueuchh! I suppose that this can go in for now, but this has definitely
Angus Leeming [EMAIL PROTECTED] writes:
| Can somebody apply this patch please.
Just make sure that it is uptodate first. (no conflicts with current
cvs).
and repost...
Lgb
On Tue, 27 Feb 2001, Angus Leeming wrote:
On Monday 26 February 2001 20:06, John Levon wrote:
Here we go again ...
Angus, I have to put in an ed hack into fdfix.sh. Unless you
have bright ideas for a clean way around the problem, now I am avoiding
a patch
Yueuchh! I suppose
John Levon [EMAIL PROTECTED] writes:
| thanks
| john
I never got a reason on the "buffer-open" - "file-open" change.
IMO this is a separate issue from the guii of filedlg, and should be
in a separate patch... if done at all.
Lgb
On 27 Feb 2001, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| thanks
| john
I never got a reason on the "buffer-open" - "file-open" change.
How do you expect me to answer questions you haven't asked ?
you REALLY should have mentioned this before I diffed 4 times
John Levon [EMAIL PROTECTED] writes:
| On 27 Feb 2001, Lars Gullik Bjnnes wrote:
|
| John Levon [EMAIL PROTECTED] writes:
|
| | thanks
| | john
|
| I never got a reason on the "buffer-open" - "file-open" change.
|
| How do you expect me to answer questions you haven't asked ?
| you
On 27 Feb 2001, Lars Gullik Bjønnes wrote:
Hmm, that might have been one of the mails denied for "not
authenticated" reasons. but I know that I _wrote_ the mail.
Ah, OK, sorry.
This is then closer to what I wanted in the beginning then (~5 years
ago)
Well you'll find my patches often
On Monday 26 February 2001 20:06, John Levon wrote:
> > Here we go again ...
>
> Angus, I have to put in an ed hack into fdfix.sh. Unless you
> have bright ideas for a clean way around the problem, now I am avoiding
> a patch
Yueuchh! I suppose that this can go in for now, but this has
Angus Leeming <[EMAIL PROTECTED]> writes:
| Can somebody apply this patch please.
Just make sure that it is uptodate first. (no conflicts with current
cvs).
and repost...
Lgb
On Tue, 27 Feb 2001, Angus Leeming wrote:
> On Monday 26 February 2001 20:06, John Levon wrote:
>
> > > Here we go again ...
> >
> > Angus, I have to put in an ed hack into fdfix.sh. Unless you
> > have bright ideas for a clean way around the problem, now I am avoiding
> > a patch
>
>
John Levon <[EMAIL PROTECTED]> writes:
| thanks
| john
I never got a reason on the "buffer-open" -> "file-open" change.
IMO this is a separate issue from the guii of filedlg, and should be
in a separate patch... if done at all.
Lgb
On 27 Feb 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | thanks
> | john
>
> I never got a reason on the "buffer-open" -> "file-open" change.
How do you expect me to answer questions you haven't asked ?
you REALLY should have mentioned this before I diffed 4
John Levon <[EMAIL PROTECTED]> writes:
| On 27 Feb 2001, Lars Gullik Bjønnes wrote:
|
| > John Levon <[EMAIL PROTECTED]> writes:
| >
| > | thanks
| > | john
| >
| > I never got a reason on the "buffer-open" -> "file-open" change.
|
| How do you expect me to answer questions you haven't asked
On 27 Feb 2001, Lars Gullik Bjønnes wrote:
> Hmm, that might have been one of the mails denied for "not
> authenticated" reasons. but I know that I _wrote_ the mail.
Ah, OK, sorry.
> This is then closer to what I wanted in the beginning then (~5 years
> ago)
Well you'll find my patches often
Here we go again ...
Angus, I have to put in an ed hack into fdfix.sh. Unless you
have bright ideas for a clean way around the problem, now I am avoiding
a patch
john
p.s. any reason no one applied cleanups.diff and the mathed/support patch ?
Maybe someone should take a break from flaming ;)
Here we go again ...
Angus, I have to put in an ed hack into fdfix.sh. Unless you
have bright ideas for a clean way around the problem, now I am avoiding
a patch
john
p.s. any reason no one applied cleanups.diff and the mathed/support patch ?
Maybe someone should take a break from flaming ;)
The not-attached patch fixes all sorts of stuff, and GUIIizes
the External form and FileDialog.
One thing of interest is a "fix" for the FL_TRANSIENT stuff.
This *should* ensure that iconified dialogs are brought
back up again - at least it seems a convention that
XMapWindow() has this effect.
Come on, John! This is huge and monstrous! Can't you split it up into
logically independent patches:
* configure stuff
* File dialog
* External dialog
* DO_USE_DEFAULT_LANGUAGE
* etc etc
You might get some feedback then!
Angus
On Friday 23 February 2001 12:46, John Levon wrote:
The
On Fri, 23 Feb 2001, Angus Leeming wrote:
Come on, John! This is huge and monstrous! Can't you split it up into
logically independent patches:
* configure stuff
* File dialog
* External dialog
* DO_USE_DEFAULT_LANGUAGE
* etc etc
You might get some feedback then!
Angus
It was
On 23-Feb-2001 John Levon wrote:
It was half the size last week when it got ignored. I *could* just split it up
but I don't see how that helps, it just makes 10 or so ChangeLog .rej files
the applier has to clean up.
It all has to be reviewed by *someone*. How does splitting it up make it
On Friday 23 February 2001 13:58, John Levon wrote:
On Fri, 23 Feb 2001, Angus Leeming wrote:
Come on, John! This is huge and monstrous! Can't you split it up into
logically independent patches:
* configure stuff
* File dialog
* External dialog
* DO_USE_DEFAULT_LANGUAGE
* etc
On Fri, 23 Feb 2001, Angus Leeming wrote:
For the same reason. It's too much for mere mortals to cope with!
OK, I'll split it now. Thanks.
Well different people know different bits of the code to different levels.
For example, I feel able to comment on the FileDialog stuff which looks like
On 23-Feb-2001 Angus Leeming wrote:
Alternatively, Lars will end up having to look at everything!
Good old Lars ;)
Well I had a (REALLY) fast look at the patch and now I'm more then before
of the same opinion as Angus. There are too much different changes in that
file, to chop with and I
I've split this apart as best I can (luckily I found a
diff I did of FormExternal against this, so I could
back it off with minimum of fuss)
john
--
On Year 2000 compliance :
"Unfortunately, it is not possible to gather similar
assurances on the compliance of viruses."
- Dr.
On Fri, 23 Feb 2001, John Levon wrote:
I've split this apart as best I can (luckily I found a
diff I did of FormExternal against this, so I could
back it off with minimum of fuss)
john
ugh, sorry, malformed patch. try the new attached instead
thanks
john
--
On Year 2000 compliance :
Juergen Vigna [EMAIL PROTECTED] writes:
| As you know we also are pretty specialized f.ex. Jean-Marc does the configure
| stuff normally. So If I see a part which is in my campus I'm fast to review
| it, but if most of the patch is outside and I don't know how to split it
| up I probably will
On 23 Feb 2001, Lars Gullik Bjønnes wrote:
Juergen Vigna [EMAIL PROTECTED] writes:
| As you know we also are pretty specialized f.ex. Jean-Marc does the configure
| stuff normally. So If I see a part which is in my campus I'm fast to review
| it, but if most of the patch is outside and I
This is NOT a get-at-John day (by the way).
The FileDialog stuff will take some digesting. It's huge!
As for the rest:
Index: src/frontends/xforms/FormGraphics.C
- string const pattern = "*(ps|png)";
+ // FIXME: currently we need the second '|' to prevent mis-interpretation
+
On Fri, 23 Feb 2001, Angus Leeming wrote:
This is NOT a get-at-John day (by the way).
awww, that sounds like fun.
The FileDialog stuff will take some digesting. It's huge!
but actually very simple in concept. Literally filedlg.C just got moved.
I suppose I should have left the KDE
On Fri, Feb 23, 2001 at 04:19:03PM +, John Levon wrote:
Index: src/frontends/xforms/FormPreferences.C
+ if (i 0 || (((::Formats::FormatList::size_type)i) =
local_formats.size())) {
I thought we dodn't do C-style casts?
You want me to do a typedef instead ? or is the scope
On Fri, 23 Feb 2001, Dekel Tsur wrote:
On Fri, Feb 23, 2001 at 04:19:03PM +, John Levon wrote:
Index: src/frontends/xforms/FormPreferences.C
+ if (i 0 || (((::Formats::FormatList::size_type)i) =
local_formats.size())) {
I thought we dodn't do C-style casts?
You
On Friday 23 February 2001 16:32, John Levon wrote:
On Fri, 23 Feb 2001, Dekel Tsur wrote:
On Fri, Feb 23, 2001 at 04:19:03PM +, John Levon wrote:
Index: src/frontends/xforms/FormPreferences.C
+ if (i 0 || (((::Formats::FormatList::size_type)i) =
On Fri, 23 Feb 2001, Angus Leeming wrote:
From the xforms manuals (they really are very good):
I didn't have it around at the time of patch, my bad
It returns the number of the current choice (0 if there is no choice).
*sigh* then why didn't they make it unsigned
anyway, Dekel's change is
Continuing on:
This is not acceptable. Patches to .fd files only accepted as a last resort.
This doesn't qualify.
Angus
Index: src/frontends/xforms/forms/form_filedialog.C.patch
===
RCS file: form_filedialog.C.patch
diff -N
On Fri, Feb 23, 2001 at 04:32:32PM +, John Levon wrote:
I thought we dodn't do C-style casts?
You want me to do a typedef instead ? or is the scope resolution
operator allowed in C++ style casts ?
Change the line above to
Formats::FormatList::size_type const i =
On Fri, 23 Feb 2001, Angus Leeming wrote:
Continuing on:
This is not acceptable. Patches to .fd files only accepted as a last resort.
This doesn't qualify.
Angus
ok, whatever
john
--
"Anyone who says you can have a lot of widely dispersed people hack away on
a complicated piece of
The not-attached patch fixes all sorts of stuff, and GUIIizes
the External form and FileDialog.
One thing of interest is a "fix" for the FL_TRANSIENT stuff.
This *should* ensure that iconified dialogs are brought
back up again - at least it seems a convention that
XMapWindow() has this effect.
Come on, John! This is huge and monstrous! Can't you split it up into
logically independent patches:
* configure stuff
* File dialog
* External dialog
* DO_USE_DEFAULT_LANGUAGE
* etc etc
You might get some feedback then!
Angus
On Friday 23 February 2001 12:46, John Levon wrote:
> The
On Fri, 23 Feb 2001, Angus Leeming wrote:
> Come on, John! This is huge and monstrous! Can't you split it up into
> logically independent patches:
>
> * configure stuff
> * File dialog
> * External dialog
> * DO_USE_DEFAULT_LANGUAGE
> * etc etc
>
> You might get some feedback then!
>
> Angus
On 23-Feb-2001 John Levon wrote:
> It was half the size last week when it got ignored. I *could* just split it up
> but I don't see how that helps, it just makes 10 or so ChangeLog .rej files
> the applier has to clean up.
>
> It all has to be reviewed by *someone*. How does splitting it up
On Friday 23 February 2001 13:58, John Levon wrote:
> On Fri, 23 Feb 2001, Angus Leeming wrote:
>
> > Come on, John! This is huge and monstrous! Can't you split it up into
> > logically independent patches:
> >
> > * configure stuff
> > * File dialog
> > * External dialog
> > *
On Fri, 23 Feb 2001, Angus Leeming wrote:
> For the same reason. It's too much for mere mortals to cope with!
OK, I'll split it now. Thanks.
> Well different people know different bits of the code to different levels.
> For example, I feel able to comment on the FileDialog stuff which looks
On 23-Feb-2001 Angus Leeming wrote:
> Alternatively, Lars will end up having to look at everything!
Good old Lars ;)
Well I had a (REALLY) fast look at the patch and now I'm more then before
of the same opinion as Angus. There are too much different changes in that
file, to chop with and I
I've split this apart as best I can (luckily I found a
diff I did of FormExternal against this, so I could
back it off with minimum of fuss)
john
--
On Year 2000 compliance :
"Unfortunately, it is not possible to gather similar
assurances on the compliance of viruses."
- Dr.
On Fri, 23 Feb 2001, John Levon wrote:
>
> I've split this apart as best I can (luckily I found a
> diff I did of FormExternal against this, so I could
> back it off with minimum of fuss)
>
> john
ugh, sorry, malformed patch. try the new attached instead
thanks
john
--
On Year 2000
Juergen Vigna <[EMAIL PROTECTED]> writes:
| As you know we also are pretty specialized f.ex. Jean-Marc does the configure
| stuff normally. So If I see a part which is in my campus I'm fast to review
| it, but if most of the patch is outside and I don't know how to split it
| up I probably will
On 23 Feb 2001, Lars Gullik Bjønnes wrote:
> Juergen Vigna <[EMAIL PROTECTED]> writes:
>
> | As you know we also are pretty specialized f.ex. Jean-Marc does the configure
> | stuff normally. So If I see a part which is in my campus I'm fast to review
> | it, but if most of the patch is outside
This is NOT a get-at-John day (by the way).
The FileDialog stuff will take some digesting. It's huge!
As for the rest:
Index: src/frontends/xforms/FormGraphics.C
- string const pattern = "*(ps|png)";
+ // FIXME: currently we need the second '|' to prevent mis-interpretation
+
On Fri, 23 Feb 2001, Angus Leeming wrote:
> This is NOT a get-at-John day (by the way).
awww, that sounds like fun.
>
> The FileDialog stuff will take some digesting. It's huge!
but actually very simple in concept. Literally filedlg.C just got moved.
I suppose I should have left the KDE
On Fri, Feb 23, 2001 at 04:19:03PM +, John Levon wrote:
> > Index: src/frontends/xforms/FormPreferences.C
> >
> > + if (i < 0 || (((::Formats::FormatList::size_type)i) <=
> > local_formats.size())) {
> >
> > I thought we dodn't do C-style casts?
>
> You want me to do a typedef instead ?
On Fri, 23 Feb 2001, Dekel Tsur wrote:
> On Fri, Feb 23, 2001 at 04:19:03PM +, John Levon wrote:
> > > Index: src/frontends/xforms/FormPreferences.C
> > >
> > > + if (i < 0 || (((::Formats::FormatList::size_type)i) <=
> > > local_formats.size())) {
> > >
> > > I thought we dodn't do
On Friday 23 February 2001 16:32, John Levon wrote:
> On Fri, 23 Feb 2001, Dekel Tsur wrote:
>
> > On Fri, Feb 23, 2001 at 04:19:03PM +, John Levon wrote:
> > > > Index: src/frontends/xforms/FormPreferences.C
> > > >
> > > > + if (i < 0 || (((::Formats::FormatList::size_type)i) <=
>
On Fri, 23 Feb 2001, Angus Leeming wrote:
> >From the xforms manuals (they really are very good):
I didn't have it around at the time of patch, my bad
> It returns the number of the current choice (0 if there is no choice).
*sigh* then why didn't they make it unsigned
anyway, Dekel's change
Continuing on:
This is not acceptable. Patches to .fd files only accepted as a last resort.
This doesn't qualify.
Angus
Index: src/frontends/xforms/forms/form_filedialog.C.patch
===
RCS file: form_filedialog.C.patch
diff -N
On Fri, Feb 23, 2001 at 04:32:32PM +, John Levon wrote:
> > > > I thought we dodn't do C-style casts?
> > >
> > > You want me to do a typedef instead ? or is the scope resolution
> > > operator allowed in C++ style casts ?
> >
> > Change the line above to
> > Formats::FormatList::size_type
On Fri, 23 Feb 2001, Angus Leeming wrote:
> Continuing on:
>
> This is not acceptable. Patches to .fd files only accepted as a last resort.
> This doesn't qualify.
>
> Angus
ok, whatever
john
--
"Anyone who says you can have a lot of widely dispersed people hack away on
a complicated
1 - 100 of 102 matches
Mail list logo
