Roland I've taken this to the list since it saves me writing an almost
identical email to explain to everyone else what's currently happening.
I hope you don't mind.
Karl, thanks for your advice. There are a couple of lines relevent for
you below -- see discussion about sigc.m4. I thought you might also like
to know how my plans are evolving.
Everyone, this has grown very long but you should be used to that from me
by now. It should contain just about every tiny bit of detail so there
should be no need to ask questions as they've already been answered ;-)
On Tue, 25 Jan 2000, Dr. Ing. Roland Krause wrote:
> Allan, thanks for your reply.
> Yesterday I took some time to look closer into libsigc++ and I must
> say, that it is pretty good. It is really easy to use and I do not
> even think that it is to large to incorporate. If it really hold what
> it promises then this is definitely the right tool for the job.
I noticed you filed a report to the libsigc++ list.
I've cut down the number of signal and slot templates that are generated
(Signal0-Signal2 only for now -- I don't see any need for more that number
of parameters in our code [one return + two parameters] although that may
change after a long arguement and much swearing) and we only compile it as
a static library that isn't installed. If someone wants a libsigc++
library on their system then they should get the real thing.
> Allan Rae wrote:
>
> > I'll also setup an abstract base class for the Popups to inherit from.
> > That should help insure that they all look roughly the same and may
> > provide other advantages later on.
>
> Have you already done that? I think I saw something like popup.[Ch]?
> Hmm maybe that was something else.
All the work on this is being done in the "rae" branch of lyx-devel.
I haven't committed it yet but I do have libsigc++ integrated on my
machine at home. I have started on building the gui-indep structure and
currently have a new Popups and PopupBase (the abstract base class).
The first draft of libsigc++ integration uses a slightly modified version
of the libsigc++ configure.in in the sigc++ directory. Hmmm, does NT let
you have a directory called "sigc++"? What about OS/2?
I'm planning on reworking the sigc++/configure.in and creating a sigc.m4
like the gettext.m4 which provides an AM_WITH_SIGC. This is mainly to
work around a couple of tricky "chicken-and-egg" problems and to help
reduce the size of our dist. Things like duplicated compiler tests and
two copies of libtool etc.
> > I've started work on incorporating libsigc++ but I won't be merging into
> > the main trunk before 1.2.0 -- unless 1.2.0 is considerably further away
> > than I think it is.
>
> Is there a 1.1.5 before 1.2.0 - if so why not introducing it there. I
> dont think it will really break things.
Perhaps, but I want to be sure it's good before making it mainstream.
After all I expect the floodgates will open with heaps of people
scrambling to force their favourite toolkit to be top-dog and convince us
to completely ditch xforms and half the existing codebase.
As I said before I want to filter the popup work and am trying to get a
base where we can have popups from different toolkits co-existing although
I don't want to allow a new popup to replace a hardcoded one until the
hardcoded one has been made gui-indep. That sounds a bit conusing let me
try that again: gui-indep popups from multiple toolkits will be supported
but will only be visible once the existing xforms popup has been made
gui-indep.
> > The simple trick I employed for gui-indep popups was to say that as
> > far as the kernel is concerned we just need to tell a popup to show
> > itself and to tell those popups that are interested when the buffer
> > has changed. So the signals generally don't carry any information.
> > The second thing is that any popup must be able to do 3 things:
> > show itself, hide itself and update itself.
>
> Alright - so these are virtual functions of the base class popup.
Yes.
> > These 3 are made targets of signals. A popup specific signal for showing
> > the popup and whichever of the two hide or update signals in Popups that
> > is appropriate.
> >
> > A popup retrieves the data it needs from the kernel. Andre described this
> > as a Pull method a few months ago. In fact one is his emails is on my
> > list for inclusion in the docs.
>
> That is - the popup knows where to get the necessary information to
> update fields, buttons etc. I understand. With the signal/slot
> mechanism it could have been sent this information but pulling is
> safer I guess.
It's also a question of just how extravegant we are willing to allow our
signals/slots to get -- how many parameters we're willing to pass.
Also if we only push info down the wire we have to push different info to
each popup separately we lose the extremely simple interface of calling
one Signal0<void> updateAllBufferDependent which will call all the
_visible_ popups. If we tried to support push to popups we would
have to push to each and every update signal just in case that popup is
visible -- if it's not visible it doesn't need updating, in fact if it's
not visible it probably hasn't even been created yet. Calling a signal
that doesn't have anything attached isn't a problem it's the cost of
building the data to pass as parameters that are never used that is the
problem.
Push is useful for some specific cases like table-cell updates in the
table popup and character attributes in a character toolbar but even then
it should only need a limited amount of info to pass to it.
Oh and the popup will get its info from a LyXFunc. We used to use a
separate class called Communicator but I've since decided that was a dumb
idea as a LyXFunc will be available to scripts and the outside world via
the LyXServer.
> > > > It's probably a good idea if you at least familiarize yourself with
> > > > the Popups class and try to figure out for yourself why it works.
> > > > (and how if you like).
>
> As far as I can see there is no such thing as one popup class in
> lyx-devel yet, or am I wrong and if so could you tell me where to
> start looking for it?
I meant "class Popups" in lyx/src/Popups.h and
lyx/src/frontends/xforms/Popups.C in the lyx module of cvs.
I'll probably commit the new stuff over the weekend and then you'll be
able to see the new code.
> > Popups.C has a lot of comments. Probably easiest to start by looking at
> > the copyright popup since it is the simplest -- and see where it's
> > called. If you're adventurous you might want to check how Popups is first
> > created and follow how the popups are initialised -- but this isn't really
> > necessary for just creating new popups.
>
> But that is the old development branch or?
Yes old branch.
> > > > You could get a copy of libsigc++ and take a look at the gtk--
> signal/slot > > > adapter they have there -- in examples/ I think.
> Since that is pretty > > > much what we'll use. I don't know that we
> need all the fancy capabilities > > > of libsigc++ but then again it
> might be wisest to use the revised > > > interface it offers.
>
> Why not using the native signal/slot mechanism that they provide? Do I
> misunderstand something here. From what I see this should be far
> easiest and it is as you said just a few lines of code. Maybe we can
> get a prototype into the exisiting codebase. Say we'd create a virtual
> base class for all popups that inherits from Object:
Yes, I've since changed my mind and we'll just use the libsigc++ notation
and forget the whole gtk--sig thing.
> class Popup:public Object {
> public:
> Popup () {};
> ~virtual Popup () {};
> virtual void show()=0;
> virtual void update()=0;
> virtual void hide()=0;
> protected:
> private:
> Popup(const Popup& p);
> Popup operator= (const Popup& p);
> };
>
> already slots can be created for show() update() and hide(). Do I get
> the idea?
Gosh! You wrote PopupBase and called it Popup!! Yes, you get the idea!
Although I'm thinking about adding another member and also something very
naughty: a data member, although I might just leave it as an enum and not
have the data member. Using a PopupBase class I can cleanup Popups
considerably and each port can its various popup/toolbar classes by
whatever name they like.
> > Yes and no. Libsigc++ is very advanced and we probably won't use most of
> > it's capabilities however there are some perl scripts that can convert the
> > gtk-- style sig/slot code into the libsigc++ code. In fact gtk-- have
> > stopped using the connect_to_method etc. functions and just use the
> > libsigc++ interface. They wrote a perl script for converting.
>
> I think that's what we should do. It looks so simple - makes me think :-)
Well I used a modified form of the convert.pl script from libsigc++ that
converts to newish gtk-- format but there's a better script from gtk--
that converts old stuff to libsigc++ stuff and that'd make for an even
better patch than the one I generated last week.
> > What toolkit would you like to work with?
>
> Probably wxwin or qt - maybe even MFC I havent really decided yet.
MFC sounds good. Qt costs money on Windows. MFC is everywhere and it is
_the_ native toolkit after all. Besides Asger has said he's interested in
doing/helping an MFC port as has someone in Sweden(?) who's willing to pay
people to work on it! Might be a short-term job in it for someone.
> > Followed by Popups.[Ch] and src/frontends/[xforms,kde] and an example of
> > how to use both kde and xforms together. This will be tricky initially
> > but I think I'm going to have to allow people to develop with whatever
> > toolkit they like rather than force them to help get the xforms stuff
> > separated first -- since nobody could be bothered to help the first time
> > around I can't see hoards of people helping this time.
>
> I have promised it before and sometimes my timeframe is changing a lot
> - but I'll see that we can get this of the ground. Once the GUI
> independent stuff is on the way there will be more contributors.
I still don't think they'll want to do the extraction work.
> > > PS: Good luck with your thesis:-) Dont let this keep you from the
> > > important things.
> > Don't let the thesis stop me from working on LyX? I try not too ;-)
>
> :-)
I'm seriously considering suspending my enrolment for 6 months. I'm
working part-time and haven't really done anything constructive
thesis-wise (or otherwise) for at least the last 6 months. The last
subtopic of my thesis crashed and burned so I've lost a lot of interest in
working on it. Besides it seems half the world is waiting for me to get
this gui-indep stuff back on the rails. May as well work on something
that brings some joy and satisfaction and then reassess my thesis in a few
months.
Allan. (ARRae)
