Re: FormPreferences patch
I've tracked down the reason why I can't use:
string const arg = lcolor.getLyXName(lc) + string(" black");
LyXFunC::Dispatch(LFUN_SET_COLOR, arg);
when I'm editing the colors in FormPreferences and LyX has no document open.
About line 488 of Dispatch, there is the code:
// We cannot use this function here
if (getStatus(ac) Disabled)
goto exit_with_message;
The action is disabled without a buffer and no progress can, therefore be
made.
I have used a work around in FormPreferences:
if buffer exists
use Dispatch,
else
use setColor direct.
Clearly, it would be better to allow the colors to be editted without a
buffer present.
Anyway, I think I have cleaned up the bugs in the colors tab. Will submit
once cvs is working again. Currently it's seems to be taking an age to do
very little.
Angus
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes:
Angus Clearly, it would be better to allow the colors to be editted
Angus without a buffer present.
This is probably an oversight. You can probably change in LyXAction.C
{ LFUN_SET_COLOR, "set-color", "", Noop },
to
{ LFUN_SET_COLOR, "set-color", "", ReadOnly|NoBuffer },
and see whether a problem occurs.
JMarc
Re: FormPreferences patch
Will do.
A
On Friday 17 November 2000 14:21, Jean-Marc Lasgouttes wrote:
"Angus" == Angus Leeming [EMAIL PROTECTED] writes:
Angus Clearly, it would be better to allow the colors to be editted
Angus without a buffer present.
This is probably an oversight. You can probably change in LyXAction.C
{ LFUN_SET_COLOR, "set-color", "", Noop },
to
{ LFUN_SET_COLOR, "set-color", "", ReadOnly|NoBuffer },
and see whether a problem occurs.
JMarc
Re: FormPreferences patch
On Wed, Nov 15, 2000 at 05:39:12PM +0100, Lars Gullik Bjønnes wrote: Note also, that a writeable file need not yet exist but the directory should be writeable. Allan wrote them because he wanted the feedback for the "idiot user". I We don't have idiot users. But we may in the future! When we take over the world, some of the people forced to use LyX since it's the only software available will be stupid. As the current situation in Florida proves (and I'm sure you foreigners can't wait to make fun of us for this), we Americans hold sacred the right to be stupid. -Amir
Re: FormPreferences patch
I've tracked down the reason why I can't use:
string const arg = lcolor.getLyXName(lc) + string(" black");
LyXFunC::Dispatch(LFUN_SET_COLOR, arg);
when I'm editing the colors in FormPreferences and LyX has no document open.
About line 488 of Dispatch, there is the code:
// We cannot use this function here
if (getStatus(ac) & Disabled)
goto exit_with_message;
The action is disabled without a buffer and no progress can, therefore be
made.
I have used a work around in FormPreferences:
if buffer exists
use Dispatch,
else
use setColor direct.
Clearly, it would be better to allow the colors to be editted without a
buffer present.
Anyway, I think I have cleaned up the bugs in the colors tab. Will submit
once cvs is working again. Currently it's seems to be taking an age to do
very little.
Angus
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Clearly, it would be better to allow the colors to be editted
Angus> without a buffer present.
This is probably an oversight. You can probably change in LyXAction.C
{ LFUN_SET_COLOR, "set-color", "", Noop },
to
{ LFUN_SET_COLOR, "set-color", "", ReadOnly|NoBuffer },
and see whether a problem occurs.
JMarc
Re: FormPreferences patch
Will do.
A
On Friday 17 November 2000 14:21, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Clearly, it would be better to allow the colors to be editted
> Angus> without a buffer present.
>
> This is probably an oversight. You can probably change in LyXAction.C
> { LFUN_SET_COLOR, "set-color", "", Noop },
> to
> { LFUN_SET_COLOR, "set-color", "", ReadOnly|NoBuffer },
> and see whether a problem occurs.
>
> JMarc
Re: FormPreferences patch
On Wed, Nov 15, 2000 at 05:39:12PM +0100, Lars Gullik Bjønnes wrote: > > > Note also, that a writeable file need not yet exist but the directory > > should be writeable. Allan wrote them because he wanted the feedback > > for the "idiot > user". I > > We don't have idiot users. But we may in the future! When we take over the world, some of the people forced to use LyX since it's the only software available will be stupid. As the current situation in Florida proves (and I'm sure you foreigners can't wait to make fun of us for this), we Americans hold sacred the right to be stupid. -Amir
Re: FormPreferences patch
Two patches attached. patch1 is very small. Just a couple of tiny things. patch2 continues the FormPreferences clean up, but it also allows you to change the LyX LColors. A couple of bugs remain, but I'd be grateful of some help/advice. See the ChangeLog entry. Finally, a useability question. Should I try and sort the X11 names in the browser. Not a straight alphabetical sort, but into a "rainbow" sort so that all names containing "red" ane grouped together, then those containing "orange" etc. What do people think? Anyway, have a play. I think you'll like it. Angus patch1.bz2 patch2.bz2
Re: FormPreferences patch
Angus Leeming [EMAIL PROTECTED] writes: | browser. Not a straight alphabetical sort, but into a "rainbow" sort so that | all names containing "red" ane grouped together, then those containing | "orange" etc. What do people think? Why not sort on rgb numbers? and also remove "indian red" if "IndianRed" exists and have the same rgb value. Howto map rgb number to rainbow numbers? (wavelength?) Is a color cube transformation needed? You probably need to handle grey values separately. Lgb
Re: FormPreferences patch
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Why not sort on rgb numbers? and also remove "indian red" if Lars "IndianRed" exists and have the same rgb value. How do you know which one should be removed? JMarc
Re: FormPreferences patch
On Wed, 15 Nov 2000, Angus Leeming wrote: Two patches attached. patch1 is very small. Just a couple of tiny things. patch2 continues the FormPreferences clean up, but it also allows you to change the LyX LColors. A couple of bugs remain, but I'd be grateful of some help/advice. See the ChangeLog entry. Finally, a useability question. Should I try and sort the X11 names in the browser. Not a straight alphabetical sort, but into a "rainbow" sort so that all names containing "red" ane grouped together, then those containing "orange" etc. What do people think? Anyway, have a play. I think you'll like it. Angus + Moved class xformColor to files xform_helpers.[Ch]. These files, + Color.[Ch], could now be moved into src if they would be useful to + other GUIs. For KDE, QColor can handle both HSV, RGB, and named X colours, so it wouldn't be useful AFAICS. john
Re: FormPreferences patch
Angus Leeming [EMAIL PROTECTED] writes: | patch2 continues the FormPreferences clean up, but Why do we want to have: int IsDirWriteable (string const path); bool IsFileReadable (string const path); int IsFileWriteable (string const path); _and_ (WriteableDir, ReadableDir, WriteableFile, ReadableFile) i.e. which(?) of them should go? Lgb
Re: FormPreferences patch
good question! Note that the new functions are more sophisticated than the old ones. In particular, they can tell you WHY the dir/file isn't read/writeable. Note also, that a writeable file need not yet exist but the directory should be writeable. Allan wrote them because he wanted the feedback for the "idiot user". I modified them so that they worked ;-) and then thought that they'd be useful to other GUI's. They're certainly useful to other xforms dialogs, so they should at least be put in xform_helpers.[Ch] rather than just in FormPreferences. As you can see, I'm not sure whether they should replace the existing functions! Angus On Wednesday 15 November 2000 16:18, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | patch2 continues the FormPreferences clean up, but Why do we want to have: int IsDirWriteable (string const path); bool IsFileReadable (string const path); int IsFileWriteable (string const path); _and_ (WriteableDir, ReadableDir, WriteableFile, ReadableFile) i.e. which(?) of them should go? Lgb
Re: FormPreferences patch
Angus Leeming [EMAIL PROTECTED] writes:
| Note that the new functions are more sophisticated than the old ones. In
| particular, they can tell you WHY the dir/file isn't read/writeable.
I feel that this is a bit too much of hand holding. And they are not
core support functions... I'd say move them to frontends.
(I'd really hate to see code like:
string dummy;
if (ReadableFile(file, dummy)) { ... } )
| Note also, that a writeable file need not yet exist but the directory should
| be writeable.
|
| Allan wrote them because he wanted the feedback for the "idiot
| user". I
We don't have idiot users.
Lgb
Re: FormPreferences patch
On Wednesday 15 November 2000 16:39, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Note that the new functions are more sophisticated than the old ones. In
| particular, they can tell you WHY the dir/file isn't read/writeable.
I feel that this is a bit too much of hand holding. And they are not
core support functions... I'd say move them to frontends.
(I'd really hate to see code like:
string dummy;
if (ReadableFile(file, dummy)) { ... } )
well we could easily overcome that by creating a class to hold them
class ReadWriteInfo {
public:
static bool ReadableFile(string const file);
static string const ErrorMessage() { return error_message; }
private:
static string error_message;
};
bool ReadWriteInfo::ReadableFile( string const file )
{
error_message.erase();
if( file is not readable ) {
error_message = " some error message ";
return false;
}
return true;
}
if( !ReadWriteInfo::ReadableFile(file) )
std::cerr ReadWriteInfo::ErrorMessage() std::endl;
I'll do this anyway and put it into xform_helpers.[Ch]. If you like it, we
can always move it into support.
Does this mean that you aren't going to apply this patch? Please do, because
I'd like feedback/help
| Note also, that a writeable file need not yet exist but the directory
| should be writeable.
|
| Allan wrote them because he wanted the feedback for the "idiot
| user". I
We don't have idiot users.
Sure we do. Look at all the dumn questions I ask! I use LyX therefore LyX has
an idiot user!
A.
Re: FormPreferences patch
Angus Leeming [EMAIL PROTECTED] writes: | if( !ReadWriteInfo::ReadableFile(file) ) | std::cerr ReadWriteInfo::ErrorMessage() std::endl; | | I'll do this anyway and put it into xform_helpers.[Ch]. If you like it, we | can always move it into support. | | Does this mean that you aren't going to apply this patch? Please do, because | I'd like feedback/help No, I am applying and compiling as we speak. I have to fix a couple of warning: base initializer for `RGBColor' ../../../../src/frontends/xforms/Color.h:45: warning:will be re-ordered to precede member initializations before I commit. | Sure we do. Look at all the dumn questions I ask! I use LyX | therefore LyX has an idiot user! You are not a user you are an idiot developer! Lgb
Re: FormPreferences patch
Two patches attached. patch1 is very small. Just a couple of tiny things. patch2 continues the FormPreferences clean up, but it also allows you to change the LyX LColors. A couple of bugs remain, but I'd be grateful of some help/advice. See the ChangeLog entry. Finally, a useability question. Should I try and sort the X11 names in the browser. Not a straight alphabetical sort, but into a "rainbow" sort so that all names containing "red" ane grouped together, then those containing "orange" etc. What do people think? Anyway, have a play. I think you'll like it. Angus patch1.bz2 patch2.bz2
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | browser. Not a straight alphabetical sort, but into a "rainbow" sort so that | all names containing "red" ane grouped together, then those containing | "orange" etc. What do people think? Why not sort on rgb numbers? and also remove "indian red" if "IndianRed" exists and have the same rgb value. Howto map rgb number to rainbow numbers? (wavelength?) Is a color cube transformation needed? You probably need to handle grey values separately. Lgb
Re: FormPreferences patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Why not sort on rgb numbers? and also remove "indian red" if Lars> "IndianRed" exists and have the same rgb value. How do you know which one should be removed? JMarc
Re: FormPreferences patch
On Wed, 15 Nov 2000, Angus Leeming wrote: > Two patches attached. > > patch1 is very small. Just a couple of tiny things. > > patch2 continues the FormPreferences clean up, but > it also allows you to change the LyX LColors. > > A couple of bugs remain, but I'd be grateful of some help/advice. See the > ChangeLog entry. > > Finally, a useability question. Should I try and sort the X11 names in the > browser. Not a straight alphabetical sort, but into a "rainbow" sort so that > all names containing "red" ane grouped together, then those containing > "orange" etc. What do people think? > > Anyway, have a play. I think you'll like it. > Angus > + Moved class xformColor to files xform_helpers.[Ch]. These files, > + Color.[Ch], could now be moved into src if they would be useful to > + other GUIs. For KDE, QColor can handle both HSV, RGB, and named X colours, so it wouldn't be useful AFAICS. john
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | patch2 continues the FormPreferences clean up, but Why do we want to have: int IsDirWriteable (string const & path); bool IsFileReadable (string const & path); int IsFileWriteable (string const & path); _and_ (WriteableDir, ReadableDir, WriteableFile, ReadableFile) i.e. which(?) of them should go? Lgb
Re: FormPreferences patch
good question! Note that the new functions are more sophisticated than the old ones. In particular, they can tell you WHY the dir/file isn't read/writeable. Note also, that a writeable file need not yet exist but the directory should be writeable. Allan wrote them because he wanted the feedback for the "idiot user". I modified them so that they worked ;-) and then thought that they'd be useful to other GUI's. They're certainly useful to other xforms dialogs, so they should at least be put in xform_helpers.[Ch] rather than just in FormPreferences. As you can see, I'm not sure whether they should replace the existing functions! Angus On Wednesday 15 November 2000 16:18, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | patch2 continues the FormPreferences clean up, but > > Why do we want to have: > > int IsDirWriteable (string const & path); > bool IsFileReadable (string const & path); > int IsFileWriteable (string const & path); > > _and_ > > (WriteableDir, ReadableDir, WriteableFile, > ReadableFile) > > i.e. which(?) of them should go? > > Lgb
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes:
| Note that the new functions are more sophisticated than the old ones. In
| particular, they can tell you WHY the dir/file isn't read/writeable.
I feel that this is a bit too much of hand holding. And they are not
core support functions... I'd say move them to frontends.
(I'd really hate to see code like:
string dummy;
if (ReadableFile(file, dummy)) { ... } )
| Note also, that a writeable file need not yet exist but the directory should
| be writeable.
|
| Allan wrote them because he wanted the feedback for the "idiot
| user". I
We don't have idiot users.
Lgb
Re: FormPreferences patch
On Wednesday 15 November 2000 16:39, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Note that the new functions are more sophisticated than the old ones. In
> | particular, they can tell you WHY the dir/file isn't read/writeable.
>
> I feel that this is a bit too much of hand holding. And they are not
> core support functions... I'd say move them to frontends.
> (I'd really hate to see code like:
> string dummy;
> if (ReadableFile(file, dummy)) { ... } )
well we could easily overcome that by creating a class to hold them
class ReadWriteInfo {
public:
static bool ReadableFile(string const & file);
static string const & ErrorMessage() { return error_message; }
private:
static string error_message;
};
bool ReadWriteInfo::ReadableFile( string const & file )
{
error_message.erase();
if( file is not readable ) {
error_message = " some error message ";
return false;
}
return true;
}
if( !ReadWriteInfo::ReadableFile(file) )
std::cerr << ReadWriteInfo::ErrorMessage() << std::endl;
I'll do this anyway and put it into xform_helpers.[Ch]. If you like it, we
can always move it into support.
Does this mean that you aren't going to apply this patch? Please do, because
I'd like feedback/help
> | Note also, that a writeable file need not yet exist but the directory
> | should be writeable.
> |
> | Allan wrote them because he wanted the feedback for the "idiot
> | user". I
>
> We don't have idiot users.
Sure we do. Look at all the dumn questions I ask! I use LyX therefore LyX has
an idiot user!
A.
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | if( !ReadWriteInfo::ReadableFile(file) ) | std::cerr << ReadWriteInfo::ErrorMessage() << std::endl; | | I'll do this anyway and put it into xform_helpers.[Ch]. If you like it, we | can always move it into support. | | Does this mean that you aren't going to apply this patch? Please do, because | I'd like feedback/help No, I am applying and compiling as we speak. I have to fix a couple of warning: base initializer for `RGBColor' ../../../../src/frontends/xforms/Color.h:45: warning:will be re-ordered to precede member initializations before I commit. | Sure we do. Look at all the dumn questions I ask! I use LyX | therefore LyX has an idiot user! You are not a user you are an idiot developer! Lgb
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Attached is a clean-up of FormPreferences. Each tab folder is Angus now encapsulated in its own class. Angus The patch also activates the various "Browse" buttons, although Angus LyXFileDlg still needs to be modified to make it Angus straightforward to return a directory if that is what is Angus desired. Applied. Looks good. BTW, I see you use Xform in a lot of names. The real name of the toolkit is Xforms, but maybe you just don't care :) JMarc
Re: FormPreferences patch
On Tuesday 14 November 2000 13:58, Jean-Marc Lasgouttes wrote: "Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Attached is a clean-up of FormPreferences. Each tab folder is Angus now encapsulated in its own class. Angus The patch also activates the various "Browse" buttons, although Angus LyXFileDlg still needs to be modified to make it Angus straightforward to return a directory if that is what is Angus desired. Applied. Looks good. BTW, I see you use Xform in a lot of names. The real name of the toolkit is Xforms, but maybe you just don't care :) I think Lars would reply "Nada, nada, nada...", but since I've no idea what this means I'll just say, "So sue me"! A.
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus I think Lars would reply "Nada, nada, nada...", but since I've Angus no idea what this means I'll just say, "So sue me"! Well, "xform" is a noce name too actually :) JMarc
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Attached is a clean-up of FormPreferences. Each tab folder is Angus> now encapsulated in its own class. Angus> The patch also activates the various "Browse" buttons, although Angus> LyXFileDlg still needs to be modified to make it Angus> straightforward to return a directory if that is what is Angus> desired. Applied. Looks good. BTW, I see you use Xform in a lot of names. The real name of the toolkit is Xforms, but maybe you just don't care :) JMarc
Re: FormPreferences patch
On Tuesday 14 November 2000 13:58, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Attached is a clean-up of FormPreferences. Each tab folder is > Angus> now encapsulated in its own class. > > Angus> The patch also activates the various "Browse" buttons, although > Angus> LyXFileDlg still needs to be modified to make it > Angus> straightforward to return a directory if that is what is > Angus> desired. > > Applied. Looks good. > > BTW, I see you use Xform in a lot of names. The real name of the > toolkit is Xforms, but maybe you just don't care :) I think Lars would reply "Nada, nada, nada...", but since I've no idea what this means I'll just say, "So sue me"! A.
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I think Lars would reply "Nada, nada, nada...", but since I've Angus> no idea what this means I'll just say, "So sue me"! Well, "xform" is a noce name too actually :) JMarc
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Here is that patch. Angus I've simply commented out FL_LIGHTER_COL1. It's not yet used Angus anyway. If you can work out how to highlight the active folder, Angus it won't be. Fine. I applied the patch. Angus The patch also adds the ability to write any changes to the Angus xforms GUI to file and to then read them back in next time. Angus LyXLex is very easy to use! Isn't it? ;) JMarc
Re: FormPreferences patch
Attached is a clean-up of FormPreferences. Each tab folder is now encapsulated in its own class. The patch also activates the various "Browse" buttons, although LyXFileDlg still needs to be modified to make it straightforward to return a directory if that is what is desired. Angus patch.diff.bz2
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Here is that patch. Angus> I've simply commented out FL_LIGHTER_COL1. It's not yet used Angus> anyway. If you can work out how to highlight the active folder, Angus> it won't be. Fine. I applied the patch. Angus> The patch also adds the ability to write any changes to the Angus> xforms GUI to file and to then read them back in next time. Angus> LyXLex is very easy to use! Isn't it? ;) JMarc
Re: FormPreferences patch
Attached is a clean-up of FormPreferences. Each tab folder is now encapsulated in its own class. The patch also activates the various "Browse" buttons, although LyXFileDlg still needs to be modified to make it straightforward to return a directory if that is what is desired. Angus patch.diff.bz2
Re: FormPreferences patch
Here is that patch. I've simply commented out FL_LIGHTER_COL1. It's not yet used anyway. If you can work out how to highlight the active folder, it won't be. The patch also adds the ability to write any changes to the xforms GUI to file and to then read them back in next time. LyXLex is very easy to use! Angus On Friday 10 November 2000 17:33, Jean-Marc Lasgouttes wrote: "Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus The Colors tab is now working and, to show you all the fun you Angus can have with it, I've given it the ability to modify the Angus colors of the xforms GUI. In fact, this is ALL you can do with Angus it at the moment; modifying the colors in LColor will come Angus next. Angus, I cannot compile on xforms 0.88 because of: cxx: Error: ../../../../lyx-devel/src/frontends/xforms/FormPreferences.C, line 654: identifier "FL_LIGHTER_COL1" is undefined xcol.colorID = FL_LIGHTER_COL1; ---^ I will commit anyway before leaving, although I cannot compile. But if you have a quick fix... JMarc patch.diff.bz2
Re: FormPreferences patch
Here is that patch. I've simply commented out FL_LIGHTER_COL1. It's not yet used anyway. If you can work out how to highlight the active folder, it won't be. The patch also adds the ability to write any changes to the xforms GUI to file and to then read them back in next time. LyXLex is very easy to use! Angus On Friday 10 November 2000 17:33, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> The Colors tab is now working and, to show you all the fun you > Angus> can have with it, I've given it the ability to modify the > Angus> colors of the xforms GUI. In fact, this is ALL you can do with > Angus> it at the moment; modifying the colors in LColor will come > Angus> next. > > Angus, I cannot compile on xforms 0.88 because of: > > cxx: Error: ../../../../lyx-devel/src/frontends/xforms/FormPreferences.C, > line 654: identifier "FL_LIGHTER_COL1" is undefined > xcol.colorID = FL_LIGHTER_COL1; > ---^ > > I will commit anyway before leaving, although I cannot compile. But if > you have a quick fix... > > JMarc patch.diff.bz2
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus The Colors tab is now working and, to show you all the fun you Angus can have with it, I've given it the ability to modify the Angus colors of the xforms GUI. In fact, this is ALL you can do with Angus it at the moment; modifying the colors in LColor will come Angus next. Angus, I cannot compile on xforms 0.88 because of: cxx: Error: ../../../../lyx-devel/src/frontends/xforms/FormPreferences.C, line 654: identifier "FL_LIGHTER_COL1" is undefined xcol.colorID = FL_LIGHTER_COL1; ---^ I will commit anyway before leaving, although I cannot compile. But if you have a quick fix... JMarc
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> The Colors tab is now working and, to show you all the fun you Angus> can have with it, I've given it the ability to modify the Angus> colors of the xforms GUI. In fact, this is ALL you can do with Angus> it at the moment; modifying the colors in LColor will come Angus> next. Angus, I cannot compile on xforms 0.88 because of: cxx: Error: ../../../../lyx-devel/src/frontends/xforms/FormPreferences.C, line 654: identifier "FL_LIGHTER_COL1" is undefined xcol.colorID = FL_LIGHTER_COL1; ---^ I will commit anyway before leaving, although I cannot compile. But if you have a quick fix... JMarc
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Attached is a patch that gets rid of the timer. Feedback now Angus uses the Preemptive handler instead. Much simpler. The patch Angus also finishes off the Converters and Formats tabs. ALMOST. I Angus need a little help to finish off, so... Applied. It looks quite good. JMarc
Re: FormPreferences patch
Attached is yet another patch to FormPreferences. I think you'll like this one... The Colors tab is now working and, to show you all the fun you can have with it, I've given it the ability to modify the colors of the xforms GUI. In fact, this is ALL you can do with it at the moment; modifying the colors in LColor will come next. This will resolve the problem just posted by Haase Hartmut. How topical! From the ChangeLog: * src/frontends/xforms/FormPreferences.[Ch]: functioning Colors tab. Can now alter the colors of the xform's GUI on the fly. With the aid of a single static Signal (see below), can "Apply" these changes to all currently open dialogs. (Well, to all of the NEW dialogs and to LyXView. The OLD dialogs are not yet redrawn.) ALL subsequently opened dialogs will, of course, also have the new color scheme. Cannot yet save (or load) the choices to file, so they are lost when exiting LyX. Angus patch.diff.bz2
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Attached is a patch that gets rid of the timer. Feedback now Angus> uses the Preemptive handler instead. Much simpler. The patch Angus> also finishes off the Converters and Formats tabs. ALMOST. I Angus> need a little help to finish off, so... Applied. It looks quite good. JMarc
Re: FormPreferences patch
Attached is yet another patch to FormPreferences. I think you'll like this one... The Colors tab is now working and, to show you all the fun you can have with it, I've given it the ability to modify the colors of the xforms GUI. In fact, this is ALL you can do with it at the moment; modifying the colors in LColor will come next. This will resolve the problem just posted by Haase Hartmut. How topical! >From the ChangeLog: * src/frontends/xforms/FormPreferences.[Ch]: functioning Colors tab. Can now alter the colors of the xform's GUI on the fly. With the aid of a single static Signal (see below), can "Apply" these changes to all currently open dialogs. (Well, to all of the NEW dialogs and to LyXView. The OLD dialogs are not yet redrawn.) ALL subsequently opened dialogs will, of course, also have the new color scheme. Cannot yet save (or load) the choices to file, so they are lost when exiting LyX. Angus patch.diff.bz2
Re: FormPreferences patch
On 07-Nov-2000 Dekel Tsur wrote: I guess you only use Latin languages, in which case a single keymap suffices. But if you want, for example, Hebrew/Russian/English, then you need 3 different maps!. Well I understood that you have other keymap problems then me and I want to resolve them obviously I just didn't want to change a working behaviour. We can define the keymap of all latin languages to be "latin", and have a lyxrc variable which select the real keymap to use for these languages. naaa And/or, we can have 3 different modes of keymap: no keymap, manual (i.e. the old behavior - there are two keymaps, and they are switched by the user), and automatic. I think that I could live with this solution (well actually I find it good ;) Default mode is "no keymap"! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ wolf, n.: A man who knows all the ankles.
Re: FormPreferences patch
Attached is a patch that gets rid of the timer. Feedback now uses the Preemptive handler instead. Much simpler. The patch also finishes off the Converters and Formats tabs. ALMOST. I need a little help to finish off, so... I haven't made use of a functor; if anyone is desperately worried, then feel free. Note that the vectors are very small! Can't yet Apply the Converters because I didn't have time to make Converter a "real" class. Ie, it's still static. Perhaps you'd do this, Dekel, as you know the code best. (Everything in FormPreferences should be ready; all you'd need to do is uncomment the code in applyConverters().) A question for Dekel: what is the Flags field for in the Converters tab? I put it in because you asked me to, but have no idea how to use it. Again, perhaps you'd do this. Note the associated comment in feedbackConverters()! Another question: in lyxrc.defaults there is the command: \ps_command "gs" This isn't implemented in the Preferences dialog. Should it be, or can it be replaced by a Converter (PS-XPM perhaps)? If it should be implemented, then where should it go. Note also that it will need a brief description in LyXRC::getDescription(). I think that's it. Everything should now be (almost!) working except for the Colours tab. Angus patch.diff.bz2
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 10:23:47PM +0100, Lars Gullik Bjnnes wrote:
Dekel Tsur [EMAIL PROTECTED] writes:
| Use
| struct compare_formats {
| bool operator()(Format const a, Format const b) {
| return a.name b.name;
| }
| }
|
| and then
| sort(formats_vec.begin(), formats_vec.end(), compare_formats());
|
| PS Is there a template for simplfying this ?
Yes, less (e.g. less(Format())
No. lessFormat requires having Format::operator, which we don't have
(and if there is Format::operator, it is suffices to write
sort(formats_vec.begin(), formats_vec.end()) ).
Is there something like lessFormat, Format::name() ?
Does sort take a function returning bool or one returning int? (-1
less than 0 = equal 1 greater than)?
Bool:
void sort(RandomAccessIterator first, RandomAccessIterator last,
StrictWeakOrdering comp);
A Strict Weak Ordering is a Binary Predicate that compares two objects,
returning true if the first precedes the second. This predicate must satisfy
the standard mathematical definition of a strict weak ordering. The precise
requirements are stated below, but what they roughly mean is that a Strict
Weak Ordering has to behave the way that "less than" behaves: if a is less
than b then b is not less than a, if a is less than b and b is less than c
then a is less than c, and so on.
Re: FormPreferences patch
On Wed, Nov 08, 2000 at 06:43:08PM +, Angus Leeming wrote: Can't yet Apply the Converters because I didn't have time to make Converter a "real" class. Ie, it's still static. Perhaps you'd do this, Dekel, as you know the code best. (Everything in FormPreferences should be ready; all you'd need to do is uncomment the code in applyConverters().) OK A question for Dekel: what is the Flags field for in the Converters tab? I put it in because you asked me to, but have no idea how to use it. Again, perhaps you'd do this. Note the associated comment in feedbackConverters()! The Flags field is a list of flags which controls the behavior of the converter. See lib/lyxrc.example for explanation of the flags. Note that the Flags field in the converters tab should actually be replaced by several buttons, one for each flag (e.g. a push button for the latex flag, a text input button for the resultdir flag etc.), but since I keep changing these flags, it wouldn't be a good idea to do it now...
Re: FormPreferences patch
On 07-Nov-2000 Dekel Tsur wrote: > > I guess you only use Latin languages, in which case a single keymap suffices. > But if you want, for example, Hebrew/Russian/English, then you need 3 > different maps!. > Well I understood that you have other keymap problems then me and I want to resolve them obviously I just didn't want to change a working behaviour. > We can define the keymap of all latin languages to be "latin", and have a > lyxrc variable which select the real keymap to use for these languages. naaa > And/or, we can have 3 different modes of keymap: no keymap, manual (i.e. the > old behavior - there are two keymaps, and they are switched by the user), > and automatic. I think that I could live with this solution (well actually I find it good ;) Default mode is "no keymap"! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ wolf, n.: A man who knows all the ankles.
Re: FormPreferences patch
Attached is a patch that gets rid of the timer. Feedback now uses the Preemptive handler instead. Much simpler. The patch also finishes off the Converters and Formats tabs. ALMOST. I need a little help to finish off, so... I haven't made use of a functor; if anyone is desperately worried, then feel free. Note that the vectors are very small! Can't yet Apply the Converters because I didn't have time to make Converter a "real" class. Ie, it's still static. Perhaps you'd do this, Dekel, as you know the code best. (Everything in FormPreferences should be ready; all you'd need to do is uncomment the code in applyConverters().) A question for Dekel: what is the Flags field for in the Converters tab? I put it in because you asked me to, but have no idea how to use it. Again, perhaps you'd do this. Note the associated comment in feedbackConverters()! Another question: in lyxrc.defaults there is the command: \ps_command "gs" This isn't implemented in the Preferences dialog. Should it be, or can it be replaced by a Converter (PS->XPM perhaps)? If it should be implemented, then where should it go. Note also that it will need a brief description in LyXRC::getDescription(). I think that's it. Everything should now be (almost!) working except for the Colours tab. Angus patch.diff.bz2
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 10:23:47PM +0100, Lars Gullik Bjnnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> | Use
> | struct compare_formats {
> | bool operator()(Format const & a, Format const & b) {
> | return a.name < b.name;
> | }
> | }
> |
> | and then
> | sort(formats_vec.begin(), formats_vec.end(), compare_formats());
> |
> | PS Is there a template for simplfying this ?
>
>
> Yes, less<> (e.g. less(Format>())
No. less requires having Format::operator<, which we don't have
(and if there is Format::operator<, it is suffices to write
sort(formats_vec.begin(), formats_vec.end()) ).
Is there something like less() ?
> Does sort take a function returning bool or one returning int? (-1
> less than 0 = equal 1 greater than)?
Bool:
void sort(RandomAccessIterator first, RandomAccessIterator last,
StrictWeakOrdering comp);
A Strict Weak Ordering is a Binary Predicate that compares two objects,
returning true if the first precedes the second. This predicate must satisfy
the standard mathematical definition of a strict weak ordering. The precise
requirements are stated below, but what they roughly mean is that a Strict
Weak Ordering has to behave the way that "less than" behaves: if a is less
than b then b is not less than a, if a is less than b and b is less than c
then a is less than c, and so on.
Re: FormPreferences patch
On Wed, Nov 08, 2000 at 06:43:08PM +, Angus Leeming wrote: > Can't yet Apply the Converters because I didn't have time to make Converter a > "real" class. Ie, it's still static. Perhaps you'd do this, Dekel, as you > know the code best. (Everything in FormPreferences should be ready; all you'd > need to do is uncomment the code in applyConverters().) OK > > A question for Dekel: what is the Flags field for in the Converters tab? I > put it in because you asked me to, but have no idea how to use it. Again, > perhaps you'd do this. Note the associated comment in feedbackConverters()! The Flags field is a list of flags which controls the behavior of the converter. See lib/lyxrc.example for explanation of the flags. Note that the Flags field in the converters tab should actually be replaced by several buttons, one for each flag (e.g. a push button for the latex flag, a text input button for the resultdir flag etc.), but since I keep changing these flags, it wouldn't be a good idea to do it now...
Re: FormPreferences patch
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel I want to add a keymap entry to the languages file, so that the Dekel keymap can automatically change when the language is changed Dekel (esp. useful for multilingual files). Except that french users with a qwerty keyboard (all non-pc unix stations have qwerty keyboard instead of french azerty layout) may want two type of kmap (1) qwerty to azerty or (2) just enable some dead keys to type french accents. I imagine there are other cases where this is needed. JMarc
Re: FormPreferences patch
On 06-Nov-2000 Dekel Tsur wrote: I want to add a keymap entry to the languages file, so that the keymap can automatically change when the language is changed (esp. useful for multilingual files). I surely don't want this! I have only one keyboard and I want my keys as they are. If I like to have another keymap I can set it by hand (but this is not neccessary if you set up your keyboard in the right manner!). And I do write multilingual documents. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You are the only person to ever get this message.
Re: FormPreferences patch
On Mon, 06 Nov 2000, Dekel Tsur wrote:
The items in the combox shouldn't have the full path and the kmap
extension, namely, it should be
american-2
american
instead of
.../lyx-devel/lib/kbd/american-2.kmap
/lyx-devel/lib/kbd/american.kmap
Sure. I just wanted to get something working first.
1. Does "Apply" remove formats if no longer present.
It doesn't, becuase you didn't put formats_vec.erase(it) in
FormatsInputDelete().
;-)
BTW, in FormatsInputBrowser() (and other places) you do something like
string name = fl_get_browser_line(formats_-browser_formats, i);
vectorFormat::iterator it = find_if(formats_vec.begin(),
formats_vec.end(), compare_memfun(Format::getname, name)); if (it !=
formats_vec.end()) {
fl_set_input(formats_-input_format, it-name.c_str());
why aren't you doing it the way I originally did ? namely
int i = fl_get_browser(formats_-browser_formats);
if (i 0) {
Format const f = formats_vec[i-1];
fl_set_input(formats_-input_format, f.name.c_str());
Because I sort the list of names (which I store). If I could sort the list of
formats by name, then I'd do that instead. Note that the STL is largely
unknown to me and whilst I do have reference literature, I find that I tend
to use example (eg find_if(), compare_memfunc()) to expand my coding base.
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Because I sort the list of names (which I store). If I could Angus sort the list of formats by name, then I'd do that instead. Angus Note that the STL is largely unknown to me and whilst I do have Angus reference literature, I find that I tend to use example (eg Angus find_if(), compare_memfunc()) to expand my coding base. BTW Angus, what's the reason why you did not use (properly) lyxlex to read rgb.txt files? Is it only because it does not handle '!' as comment character? In this case, it would be easy to add a commentChar(char) method to LyXLex. You current code is a bit longer than needed... JMarc
Re: FormPreferences patch
On Tue, 07 Nov 2000, Jean-Marc Lasgouttes wrote: "Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Because I sort the list of names (which I store). If I could Angus sort the list of formats by name, then I'd do that instead. Angus Note that the STL is largely unknown to me and whilst I do have Angus reference literature, I find that I tend to use example (eg Angus find_if(), compare_memfunc()) to expand my coding base. BTW Angus, what's the reason why you did not use (properly) lyxlex to read rgb.txt files? Is it only because it does not handle '!' as comment character? In this case, it would be easy to add a commentChar(char) method to LyXLex. You current code is a bit longer than needed... sigh... Jean-Marc, I've worked flat out on this stuff for two weeks. If anybody feels the need to clean up the code base, then they won't find me stopping them. This isn't meant to be a flame, just exhaustion! But you're right. That was the only reason! Well spotted. ;-) Incidentally, don't bother applying the patch. Things have moved on. I'll resubmit soon enough. Angus
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus sigh... Jean-Marc, I've worked flat out on this stuff for two Angus weeks. If anybody feels the need to clean up the code base, Angus then they won't find me stopping them. This isn't meant to be a Angus flame, just exhaustion! That was not meant to be a flame either, just "constructive comments" :) I appreciate the amount of work that went into preference dialog these last weeks and am rather amazed by the result. I'll try to see if I find the time to rewrite this method a bit. JMarc
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 09:39:22AM +, Angus Leeming wrote:
why aren't you doing it the way I originally did ? namely
int i = fl_get_browser(formats_-browser_formats);
if (i 0) {
Format const f = formats_vec[i-1];
fl_set_input(formats_-input_format, f.name.c_str());
Because I sort the list of names (which I store). If I could sort the list of
formats by name, then I'd do that instead. Note that the STL is largely
unknown to me and whilst I do have reference literature, I find that I tend
to use example (eg find_if(), compare_memfunc()) to expand my coding base.
Use
struct compare_formats {
bool operator()(Format const a, Format const b) {
return a.name b.name;
}
}
and then
sort(formats_vec.begin(), formats_vec.end(), compare_formats());
PS Is there a template for simplfying this ?
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 10:19:19AM +0100, Juergen Vigna wrote: On 06-Nov-2000 Dekel Tsur wrote: I want to add a keymap entry to the languages file, so that the keymap can automatically change when the language is changed (esp. useful for multilingual files). I surely don't want this! I have only one keyboard and I want my keys as they are. If I like to have another keymap I can set it by hand (but this is not neccessary if you set up your keyboard in the right manner!). And I do write multilingual documents. I guess you only use Latin languages, in which case a single keymap suffices. But if you want, for example, Hebrew/Russian/English, then you need 3 different maps!. We can define the keymap of all latin languages to be "latin", and have a lyxrc variable which select the real keymap to use for these languages. And/or, we can have 3 different modes of keymap: no keymap, manual (i.e. the old behavior - there are two keymaps, and they are switched by the user), and automatic.
Re: FormPreferences patch
Well now. I defined
bool FormatsCompare( Format const a, Format const b )
{
return( a.name b.name );
}
and then
sort( formats_vec.begin(), formats_vec.end(), FormatsCompare );
And something similar for sorting Commands:
bool CommandCompare( Command const a, Command const b )
{
if( a.from-prettyname == b.from-prettyname )
return( a.to-prettyname b.to-prettyname );
else
return( a.from-prettyname b.from-prettyname );
}
sort( commands_vec.begin(), commands_vec.end(), CommandCompare );
Which all seems to work fine. Is your way "better"?
Anyway, thanks for the hint.
Angus
ps. I now have a fully working formats tab. It even posts a warning when I
try and delete a Format used in an existing converter Command. (Not yet
submitted.) Presumably, to do the same with the Converters tab I should do as
you have done with the Formats class. Ie make it non-static and define two
instances, a system_converters and a user_converters or similar.
A.
On Tue, 07 Nov 2000, Dekel Tsur wrote:
On Tue, Nov 07, 2000 at 09:39:22AM +, Angus Leeming wrote:
why aren't you doing it the way I originally did ? namely
int i = fl_get_browser(formats_-browser_formats);
if (i 0) {
Format const f = formats_vec[i-1];
fl_set_input(formats_-input_format, f.name.c_str());
Because I sort the list of names (which I store). If I could sort the
list of formats by name, then I'd do that instead. Note that the STL is
largely unknown to me and whilst I do have reference literature, I find
that I tend to use example (eg find_if(), compare_memfunc()) to expand my
coding base.
Use
struct compare_formats {
bool operator()(Format const a, Format const b) {
return a.name b.name;
}
}
and then
sort(formats_vec.begin(), formats_vec.end(), compare_formats());
PS Is there a template for simplfying this ?
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 06:42:27PM +, Angus Leeming wrote:
Well now. I defined
bool FormatsCompare( Format const a, Format const b )
{
return( a.name b.name );
}
and then
sort( formats_vec.begin(), formats_vec.end(), FormatsCompare );
And something similar for sorting Commands:
Which all seems to work fine. Is your way "better"?
Yes, because when using a functor the compare function is inlined, and here
it is not!
instances, a system_converters and a user_converters or similar.
Use system_converters and converters.
Re: FormPreferences patch
Dekel Tsur [EMAIL PROTECTED] writes:
| Use
| struct compare_formats {
| bool operator()(Format const a, Format const b) {
| return a.name b.name;
| }
| }
|
| and then
| sort(formats_vec.begin(), formats_vec.end(), compare_formats());
|
| PS Is there a template for simplfying this ?
Yes, less (e.g. less(Format())
Does sort take a function returning bool or one returning int? (-1
less than 0 = equal 1 greater than)?
Lgb
Re: FormPreferences patch
Dekel Tsur [EMAIL PROTECTED] writes: IMHO the default keymap for any given keymap should be the default keymap for the system, if _nything_ else is wanted it should be configured and decided by the user. i.e. we should not add a keymap field to languages. Lgb | On Tue, Nov 07, 2000 at 10:19:19AM +0100, Juergen Vigna wrote: | | On 06-Nov-2000 Dekel Tsur wrote: | | I want to add a keymap entry to the languages file, so that the keymap | can automatically change when the language is changed (esp. useful for | multilingual files). | | I surely don't want this! I have only one keyboard and I want my | keys as they are. If I like to have another keymap I can set it by hand | (but this is not neccessary if you set up your keyboard in the right | manner!). And I do write multilingual documents. | | I guess you only use Latin languages, in which case a single keymap suffices. | But if you want, for example, Hebrew/Russian/English, then you need 3 | different maps!. | | We can define the keymap of all latin languages to be "latin", and have a | lyxrc variable which select the real keymap to use for these languages. | And/or, we can have 3 different modes of keymap: no keymap, manual (i.e. the | old behavior - there are two keymaps, and they are switched by the user), | and automatic.
Re: FormPreferences patch
On 06-Nov-2000 Dekel Tsur wrote: I want to add a keymap entry to the languages file, so that the keymap can automatically change when the language is changed (esp. useful for multilingual files). I surely don't want this! I have only one keyboard and I want my keys as they are. If I like to have another keymap I can set it by hand (but this is not neccessary if you set up your keyboard in the right manner!). And I do write multilingual documents. I guess you only use Latin languages, in which case a single keymap suffices. But if you want, for example, Hebrew/Russian/English, then you need 3 different maps!. Although I write only "Latin" languages I would like to use such a feature as well. It would be perfect if it is optional. Andre' -- André Pönitz [EMAIL PROTECTED]
Re: FormPreferences patch
bool FormatsCompare( Format const a, Format const b )
{
return( a.name b.name );
}
and then
sort( formats_vec.begin(), formats_vec.end(), FormatsCompare );
And something similar for sorting Commands:
bool CommandCompare( Command const a, Command const b )
{
if( a.from-prettyname == b.from-prettyname )
return( a.to-prettyname b.to-prettyname );
else
return( a.from-prettyname b.from-prettyname );
}
sort( commands_vec.begin(), commands_vec.end(), CommandCompare );
Which all seems to work fine. Is your way "better"?
The functor object way is indeed "better" in some sense.
A function call through a pointer (as your solution uses) can not be
inlined, whereas the call to operator() can.
Of course this does not really matter in the given context so you should
choose whatever you like best.
Andre'
--
André Pönitz [EMAIL PROTECTED]
Re: FormPreferences patch
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> I want to add a keymap entry to the languages file, so that the Dekel> keymap can automatically change when the language is changed Dekel> (esp. useful for multilingual files). Except that french users with a qwerty keyboard (all non-pc unix stations have qwerty keyboard instead of french azerty layout) may want two type of kmap (1) qwerty to azerty or (2) just enable some dead keys to type french accents. I imagine there are other cases where this is needed. JMarc
Re: FormPreferences patch
On 06-Nov-2000 Dekel Tsur wrote: > > I want to add a keymap entry to the languages file, so that the keymap > can automatically change when the language is changed (esp. useful for > multilingual files). I surely don't want this! I have only one keyboard and I want my keys as they are. If I like to have another keymap I can set it by hand (but this is not neccessary if you set up your keyboard in the right manner!). And I do write multilingual documents. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You are the only person to ever get this message.
Re: FormPreferences patch
On Mon, 06 Nov 2000, Dekel Tsur wrote:
> The items in the combox shouldn't have the full path and the kmap
> extension, namely, it should be
> american-2
> american
> instead of
> .../lyx-devel/lib/kbd/american-2.kmap
> /lyx-devel/lib/kbd/american.kmap
Sure. I just wanted to get something working first.
> > 1. Does "Apply" remove formats if no longer present.
>
> It doesn't, becuase you didn't put formats_vec.erase(it) in
> FormatsInputDelete().
;-)
> BTW, in FormatsInputBrowser() (and other places) you do something like
>
> string name = fl_get_browser_line(formats_->browser_formats, i);
> vector::iterator it = find_if(formats_vec.begin(),
> formats_vec.end(), compare_memfun(::getname, name)); if (it !=
> formats_vec.end()) {
> fl_set_input(formats_->input_format, it->name.c_str());
>
>
> why aren't you doing it the way I originally did ? namely
>
> int i = fl_get_browser(formats_->browser_formats);
> if (i > 0) {
> Format const & f = formats_vec[i-1];
> fl_set_input(formats_->input_format, f.name.c_str());
Because I sort the list of names (which I store). If I could sort the list of
formats by name, then I'd do that instead. Note that the STL is largely
unknown to me and whilst I do have reference literature, I find that I tend
to use example (eg find_if(), compare_memfunc()) to expand my coding base.
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Because I sort the list of names (which I store). If I could Angus> sort the list of formats by name, then I'd do that instead. Angus> Note that the STL is largely unknown to me and whilst I do have Angus> reference literature, I find that I tend to use example (eg Angus> find_if(), compare_memfunc()) to expand my coding base. BTW Angus, what's the reason why you did not use (properly) lyxlex to read rgb.txt files? Is it only because it does not handle '!' as comment character? In this case, it would be easy to add a commentChar(char) method to LyXLex. You current code is a bit longer than needed... JMarc
Re: FormPreferences patch
On Tue, 07 Nov 2000, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Because I sort the list of names (which I store). If I could > Angus> sort the list of formats by name, then I'd do that instead. > Angus> Note that the STL is largely unknown to me and whilst I do have > Angus> reference literature, I find that I tend to use example (eg > Angus> find_if(), compare_memfunc()) to expand my coding base. > > BTW Angus, what's the reason why you did not use (properly) lyxlex to > read rgb.txt files? Is it only because it does not handle '!' as > comment character? In this case, it would be easy to add a > commentChar(char) method to LyXLex. You current code is a bit longer > than needed... sigh... Jean-Marc, I've worked flat out on this stuff for two weeks. If anybody feels the need to clean up the code base, then they won't find me stopping them. This isn't meant to be a flame, just exhaustion! But you're right. That was the only reason! Well spotted. ;-) Incidentally, don't bother applying the patch. Things have moved on. I'll resubmit soon enough. Angus
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> sigh... Jean-Marc, I've worked flat out on this stuff for two Angus> weeks. If anybody feels the need to clean up the code base, Angus> then they won't find me stopping them. This isn't meant to be a Angus> flame, just exhaustion! That was not meant to be a flame either, just "constructive comments" :) I appreciate the amount of work that went into preference dialog these last weeks and am rather amazed by the result. I'll try to see if I find the time to rewrite this method a bit. JMarc
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 09:39:22AM +, Angus Leeming wrote:
> > why aren't you doing it the way I originally did ? namely
> >
> > int i = fl_get_browser(formats_->browser_formats);
> > if (i > 0) {
> > Format const & f = formats_vec[i-1];
> > fl_set_input(formats_->input_format, f.name.c_str());
>
> Because I sort the list of names (which I store). If I could sort the list of
> formats by name, then I'd do that instead. Note that the STL is largely
> unknown to me and whilst I do have reference literature, I find that I tend
> to use example (eg find_if(), compare_memfunc()) to expand my coding base.
>
Use
struct compare_formats {
bool operator()(Format const & a, Format const & b) {
return a.name < b.name;
}
}
and then
sort(formats_vec.begin(), formats_vec.end(), compare_formats());
PS Is there a template for simplfying this ?
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 10:19:19AM +0100, Juergen Vigna wrote: > > On 06-Nov-2000 Dekel Tsur wrote: > > > > I want to add a keymap entry to the languages file, so that the keymap > > can automatically change when the language is changed (esp. useful for > > multilingual files). > > I surely don't want this! I have only one keyboard and I want my > keys as they are. If I like to have another keymap I can set it by hand > (but this is not neccessary if you set up your keyboard in the right > manner!). And I do write multilingual documents. I guess you only use Latin languages, in which case a single keymap suffices. But if you want, for example, Hebrew/Russian/English, then you need 3 different maps!. We can define the keymap of all latin languages to be "latin", and have a lyxrc variable which select the real keymap to use for these languages. And/or, we can have 3 different modes of keymap: no keymap, manual (i.e. the old behavior - there are two keymaps, and they are switched by the user), and automatic.
Re: FormPreferences patch
Well now. I defined
bool FormatsCompare( Format const & a, Format const & b )
{
return( a.name < b.name );
}
and then
sort( formats_vec.begin(), formats_vec.end(), );
And something similar for sorting Commands:
bool CommandCompare( Command const & a, Command const & b )
{
if( a.from->prettyname == b.from->prettyname )
return( a.to->prettyname < b.to->prettyname );
else
return( a.from->prettyname < b.from->prettyname );
}
sort( commands_vec.begin(), commands_vec.end(), );
Which all seems to work fine. Is your way "better"?
Anyway, thanks for the hint.
Angus
ps. I now have a fully working formats tab. It even posts a warning when I
try and delete a Format used in an existing converter Command. (Not yet
submitted.) Presumably, to do the same with the Converters tab I should do as
you have done with the Formats class. Ie make it non-static and define two
instances, a system_converters and a user_converters or similar.
A.
On Tue, 07 Nov 2000, Dekel Tsur wrote:
> On Tue, Nov 07, 2000 at 09:39:22AM +, Angus Leeming wrote:
> > > why aren't you doing it the way I originally did ? namely
> > >
> > > int i = fl_get_browser(formats_->browser_formats);
> > > if (i > 0) {
> > > Format const & f = formats_vec[i-1];
> > > fl_set_input(formats_->input_format, f.name.c_str());
> >
> > Because I sort the list of names (which I store). If I could sort the
> > list of formats by name, then I'd do that instead. Note that the STL is
> > largely unknown to me and whilst I do have reference literature, I find
> > that I tend to use example (eg find_if(), compare_memfunc()) to expand my
> > coding base.
>
> Use
> struct compare_formats {
> bool operator()(Format const & a, Format const & b) {
> return a.name < b.name;
> }
> }
>
> and then
> sort(formats_vec.begin(), formats_vec.end(), compare_formats());
>
> PS Is there a template for simplfying this ?
Re: FormPreferences patch
On Tue, Nov 07, 2000 at 06:42:27PM +, Angus Leeming wrote:
> Well now. I defined
>
> bool FormatsCompare( Format const & a, Format const & b )
> {
> return( a.name < b.name );
> }
> and then
> sort( formats_vec.begin(), formats_vec.end(), );
>
> And something similar for sorting Commands:
>
> Which all seems to work fine. Is your way "better"?
Yes, because when using a functor the compare function is inlined, and here
it is not!
> instances, a system_converters and a user_converters or similar.
Use system_converters and converters.
Re: FormPreferences patch
Dekel Tsur <[EMAIL PROTECTED]> writes:
| Use
| struct compare_formats {
| bool operator()(Format const & a, Format const & b) {
| return a.name < b.name;
| }
| }
|
| and then
| sort(formats_vec.begin(), formats_vec.end(), compare_formats());
|
| PS Is there a template for simplfying this ?
Yes, less<> (e.g. less(Format>())
Does sort take a function returning bool or one returning int? (-1
less than 0 = equal 1 greater than)?
Lgb
Re: FormPreferences patch
Dekel Tsur <[EMAIL PROTECTED]> writes: IMHO the default keymap for any given keymap should be the default keymap for the system, if _nything_ else is wanted it should be configured and decided by the user. i.e. we should not add a keymap field to languages. Lgb | On Tue, Nov 07, 2000 at 10:19:19AM +0100, Juergen Vigna wrote: | > | > On 06-Nov-2000 Dekel Tsur wrote: | > > | > > I want to add a keymap entry to the languages file, so that the keymap | > > can automatically change when the language is changed (esp. useful for | > > multilingual files). | > | > I surely don't want this! I have only one keyboard and I want my | > keys as they are. If I like to have another keymap I can set it by hand | > (but this is not neccessary if you set up your keyboard in the right | > manner!). And I do write multilingual documents. | | I guess you only use Latin languages, in which case a single keymap suffices. | But if you want, for example, Hebrew/Russian/English, then you need 3 | different maps!. | | We can define the keymap of all latin languages to be "latin", and have a | lyxrc variable which select the real keymap to use for these languages. | And/or, we can have 3 different modes of keymap: no keymap, manual (i.e. the | old behavior - there are two keymaps, and they are switched by the user), | and automatic.
Re: FormPreferences patch
> > On 06-Nov-2000 Dekel Tsur wrote: > > > > > > I want to add a keymap entry to the languages file, so that the keymap > > > can automatically change when the language is changed (esp. useful for > > > multilingual files). > > > > I surely don't want this! I have only one keyboard and I want my > > keys as they are. If I like to have another keymap I can set it by hand > > (but this is not neccessary if you set up your keyboard in the right > > manner!). And I do write multilingual documents. > > I guess you only use Latin languages, in which case a single keymap suffices. > But if you want, for example, Hebrew/Russian/English, then you need 3 > different maps!. Although I write only "Latin" languages I would like to use such a feature as well. It would be perfect if it is optional. Andre' -- André Pönitz [EMAIL PROTECTED]
Re: FormPreferences patch
> bool FormatsCompare( Format const & a, Format const & b )
> {
> return( a.name < b.name );
> }
> and then
> sort( formats_vec.begin(), formats_vec.end(), );
>
> And something similar for sorting Commands:
>
> bool CommandCompare( Command const & a, Command const & b )
> {
> if( a.from->prettyname == b.from->prettyname )
> return( a.to->prettyname < b.to->prettyname );
> else
> return( a.from->prettyname < b.from->prettyname );
> }
> sort( commands_vec.begin(), commands_vec.end(), );
>
> Which all seems to work fine. Is your way "better"?
The functor object way is indeed "better" in some sense.
A function call through a pointer (as your solution uses) can not be
inlined, whereas the call to operator() can.
Of course this does not really matter in the given context so you should
choose whatever you like best.
Andre'
--
André Pönitz [EMAIL PROTECTED]
Re: FormPreferences patch
I think that you should list all (and only) .kmap files. (But you can just replace the keymap comboxes by simple text input buttons, as I am going to remove the kbmap_primary/kbmap_secondary variables from lyxrc.) Ok. We're to leave it up to the user to get things right here?. But why are you going to remove these variables? Few more remarks: The converters tab doesn't have a flags field. The formats tab is doesn't have a shortcut field. Thanks for the info. One more: The Add button in converters/formats tabs should be named add/change Well, I thought of changing "Add" to "Change" on the fly. I do have a question on the behavior of the converters/formats tabs. Are the following assumptions true ? 1. The add/delete buttons only change the local information, but the actual change to the formats/converters is done when pressing apply/save. That's the idea. Not yet implemented of course! 2. It will not be possible to delete a format which is the from/to format of some existing converter. This can be made to happen. Some warning messages could inform the user about why s/he can't remove an entry. Angus
Re: FormPreferences patch
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel I think that you should list all (and only) .kmap files. (But Dekel you can just replace the keymap comboxes by simple text input Dekel buttons, as I am going to remove the Dekel kbmap_primary/kbmap_secondary variables from lyxrc.) What are you going to replace them with? I think it is nice for the user to be able to browse the existing files, instead of trying to guess what to use. JMarc
Re: FormPreferences patch
On Mon, 06 Nov 2000, Jean-Marc Lasgouttes wrote: "Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel I think that you should list all (and only) .kmap files. (But Dekel you can just replace the keymap comboxes by simple text input Dekel buttons, as I am going to remove the Dekel kbmap_primary/kbmap_secondary variables from lyxrc.) What are you going to replace them with? I think it is nice for the user to be able to browse the existing files, instead of trying to guess what to use. Attempting to create a choice item containing all these .kmap files... Is their a file helper function in support equivalent to "ls *.kmap"? I can't see anything, but I may be looking in the wrong place. If not, I'll make a function in filetools: vectorstring const? DirList( string const dir, string const ext = string() ) Angus
Re: FormPreferences patch
Patch attached. Any answers to the questions below? Angus 2000-11-06 Angus Leeming [EMAIL PROTECTED] * src/frontends/xforms/forms/form_preferences.fd: Inactive tab folders are no longer dark. Haven't yet worked out how to lighten the colour of the active tabfolder. Any ideas anybody? Adjusted Colours tab a little. Added Shortcut field to converters tab. Note that we can't create an fdesign label like "input_shortcut" as this buggers up the sed-script stuff. * src/frontends/xforms/FormPreferences.[Ch]: (feedback): fixed crash due to to ob=0. (LanguagesXXX): the kbmap choices now contain the files sytem_lyxdir/kbd/*.kmap. I think that these choices should eventually be replaced by an input with a file browse button, but since the browse buttons don'y yet work, this'll do for the moment. (FormatsXXX): think that this is now nearly fully functional. Some points/questions though: 1. Does "Apply" remove formats if no longer present. 2. I think that the browser should list the GUI names rather than the format names. 3. Must ensure that we can't delete Formats used by an existing Converter. * src/support/filetools.[Ch] (DirList): new function. Not at all sure if this is the best way to do this. patch.diff.bz2
Re: FormPreferences patch
(LanguagesXXX): the kbmap choices now contain the files
sytem_lyxdir/kbd/*.kmap. I think that these choices should eventually
be replaced by an input with a file browse button, but since the browse
buttons don'y yet work, this'll do for the moment.
The items in the combox shouldn't have the full path and the kmap extension,
namely, it should be
american-2
american
instead of
.../lyx-devel/lib/kbd/american-2.kmap
.../lyx-devel/lib/kbd/american.kmap
1. Does "Apply" remove formats if no longer present.
It doesn't, becuase you didn't put formats_vec.erase(it) in
FormatsInputDelete().
BTW, in FormatsInputBrowser() (and other places) you do something like
string name = fl_get_browser_line(formats_-browser_formats, i);
vectorFormat::iterator it = find_if(formats_vec.begin(), formats_vec.end(),
compare_memfun(Format::getname, name));
if (it != formats_vec.end()) {
fl_set_input(formats_-input_format, it-name.c_str());
why aren't you doing it the way I originally did ? namely
int i = fl_get_browser(formats_-browser_formats);
if (i 0) {
Format const f = formats_vec[i-1];
fl_set_input(formats_-input_format, f.name.c_str());
Re: FormPreferences patch
On Mon, Nov 06, 2000 at 11:12:08AM +0100, Jean-Marc Lasgouttes wrote: "Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel I think that you should list all (and only) .kmap files. (But Dekel you can just replace the keymap comboxes by simple text input Dekel buttons, as I am going to remove the Dekel kbmap_primary/kbmap_secondary variables from lyxrc.) What are you going to replace them with? I think it is nice for the user to be able to browse the existing files, instead of trying to guess what to use. I want to add a keymap entry to the languages file, so that the keymap can automatically change when the language is changed (esp. useful for multilingual files).
Re: FormPreferences patch
> I think that you should list all (and only) .kmap files. > (But you can just replace the keymap comboxes by simple text input buttons, > as I am going to remove the kbmap_primary/kbmap_secondary variables from > lyxrc.) Ok. We're to leave it up to the user to get things right here?. But why are you going to remove these variables? > Few more remarks: > The converters tab doesn't have a flags field. > The formats tab is doesn't have a shortcut field. Thanks for the info. > One more: > The Add button in converters/formats tabs should be named add/change Well, I thought of changing "Add" to "Change" on the fly. > I do have a question on the behavior of the converters/formats tabs. > Are the following assumptions true ? > 1. The add/delete buttons only change the local information, but the > actual change to the formats/converters is done when pressing apply/save. That's the idea. Not yet implemented of course! > 2. It will not be possible to delete a format which is the from/to format > of some existing converter. This can be made to happen. Some warning messages could inform the user about why s/he can't remove an entry. Angus
Re: FormPreferences patch
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> I think that you should list all (and only) .kmap files. (But Dekel> you can just replace the keymap comboxes by simple text input Dekel> buttons, as I am going to remove the Dekel> kbmap_primary/kbmap_secondary variables from lyxrc.) What are you going to replace them with? I think it is nice for the user to be able to browse the existing files, instead of trying to guess what to use. JMarc
Re: FormPreferences patch
On Mon, 06 Nov 2000, Jean-Marc Lasgouttes wrote: > > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > > Dekel> I think that you should list all (and only) .kmap files. (But > Dekel> you can just replace the keymap comboxes by simple text input > Dekel> buttons, as I am going to remove the > Dekel> kbmap_primary/kbmap_secondary variables from lyxrc.) > > What are you going to replace them with? I think it is nice for the > user to be able to browse the existing files, instead of trying to > guess what to use. Attempting to create a choice item containing all these .kmap files... Is their a file helper function in support equivalent to "ls *.kmap"? I can't see anything, but I may be looking in the wrong place. If not, I'll make a function in filetools: vector const? DirList( string const & dir, string const & ext = string() ) Angus
Re: FormPreferences patch
Patch attached. Any answers to the questions below? Angus 2000-11-06 Angus Leeming <[EMAIL PROTECTED]> * src/frontends/xforms/forms/form_preferences.fd: Inactive tab folders are no longer dark. Haven't yet worked out how to lighten the colour of the active tabfolder. Any ideas anybody? Adjusted Colours tab a little. Added Shortcut field to converters tab. Note that we can't create an fdesign label like "input_shortcut" as this buggers up the sed-script stuff. * src/frontends/xforms/FormPreferences.[Ch]: (feedback): fixed crash due to to ob=0. (LanguagesXXX): the kbmap choices now contain the files sytem_lyxdir/kbd/*.kmap. I think that these choices should eventually be replaced by an input with a file browse button, but since the browse buttons don'y yet work, this'll do for the moment. (FormatsXXX): think that this is now nearly fully functional. Some points/questions though: 1. Does "Apply" remove formats if no longer present. 2. I think that the browser should list the GUI names rather than the format names. 3. Must ensure that we can't delete Formats used by an existing Converter. * src/support/filetools.[Ch] (DirList): new function. Not at all sure if this is the best way to do this. patch.diff.bz2
Re: FormPreferences patch
> (LanguagesXXX): the kbmap choices now contain the files
> sytem_lyxdir/kbd/*.kmap. I think that these choices should eventually
> be replaced by an input with a file browse button, but since the browse
> buttons don'y yet work, this'll do for the moment.
The items in the combox shouldn't have the full path and the kmap extension,
namely, it should be
american-2
american
instead of
.../lyx-devel/lib/kbd/american-2.kmap
.../lyx-devel/lib/kbd/american.kmap
> 1. Does "Apply" remove formats if no longer present.
It doesn't, becuase you didn't put formats_vec.erase(it) in
FormatsInputDelete().
BTW, in FormatsInputBrowser() (and other places) you do something like
string name = fl_get_browser_line(formats_->browser_formats, i);
vector::iterator it = find_if(formats_vec.begin(), formats_vec.end(),
compare_memfun(::getname, name));
if (it != formats_vec.end()) {
fl_set_input(formats_->input_format, it->name.c_str());
why aren't you doing it the way I originally did ? namely
int i = fl_get_browser(formats_->browser_formats);
if (i > 0) {
Format const & f = formats_vec[i-1];
fl_set_input(formats_->input_format, f.name.c_str());
Re: FormPreferences patch
On Mon, Nov 06, 2000 at 11:12:08AM +0100, Jean-Marc Lasgouttes wrote: > > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > > Dekel> I think that you should list all (and only) .kmap files. (But > Dekel> you can just replace the keymap comboxes by simple text input > Dekel> buttons, as I am going to remove the > Dekel> kbmap_primary/kbmap_secondary variables from lyxrc.) > > What are you going to replace them with? I think it is nice for the > user to be able to browse the existing files, instead of trying to > guess what to use. I want to add a keymap entry to the languages file, so that the keymap can automatically change when the language is changed (esp. useful for multilingual files).
Re: FormPreferences patch
On Sat, Nov 04, 2000 at 12:48:29AM +0200, Dekel Tsur wrote: Few more remarks: The converters tab doesn't have a flags field. The formats tab is doesn't have a shortcut field. One more: The Add button in converters/formats tabs should be named add/change I do have a question on the behavior of the converters/formats tabs. Are the following assumptions true ? 1. The add/delete buttons only change the local information, but the actual change to the formats/converters is done when pressing apply/save. 2. It will not be possible to delete a format which is the from/to format of some existing converter.
Re: FormPreferences patch
On Sat, Nov 04, 2000 at 12:48:29AM +0200, Dekel Tsur wrote: > Few more remarks: > The converters tab doesn't have a flags field. > The formats tab is doesn't have a shortcut field. One more: The Add button in converters/formats tabs should be named add/change I do have a question on the behavior of the converters/formats tabs. Are the following assumptions true ? 1. The add/delete buttons only change the local information, but the actual change to the formats/converters is done when pressing apply/save. 2. It will not be possible to delete a format which is the from/to format of some existing converter.
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus oh yes, and I THINK I've fixed the crash problem when closing Angus LyX after opening FormPreferences. Could someone check, as I Angus can't reproduce the problem here... Angus, a question: would it be possible to change the font of the selected tab to *bold*? Currently, I find it difficult to see, especially for the outer tabs. JMarc
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus Attached is a patch implementing Colours and Formats tabs. You Angus can't actually DO anything with them yet, but I'd like some Angus feedback. Angus, I'll apply your patch. Note however that it contains lines like if( name == "gray0" ) name = "black" if( name == "gray100" ) name = "white" which probably do not compile better on your machine than it does on mine :) You should probably check that you submitted the right version. JMarc
Re: FormPreferences patch
"Angus" == Angus Leeming [EMAIL PROTECTED] writes: Angus The colours tab is a shameless copy of an xforms demo. I've Angus tried to write it in C++, but I'm a bit of a novice still. All Angus feedback welcome. A few remarks: - the field showing the resulting color is not visible enough (the sliders are more visible, in fact). - it would be better not to have the rgb codes visible in the color list. It is distracting. - since the colors are fixed to those contained in rgb.txt, would it be possible to force the value of the sliders to the real color (you select the color in the browser, so you could also fix the positions of the sliders). JMarc
Re: FormPreferences patch
On Fri, 03 Nov 2000, Jean-Marc Lasgouttes wrote:
Angus, I'll apply your patch. Note however that it contains lines
like
if( name == "gray0" ) name = "black"
if( name == "gray100" ) name = "white"
which probably do not compile better on your machine than it does on
mine :) You should probably check that you submitted the right
version.
Thanks, Jean-Marc.
I did submit the right version. Unfortunately, I succumbed to temptation and
made one last change and then didn't bother to recompile.
Sorry for the inconvenience.
A few remarks:
- the field showing the resulting color is not visible enough (the
sliders are more visible, in fact).
I've changed the order to "name r g b". That should be clearer.
- it would be better not to have the rgb codes visible in the color
list. It is distracting.
- since the colors are fixed to those contained in rgb.txt, would it
be possible to force the value of the sliders to the real color (you
select the color in the browser, so you could also fix the positions
of the sliders).
Well, the colours are NOT fixed to those in rgb.txt. Move the sliders and you
get the closest approximation to this in the browser. Click on the browser
entry and the slider adjusts to it.
This way, you don't need to have rgb.txt to select colours. It just helps!
I don't thing the LColor entries need know about the colour name at all. Why
not just have LColour::color containing a list of coloured elements
(background, foreground, latex etc) and change LColour::ColorEntry to
struct ColorEntry {
LColor::color lcolor;
string guiname;
vectorint rgb(3);
};
Eg: (latex, "LaTeX", vectorint(255,0,0)).
There's no need for LyX to know the actual colour of any of its elements.
Just the logical colour. LColour::color would become (see bottom).
AND this would clean up an ugly bit of code, moving GUI stuff into the GUI.
Thoughts?
Angus
enum color {
// Needed interface colors
/// Background color
background,
/// Foreground color
foreground,
/// Background color of selected text
selection,
/// Text color in LaTeX mode
latex,
/// Titles color of floats
floats,
/// Text color for notes
note,
/// Background color of notes
notebg,
/// Frame color for notes
noteframe,
/// Color for the depth bars in the margin
depthbar,
/// Color for marking foreign language words
language,
/// Text color for command insets
command,
/// Background color for command insets
commandbg,
/// Frame color for command insets
commandframe,
/// Text color for accents we can't handle nicely
accent,
///
accentbg,
///
accentframe,
/// Minipage line color
minipageline,
/// Special chars text color
special,
/// Math inset text color
math,
/// Math inset background color
mathbg,
/// Math inset frame color
mathframe,
/// Math cursor color
mathcursor,
/// Math line color
mathline,
/// Footnote marker text
footnote,
/// Footnote marker background color
footnotebg,
/// Footnote line color
footnoteframe,
/// ERT marker text
ert,
/// Text color for inset marker
inset,
/// Inset marker background color
insetbg,
/// Inset marker frame color
insetframe,
/// Error box text color
error,
/// EOL marker color
eolmarker,
/// Appendix line color
appendixline,
/// VFill line color
vfillline,
/// Top and bottom line color
topline,
/// Table line color
tableline,
/// Table line color
tabularline,
/// Table line color
tabularonoffline,
/// Bottom area color
bottomarea,
/// Page break color
pagebreak,
/// Color used for top of boxes
top,
/// Color used for bottom of boxes
Re: FormPreferences patch
On Thu, Nov 02, 2000 at 10:22:35PM +, Angus Leeming wrote: Esp. with the Formats (Outputs-Formats). This is the first point: where should it go. Formats are for input AND output. Suggestions for the name of a new top level tab? Second point. I shoved in the "Viewers" field with this tab. I propose having it optional. Make sense, or have I got the wrong end of the stick? Yes, it does seem reasonable. When do you plan on making this tab functional ? The colours tab is a shameless copy of an xforms demo. I've tried to write it in C++, but I'm a bit of a novice still. All feedback welcome. Is it possible to replace the X11 colors browser with a table of buttons, each one colored by a different color ? (or at least, in the browser put the color name before the rgb values, or omit the rgb values). oh yes, and I THINK I've fixed the crash problem when closing LyX after opening FormPreferences. Could someone check, as I can't reproduce the problem here... Yes, the crash is gone.
Re: FormPreferences patch
Angus Leeming [EMAIL PROTECTED] writes:
| I don't thing the LColor entries need know about the colour name at all. Why
| not just have LColour::color containing a list of coloured elements
| (background, foreground, latex etc) and change LColour::ColorEntry to
|
| struct ColorEntry {
| LColor::color lcolor;
| string guiname;
| vectorint rgb(3);
| };
|
| Eg: (latex, "LaTeX", vectorint(255,0,0)).
Eh now ... make a RGB class to hole the rgb values.
struct RGB {
int r;
int g;
int b;
RGB(int red, int green, int blue) : r(red), g(green), b(blue) {}
};
so {latex, "LaTeX", RGB(255, 0, 0)}
Lgb
