Re: FormPreferences patch
On Wed, 15 Nov 2000, Angus Leeming wrote: > Allan wrote them because he wanted the feedback for the "idiot user". Actually I wrote them so the input checking could be complete. You don't have to be an idiot to misspell a directory name or filename and since the browse buttons weren't working you had to remember the filename/directory for a few seconds while you typed it in. Even goldfish can't remember longer than 5 seconds ago and everyone knows goldfish are smart ;-) > I modified them so that they worked ;-) and then thought that they'd I probably broke them when I split them up to be more readable. > 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. Maybe into src/frontends/support/ as opposed to your other suggestion of src/. They should be optional so John could use QColor. Allan. (ARRae)
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
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
> "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
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 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
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:
| 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
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: | 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
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "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? pttrbb... you just pick one... btw. I see that this is already done. Lgb
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
> "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
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
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
On Tue, Nov 14, 2000 at 02:29:59PM +, Angus Leeming wrote: > I think Lars would reply "Nada, nada, nada...", but since I've no idea what > this means I'll just say, "So sue me"! In portuguese that means: * nothing, nothing, nothing or * swim, swim, swim Now you choose. ;-) > A. -- José
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
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> 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
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
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
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
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 Tue, Nov 07, 2000 at 10:23:47PM +0100, Lars Gullik Bj&resh;nnes 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
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 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
> 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
> > 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
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
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
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
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 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 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
> "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, 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> Patch attached. Any answers to the questions below? Angus BTW, do you still want me to apply the patch (since there has been a bit of discussion)? JMarc
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 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(&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
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
> "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 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
> (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(&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
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
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
> "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
> 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
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
> > To do list: > * Colours, Formats and Cnnverter tabs: make functional. > * Update LyXRC::getDefinitions(). Boo! Hiss! > * Language kbmaps. Don't load with "list of languages", load with "list of > available kbmaps". I'm stuck here because I don't know which of the different > files in lib/kbd are important. There are .kmap and .cdef files. What to > include? Someone out there MUST know... 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.) Few more remarks: The converters tab doesn't have a flags field. The formats tab is doesn't have a shortcut field.
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> You mean the RGB struct? Two points: 1. It's tiny. 2. This is Angus> definitely evolving code. It may be that it's useful to LColor Angus> too, in which case fine; we'll put it somewhere global. In the Angus> meantime, think of it as an aide-memoir for me! That's (mostly) fine with me, I was just trying to criticize code I had not written, in order to feel important :) JMarc
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Please don't apply my former patch. This one implements a RGB Angus> struct in FormPreferences. All the rest is identical. Concerning the tab color scheme, it does not look very good to me (this dark grey is too eye-catching). I'd rather have the current tabfolder highlighted in light grey. JMarc
Re: FormPreferences patch
On Fri, 03 Nov 2000, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Please don't apply my former patch. This one implements a RGB > Angus> struct in FormPreferences. All the rest is identical. > > I am not sure that I like having this code in formpreference. Does it > mean that other frontends will have to duplicate part of the code? Or > do we consider that they have their own color picker anyway? > > I'll apply it anyway. > > JMarc You mean the RGB struct? Two points: 1. It's tiny. 2. This is definitely evolving code. It may be that it's useful to LColor too, in which case fine; we'll put it somewhere global. In the meantime, think of it as an aide-memoir for me! Angus
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Please don't apply my former patch. This one implements a RGB Angus> struct in FormPreferences. All the rest is identical. I am not sure that I like having this code in formpreference. Does it mean that other frontends will have to duplicate part of the code? Or do we consider that they have their own color picker anyway? I'll apply it anyway. JMarc
Re: FormPreferences patch
Please don't apply my former patch. This one implements a RGB struct in
FormPreferences. All the rest is identical.
Lars, I take it that you're happy that I have a go at cleaning up LColor?
Angus
On Fri, 03 Nov 2000, Lars Gullik Bjønnes wrote:
> 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;
> | vector rgb(3);
> | };
> |
> | Eg: (latex, "LaTeX", vector(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
patch2_3Nov2000.bz2
Re: FormPreferences patch
The attched patch adds a converter tab to FormPreferences. It also addresses some requests from Dekel and Jean-Marc. See bottom. To do list: * Colours, Formats and Cnnverter tabs: make functional. * Update LyXRC::getDefinitions(). Boo! Hiss! * Language kbmaps. Don't load with "list of languages", load with "list of available kbmaps". I'm stuck here because I don't know which of the different files in lib/kbd are important. There are .kmap and .cdef files. What to include? Someone out there MUST know... Angus On Fri, 03 Nov 2000, Dekel Tsur wrote: > > 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. Good! > When do you plan on making this tab functional ? Ouch! I only have so much time to spare... Soon, I hope. > > 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). Well making a button browser seems a bit excessive for the time being. You're the second person to ask for some change though, so I've omitted 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. Good. On Fri, 03 Nov 2000, Jean-Marc Lasgouttes wrote: > 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. Well, I couldn't do this. Put I did manage to change the colours of the tabfolders so that inactive ones are darker. See attachment. A. patch3Nov2000.bz2
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;
| vector rgb(3);
| };
|
| Eg: (latex, "LaTeX", vector(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
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
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;
vector rgb(3);
};
Eg: (latex, "LaTeX", vector(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
> "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
> "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> 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
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... Angus On Thu, 02 Nov 2000, Angus Leeming wrote: > > Attached is a patch implementing Colours and Formats tabs. You can't > actually DO anything with them yet, but I'd like some feedback. > > 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? > > 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. > > This patch also fixes a bug in FormCitation: inability to Apply to > different insets without closing the dialog. > > As I see it, that just leaves a Converter tab to do and then all is > finished here... > > Angus
Re: FormPreferences patch
Attached is a patch implementing Colours and Formats tabs. You can't actually DO anything with them yet, but I'd like some feedback. 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? 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. This patch also fixes a bug in FormCitation: inability to Apply to different insets without closing the dialog. As I see it, that just leaves a Converter tab to do and then all is finished here... Angus patch2Nov2000.bz2
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Attached is a clean-up patch to FormPreferences and LyXRC. I'll apply it. JMarc
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | > Why? you have access to cvs.lyx.org and should be able to do a cvs | > add, so that you can get new files into the diff/patch? | | I do? No one told me! Remeber that we set this up before you went on some vacation? You only need to set your password properly. Lgb
Re: FormPreferences patch
On Tue, 31 Oct 2000, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | When untarred the attachment will contain: > | > | PATCH31Oct2000/src/frontends/xforms/xform_helpers.h > | PATCH31Oct2000/src/frontends/xforms/xform_helpers.C > > Why? you have access to cvs.lyx.org and should be able to do a cvs > add, so that you can get new files into the diff/patch? I do? No one told me! A.
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | When untarred the attachment will contain: | | PATCH31Oct2000/src/frontends/xforms/xform_helpers.h | PATCH31Oct2000/src/frontends/xforms/xform_helpers.C Why? you have access to cvs.lyx.org and should be able to do a cvs add, so that you can get new files into the diff/patch? Lgb
Re: FormPreferences patch
Attached is a clean-up patch to FormPreferences and LyXRC. >From the ChangeLog: * src/frontends/xforms/xform_helpers.[Ch]: new files. Repository for useful xforms helper functions. At present contains only formatted(). Input a string and it returns it with line breaks so that in fits inside the label. * src/frontends/xforms/Makefile.am: add new files. * src/lyxrc.[Ch] (getDescription): new name for getFeedback. * src/lyxrc.C (getDescription): Removed '\n's from strings. Corrected punctuation. * src/frontends/xforms/FormPreferences.[Ch]: * src/frontends/xforms/forms/form_preferences.fd: No new functionality but lots of little clean ups. Removed enum State. Make use of formatted(). Constify lots of methods. Perhaps best of all: removed requirement for that horrible reinterpret_cast from pointer to long in feedbackPost(). Angus When untarred the attachment will contain: PATCH31Oct2000/src/frontends/xforms/xform_helpers.h PATCH31Oct2000/src/frontends/xforms/xform_helpers.C PATCH31Oct2000/patch patch31Oct2000.tar.bz2
Re: FormPreferences patch
Jean-Marc Lasgouttes wrote: > > > "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: > > Garst> I would still like to see texmf/tex instead of just tex to > Garst> isolate the ls-R generated by texhash. I brought it up before > Garst> and you said not for 1.1.4 :) Garst > > Why should it be isolated? > > JMarc because as it is the ls-R includes everything in the .lyx directory instead of just what is in the tex directory.
Re: FormPreferences patch
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: Garst> I would still like to see texmf/tex instead of just tex to Garst> isolate the ls-R generated by texhash. I brought it up before Garst> and you said not for 1.1.4 :) Garst Why should it be isolated? JMarc
Re: FormPreferences patch
Jean-Marc Lasgouttes wrote: > > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > Lars> besides I don't think we should put too many levels of > Lars> directories in .lyx but rather keep it as flat as possible. > > The idea was that there would be several ui files in ui/. A sciword or > msword ui file come to mind. > > JMarc I would still like to see texmf/tex instead of just tex to isolate the ls-R generated by texhash. I brought it up before and you said not for 1.1.4 :) Garst
Re: FormPreferences patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> besides I don't think we should put too many levels of Lars> directories in .lyx but rather keep it as flat as possible. The idea was that there would be several ui files in ui/. A sciword or msword ui file come to mind. JMarc
Re: FormPreferences patch
On Mon, 30 Oct 2000, Lars Gullik Bjønnes wrote:
> I think you used the wrong name for getFeedback, imho it should have
> been getDescription.
Changed.
> | * feedback is now output via a timer callback loop that is functionally
> | identical to that in Toolbar_pimpl. No longer any need to change an entry
> | to get feedback. The only items not providing feedback are the new
> | Comboxes!
> I never liked the hidden timers.
Well, I've cleaned this one up a little, so that I no longer need that
horrible reinterpret_cast from pointer to long.
However, I have a Combox question for you.
I can set the combox post handler, analogous to
fl_set_object_posthandler(FL_OBJECT *ob, feedbackPost);
Combox combo.setpost( feedbackComboPost );
However, what is the equivalent of "event", used by feedbackPost() to decide
what to do (see below)? Ie, "event" is not passed to feedbackComboPost which
would be
void feedbackComboPost();
I see that Combox has a method peek_event() that interogates xevents, but I
don't know if this is what I should be using, or even how to use it.
Anyone able to help me here?
Angus
void FormPreferences::feedbackPost(FL_OBJECT *ob, int event)
{
// We do not test for empty help here, since this can never happen
if(event == FL_ENTER){
// Used as a placeholder for ob, so that we don't have to
// a horrible reinterpret_cast to long and pass it as an
// argument in fl_set_object_callback.
callbackObj = ob;
fl_set_object_callback(dialog_->timer_feedback,
C_FormPreferencesFeedbackCB,
0);
fl_set_timer(dialog_->timer_feedback, 0.5);
}
else if(event != FL_MOTION){
fl_set_timer(dialog_->timer_feedback, 0);
callbackObj = 0;
fl_set_object_label(dialog_->text_warning, "");
}
}
Re: FormPreferences patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | * feedback is now output via a timer callback loop that is Lars> functionally | identical to that in Toolbar_pimpl. No longer any Lars> need to change an entry to | get feedback. The only items not Lars> providing feedback are the new | Comboxes! Lars> I never liked the hidden timers. We will probably be able to switch to proper tooltips when we switch to xforms 0.90. JMarc
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | Thanks for the various bits of feedback. | | Attached is a patch that adds one or two missing variables to | FormPreferences. | It also cleans up the existing code: | * I've moved the various Feedback messages into LyXRC to avoid | duplication in I think you used the wrong name for getFeedback, imho it should have been getDescription. | * We select the languages using a Combox, rather than a choice. good. | * feedback is now output via a timer callback loop that is functionally | identical to that in Toolbar_pimpl. No longer any need to change an entry to | get feedback. The only items not providing feedback are the new | Comboxes! I never liked the hidden timers. | Main Dialog->Outputs->Fax | string fax_command; * Are these still needed? | string phone_book; | string fax_program; No, we want to set this code inactive. I'll do that. We will only enable it if a lot of users complain. | | Main Dialog->Outputs->Viewers | \viewer | | In addition, we need to add the ability to edit individual \bind | entries. (Or| at least input the file containing the users choices.) Yes, we don't need the full fledged online bind editing now. Actually we have all we need already since you can name your own bind file in the bind input and from that file inlucde the bind file that you base it on. Lgb
Re: FormPreferences patch
Thanks for the various bits of feedback. Attached is a patch that adds one or two missing variables to FormPreferences. It also cleans up the existing code: * I've moved the various Feedback messages into LyXRC to avoid duplication in the other frontends. * We select the languages using a Combox, rather than a choice. * feedback is now output via a timer callback loop that is functionally identical to that in Toolbar_pimpl. No longer any need to change an entry to get feedback. The only items not providing feedback are the new Comboxes! All changes follow suggestions by JMarc! Angus Below is an updated list of what needs doing in FormPreferences. Main Dialog->Look&Feel->Colours Ability to set colours of background, text, notes etc. \set_color Main Dialog->I/O // New Tab, because converters cover Input AND Output. \converter \Format Main Dialog->Outputs->Fax string fax_command; * Are these still needed? string phone_book; string fax_program; Main Dialog->Outputs->Viewers \viewer In addition, we need to add the ability to edit individual \bind entries. (Or at least input the file containing the users choices.) Multiple \converter, \viewer (and \bind) commands will be input using tabs of the format suggested by Dekel: +--+++ |dvi | format |dvi | |ps|++ | |++ | | viewer |xdvi| +--+++ +---+--+---+ |Add|Delete|Replace| +---+--+---+ patch_preferences.bz2
Re: FormPreferences patch
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Imho bindings should go into their own file, why they can very | Lars> well be edited from preferences. | | I'll reiterate the opinion that they should go in ui/. THey are just | another (non-graphical) way for the user to access lyxfuncs. I can agree on that, but they should _not_ be in defult.ui. besides I don't think we should put too many levels of directories in .lyx but rather keep it as flat as possible. Lgb
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | H! But I can not use the key shortcut #L to "launch" the combox (try!) | and then use the arrow keys to scroll through it. I can do this with the | current set up. Probably missing from the combox code... patches will be accepted. | This isn't to say that the current set up is better, (clearly it isn't), but | combox should be extended so that the user can use shortcuts to | navigate it. as said... Lgb
Re: FormPreferences patch
On Mon, 30 Oct 2000, Juergen Vigna wrote: > On 30-Oct-2000 Angus Leeming wrote: > >> Angus, it would be much better to use a combox for the list of > >> languages (it is too long here). > > > > How would using a combox make it shorter? I'm happy to make it a combox, > > but this just seems to be style rather than substance. > > Well have a look at the document->languages combox ;), it doen't make the > list shorter only the combox is scrollable! > > Jürgen H! But I can not use the key shortcut #L to "launch" the combox (try!) and then use the arrow keys to scroll through it. I can do this with the current set up. This isn't to say that the current set up is better, (clearly it isn't), but combox should be extended so that the user can use shortcuts to navigate it. Thanks for the info. Angus
Re: FormPreferences patch
On 30-Oct-2000 Angus Leeming wrote: >> Angus, it would be much better to use a combox for the list of >> languages (it is too long here). > > How would using a combox make it shorter? I'm happy to make it a combox, but > this just seems to be style rather than substance. > Well have a look at the document->languages combox ;), it doen't make the list shorter only the combox is scrollable! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ One advantage of talking to yourself is that you know at least somebody's listening. -- Franklin P. Jones
Re: FormPreferences patch
On Mon, 30 Oct 2000, Jean-Marc Lasgouttes wrote: > Angus, it would be much better to use a combox for the list of > languages (it is too long here). Moreover, the old way of using the > list of languages for kmaps is plain wrong. You should get (in some > way) the list of available kmap files (either hardcoded or from > a text file). Thanks for the feedback, Jean-Marc. > Angus, it would be much better to use a combox for the list of > languages (it is too long here). How would using a combox make it shorter? I'm happy to make it a combox, but this just seems to be style rather than substance. > Moreover, the old way of using the list of languages for kmaps is > plain wrong. You should get (in some way) the list of available kmap files > (either hardcoded or from a text file). Here is the current contents of lib/kbd: CVS/ german-3.kmapmagyar.kmap american-2.kmap german.kmap null.kmap american.kmapgreek.kmap polish.kmap arabic.kmap hebrew.kmap portuges.kmap brazil.kmap iso8859-1.cdef romanian.kmap brazil2.kmap iso8859-2.cdef sf.kmap czech-prg.kmap iso8859-7.cdef sg.kmap czech.kmap iso8859-8.cdef slovak.kmap european.kmapkoi8-r.kmap slovene.kmap francais.kmaplatvian.kmap transilvanian.kmap french.kmap magyar-2.kmapturkish-f.kmap german-2.kmapmagyar-3.kmapturkish.kmap How is this meant to work? Are lang.kmap, lang-2.kmap alternatives or is lang-2.kmap "included" in the kmap for "lang". What are the *.cdef files. Angus
Re: FormPreferences patch
Angus, it would be much better to use a combox for the list of languages (it is too long here). Moreover, the old way of using the list of languages for kmaps is plain wrong. You should get (in some way) the list of available kmap files (either hardcoded or from a text file). JMarc
Re: FormPreferences patch
Angus> Attached is a patch adding a Languages tab to FormPreferences. Angus> (Also one or two miscellaneous bits.) Applied. JMarc
Re: FormPreferences patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Imho bindings should go into their own file, why they can very Lars> well be edited from preferences. I'll reiterate the opinion that they should go in ui/. THey are just another (non-graphical) way for the user to access lyxfuncs. JMarc
Re: FormPreferences patch
Angus Leeming <[EMAIL PROTECTED]> writes: | What to do with individual bind keys? | Eg \bind "Delete" "delete-backward" | \bind "F12" "language french" Imho bindings should go into their own file, why they can very well be edited from preferences. In the preferences file we store the "main" bindings file, and in f.ex. user_bindings the modifications to this are stored. When stating lyx we first load the bindings file in preferences and then the bindings in user_bindings. Also the bindings parsing in class lyxrc should be moved to an other class. | What about the following stuff. Is it all still needed? Where to put it? | | /// ??? | bool pdf_mode; get rid of it Lgb
Re: FormPreferences patch
On Fri, Oct 27, 2000 at 05:56:48PM +0100, Angus Leeming wrote: > Outputs->Exporters. > \converter > > Outputs->Viewers > \viewer You also need \format > Inputs->Importers > \converter Note that currently there is no difference between converters used for exporting and converter used for importing, but I am going to add a field to the Command class, that stores the type of the converter. > What about the following stuff. Is it all still needed? Where to put it? > > /// ??? > bool pdf_mode; The pdf_mode and use_gui should not be edited in the preferences dialog as their value is set by LyX and it is not stored in lyxrc/preferences (so perhaps they should be moved from lyxrc). > /// ?? > bool auto_number; Flag telling whether to automatically reverse number in RTL text (It should be grouped with rtl_support, but I don't think anyone will want to set it to false, so it can be left out from the dialog). > Any/all feedback welcomed. Especially if you have any ideas on how to enter > arbitrary numbers of converter functions, viewers or bind keys!!! For example, the viewers tab can be implemented using a browser with all the viewable formats, two text inputs (format/viewer) and add/delete/replace buttons: +--+++ |dvi | format |dvi | |ps|++ | |++ | | viewer |xdvi| +--+++ +---+--+---+ |Add|Delete|Replace| +---+--+---+ The same idea can be used for converter/bind keys.
Re: FormPreferences patch
Attached is a patch adding a Languages tab to FormPreferences. (Also one or two miscellaneous bits.) Below is a list of all the lyxrc variables that are not yet set by FormPreferences. I've grouped some of them in the tabs that they'll end up being set in. Colours Tab Ability to set colours of background, text, notes etc. \set_color Outputs->Exporters. \converter string fax_command; * Are these still needed? string phone_book; string fax_program; Outputs->Viewers \viewer Inputs->Importers \converter What to do with individual bind keys? Eg \bind "Delete" "delete-backward" \bind "F12" "language french" What about the following stuff. Is it all still needed? Where to put it? /// ??? bool pdf_mode; /// postscript interpreter (in general "gs", if it is installed) string ps_command; /// option for telling the dvi viewer about the paper size string view_dvi_paper_option; /// DPI of monitor. float dpi; /// ?? bool auto_number; /// Do we have to use a GUI? bool use_gui; Any/all feedback welcomed. Especially if you have any ideas on how to enter arbitrary numbers of converter functions, viewers or bind keys!!! Angus patch2_27Oct2000.bz2
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I haven't found a way of getting a callback when clicking the Angus> mouse on an input box. Only when altering the contents. This Angus> isn't ideal, as it means that you get feedback for these inputs Angus> only by altering the text. If you enter invalid text, then Angus> you'll get the warning, not the feedback. Two remarks: - when we switch to 0.89/0.90, you may want to use tooltips instead of the current help scheme. Currently, it is not possible to see help without clicking on an entry. - for entries which require paths, why do we need to have a checkbox to enable them? We could decide that empty means disabled. And indeed, I like it. What is the proportion of implemented tags? JMarc
Re: FormPreferences patch
On Fri, 27 Oct 2000, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> FormPreferences is now much more user-friendly as it has > Angus> Feedback and Warning messages. It's also more coder-friendly as > Angus> it's now modular. Modules are based on tabs, so it's easy to > Angus> folllow the flow of the code and it's easy to add new > Angus> functionality. > > I'll apply it. Excellent. I think you'll like this one, but a word of warning/request for info... I haven't found a way of getting a callback when clicking the mouse on an input box. Only when altering the contents. This isn't ideal, as it means that you get feedback for these inputs only by altering the text. If you enter invalid text, then you'll get the warning, not the feedback. Anyway, suck it and see. No doubt this is sometthing that can be overcome eventually. Angus
Re: FormPreferences patch
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> FormPreferences is now much more user-friendly as it has Angus> Feedback and Warning messages. It's also more coder-friendly as Angus> it's now modular. Modules are based on tabs, so it's easy to Angus> folllow the flow of the code and it's easy to add new Angus> functionality. I'll apply it. JMarc
