Martin Vermeer wrote:
> Eh, why would you want to nest branches? Now, nesting notes in
> branches vv. etc. must work right, and I had to work to make it so.
Don't know. Well, maybe I do. Imagine the doc team wants to use branches for
different frontend description and the differnences betwenn qt/pc and qt/mac.
They define a branch qt, a branch xforms and a branch mac and a branch pc.
Then they could write:
"To change color settings, you have to use the preferences dialog, which you
will find in <xforms>Tools->Preferences->Look&Feel->Colors</xforms>
<qt><pc>Tools</pc><mac>LyX</mac>->Preferences->Colors</qt>"
Note that qtmac and qtpc would be not the same, since the qt frontends looks
mostly the same, except for some small differences.
Anyway, it works, so there's no need for reasons :-)
> > A few remarks concerning the ui though:
> >
> > - what is color supposed to do? I cannot see any color on screen or dvi.
>
> Save and reload. Or create a new branch inset. Unfortunately I haven't
> managed to make it so that the colour of a pre-existing inset can be
> changed. There must be a way... perhaps by handing the branchlist in
> the bufferparams as a pointer, not a physical object. Too difficult
> for me :-(
Hmm... I cannot get it to work no matter how often I save/reload.
> > - Is it necessary to hardcode the color to those six? If this concerns
> > screen representation, I'd like to use a real color selector (like in
> > prefs).
>
> Probably. Why not. But how to save the colour into the doc file?
> Having the colours named has value. What If I extend the list of
> available colours to include more rgb.txt entries? Note also that blue
> and red should probably go as they are too dark for background.
Don't know. Isn't it possible to save a color "foo" with the rgb values
(x,y,z), maybe as a branch param?
> > - I do not like the branch selection ui at all. In qt, I would probably
> > use a QListBox (browser widget) instead of the choice_all_branches. All
> > branches would be listed there and the user can select multiple of them
> > (QListBox allows multiple selections). That's it, no second choice
> > "all_selected", no checkbox "check_select_branch". In xforms, if multiple
> > selections are not possible, I'd really recommend a two-browser-approach
> > like the citation dialog has. Like it is now, it is really very confusing
> > IMO.
>
> Yes it is a bit primitive. But it is meant only as a first try.
> Unfortunately I have not much time to work on this from home, and my
> X11 connection over dial-up is extremely slow. So I went for a minimal
> solution that works.
Fair enough (though I don't think that a browser approach is much more
difficult).
> BTW if multiple selections don't work, you could at least have a
> second browser widget displaying all_selected. But you still need the
> add/remove button functionality in addition. Perhaps instead of the
> check button we could have select/unselect buttons.
Yes, that's what I meant with the citation dialog approach.
> > - I think the menu item should be disabled if there are no branches
> > defined.
>
> ...but how do you get started then defining your first branch?
Document->Branch. Unless I have not defined a branch there, I cannot insert a
branch inset. Looks like a sane approach to me.
> > Actually, an enhancement would be to make a branches submenu where the
> > user can select a branch from the list. Branch "none" does not seem to be
> > very useful to me.
>
> No... but note that you cannot actually select it. Taking the first
> from the list upon creation of the inset is a little arbitrary too.
Why not having some ui like this:
Insert
...
Branches >
1. qt
2. xforms
3. pc
4. mac
(like the "paste recent" submenu). Of course this list needs to be limited.
> > That's all from a first glance. Did I mention that I really like it? ;-)
>
> Enough to kick up a prototype of a two-browser UI? ;-)
Did I mention that my PhD timeline ends next month? This is what I have to
kick up first I'm afraid.
> Did I remember to thank you for valuable testing work? ;-)
My pleasure.
Regards,
Juergen.
> Martin
