FWIW, the two lines I need to change for my proposal are in ComboBox.C
I was reluctant to do this when I first figured it out (must be about 12
months ago now) because it might affect other combo boxes. It should
probably be implemented as another type of combo box.
I'd suggest using my 2 line change in the main tree until a new GUI indep
dialog has been prepared. Don't just rewrite the existing one, since
it'll have to be made gui-indep anyway -- do both jobs at once.
On Wed, 10 May 2000, Dekel Tsur wrote:
> > I attach a "first attempt" at fdesign.
> > * Inset keys and Bibliography keys are browser windows (Dekel's (1) and (2))
> > * Citation style allows the user to choose \citet, \citep etc. There should be a
> > default here.
Remember that when you implement this you will almost certainly need to
change the lyx file format to support the choice of citation style.
> > * Text before and text after allow the addition of user-specified
> comments. > > Any comments/suggestions/changes? Especially things like
> labels to make them as > clear as possible.
>
> Few comments:
>
> * Make it bigger! I want to be able to see more than 4 keys at once.
We also want to allow room for internationalized labels.
> * You should make your changes over the existing bibforms.fd file (which
> hold the citation form and the bibitem form)
The citation and bibform should be separated into distinct dialogs. They
can share the same definition but shouldn't expect to be able to swap
labels on a shared dialog like we do at present. So starting a new
fdesign is the right thing to do.
Your work should also be done as GUI-indep -- you can reuse or at least
learn how the insets were handled from the old lyx cvs module -- it has to
be done anyway and I want an example of an inset in the tree when the
gui-indep stuff is rolled into the trunk.
The rae branch should be considered closed at this point however. I had a
conversation with the interim gdb maintainer, Andrew Cagney, at the QAUUG
conference yesterday and he confirmed my fears that I have been using CVS
incorrectly. You can't maintain long term branches and merge changes from
the trunk into them and expect CVS to consider that merger as having a new
base. You have to make a new branch and merge the changes from the old
branch into that. Since you also can't name two branches with the same
name without losing history then every update gives a new name and the old
branch has to be closed. I'm not sure it's possible to enforce that nobody
is allowed to commit to a branch it may just have to be a voluntary
agreement.
I'll try extra hard to get a new branch started based on pre2 (is that out
yet? if not Lars maybe you should tag prereleases in future).
Allan. (ARRae)
