On Wed, 2 Feb 2000, Dr. Ing. Roland Krause wrote:
[...]
> Well, the question is then how this will work with the proposed
> integration of Signal/Slot for GUII. Much of what I wrote earlier was
> to help me understanding how things work in LyX. I realize that
> LyXFunc plays a central role in LyX because everything runs through
> its dispatch. So when the user presses a button in the menu, the menu
> calls LyXFunc and LyXFunc makes the connection to the appropriate
> method. Realizing this structure I was most astonished and asking
> myself what Signal/Slot is then needed for, since calling a virtual
> method of some dialog base class could be done directly from LyXFunc.
> Then I realized that LyXFunc needs to be called also. Anyway I will
> keep searching since this all doesnt make too much sense to me yet,
> but it got me curious.
You have observed a phenomenon known as "transition".
The menus etc. are all currently hardcoded into the core of LyX like 99%
of the rest of the GUI. Once we have a fully independent system (and
maybe even before) we could either set up a GUIFunc in the common area of
frontends/support (or frontends/common?). We might even be able to allow
the gui-specific menu to directly connect to its associated gui-specific
dialog -- but this will require some careful thought in the plans for
having the menues defined in files (so we can have "native" or even custom
menues. A Word menu format for those people transitioning to the new
world for example).
[Asger, it was Andre']
> No but if too many development branches exist, things may be more
> difficult than necessary. GUII and nonGUI LyX are relatively close
> targets now. Since there is interest in both and code being written
> maybe these things should get testing soon.
I'm not allowing anyones patches in GUII except those that come through
me. Once I'm satisfied the scheme is the right one I'll merge it into the
main trunk. There won't be two branches for long. Although, I will be
testing submitted GUII patches in a separate branch before merging into
the main trunk. So don't worry about there being a fork or some other
major problem. Probably sometime this weekend I'll make a snapshot
available to Michael Schmitt{+} that includes all the latest fixes from
the main trunk and get him to test the libsigc++ stuff. Actually any new
problems introduced by the GUII work should only be due to problems in the
libsigc++ code I think.
> Hmmm, I was not aware that you guys did actual work at this meetings :-)
> He he wish I could participate - maybe if you'd all come to the US.
You just need to find a conference in Europe either at the end of May or
mid-June so you can get "sponsorship". Or do like me and save up your
dollars -- I contemplated swimming last year but I'd still be in the water
now if I had tried.
Allan. (ARRae)
{+} Michael you have cvs access don't you?
