Allan Rae <[EMAIL PROTECTED]> writes:
[I dropped the sigc++ 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.
Agree. So you are not letting the included sigc++ use its own
./configure? Ok that seems like the best way. Some work needed to the
the correct autoconf macros in place then.
| 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).
Even I managed to checkout the rae branch now. :-)
Feel free to commit at any time.
| > > 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.
I at least expect several versions before 1.2.0.
| 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.
There are also some other very important things that is closely
releated to gui-indep that needs to get done before the ball can begin
to roll: the lyx painter, new menucode, new toolbar code.
Also the gui initialization needs to get cleaned up.
| 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.
One other approach is to just not show the popups that has not been
implemented yet for the given tk.
As as been shown earlier having two toolkits running at the same time
is not always possible, and on some systems impossible. (MFC port)
| > 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.
There is the possiblity of passing objects.
| 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.
True.
| 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 is possible that when setting paramters we will do that using
lyxfunc too.
| I'll probably commit the new stuff over the weekend and then you'll be
| able to see the new code.
mmmm
| and forget the whole gtk--sig thing.
Good!
| Gosh! You wrote PopupBase and called it Popup!!
I have thought a bit about this, and perhaps we should switch to the
more generally accepted term: "Dialog".
Popups are really something else...
| Yes, you get the idea!
| Although I'm thinking about adding another member and also something very
| naughty: a data member,
Hey! forget that.
| 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.
Hmmm a fulltime LyX developer would be nice :-)
I have been planning to begin the gui-indep work for some time, but so
far there have been other task that has been crying to get done. As I
see it have no finished a lot of the cleanup that was needed, and we
can begin to focues (slowly) on different matters.
So my simplistic plan is now:
- release 1.1.4
- include the hebrew patch.
- remove some code cruft
- new prerelease
- release 1.1.5
- work on the painter
(get asger to tell be what the painter/painterbase lack to
work on more platforms/toolkits)
- work on the toolbar
- work on the menubar
Hmm I seem to one task I really would have liked to have done:
- get rid of current_view.
(I think I will work on this too before 1.1.5)
Lgb
