Martin Vermeer wrote:
>> Maybe. Or maybe the dialog will simply inform the user that this
>> newly defined branch will be presented in colour "branch5". If they
>> aren't happy with the physical appearance, then they'll pop along
>> to the preferences dialog and modify it.
>
> No, I don't like this. The names are too prosaic.
>
>> > My idea was to add to LColor a number of existing colours found
>> > in rgb.txt, suitable as background colours under black text.
>> > These would then be absolute, not logical. Is there really much
>> > sense in allowing the user to redefine these? I mean, they don't
>> > "logically" represent anything, the're just supposed to be all
>> > different.
>>
>> You use a pale background and black text. Someone with poor
>> eyesight will use a dark background and pale text. Your sets of
>> 'suitable' will differ.
>
> Hmm, I see your point. What about then defining formal colours like
> br_red, br_cyan, ... which are nevertheless redefinable in
> Preferences? br_red is supposed to be a sort of red, but contrasting
> with the text, whether black or white. Needs to be set up only once.
Maybe your way is the right way forward: associate a branch with a
physical colour. The only problem then lies in the implementation.
You are restricting users to some subset of available colours chosen
by you. (The choice widget in the dialog.) I wonder if I could create
a colour-picker dialog for xforms, analogous to that in the Qt
frontend? The branch dialog would have a button "color", coloured
appropriately. Pressing it would launch the picker. Returning from
this would re-colour the button appropriately.
The LyX document could also easily store these colours as a
<branch name> <colour>
pair.
--
Angus
