Baruch Even <[EMAIL PROTECTED]> writes:
| > | We should try to have the next version stabilized soon so that our users
| > | who want something better than 1.1.5fixN will be able to upgrade. The
| > | tables code in 1.1.6fix2 will not have all fixes and we need to
| > | stabilize that before we go on.
| >
| > Things I'd really like to see before 1.2.0:
| > - GUI support for creating user defineable float types
| > - Stabilization of the mathed changes. If this cannot be
| > provided we have to move back to the code n 1.1.6.
| > - InsetGraphics support finished. InsetFigure removed
| > completely.
|
| I would suggest leaving InsetFigure dormant at that stage and not
| removed, just to avoid the problems that the table experienced,
| InsetGraphics is far simpler than the Table but still. It will cost
| nothing to keep it in (except a bit of compile time and executable
| size).
I agree on leaving it dormant (for a short time), but I don't agree
that this will avoid any problems...
| > - Rest of the small stuff moved GUII.
| >
| > btw. The minibuffer is almost ready for GUII, should now be quite easy
| > to split in gui/non-gui.
|
| The minibuffer has a small bug that it cannot accept parameters with the
| command. When I did the python-function stuff it tried to match the
| whole command and parameter for the commands and failed for obvious
| reasons. For some reason mathed commands can continue to get
| parameters. I ended up fixing it by spliting the line on the first space
| and then combining it back before sending it to lyxfunc. Ugly.
This is not really a bug.
The intention is that in the minibuffer you will not be allowed to
enter "free text" strings. i.e. lfuns with arguments, but will _only_
be allowed to enter the lfun. If the lfun requires an argument it will
be asked for (or more than one). To do this the information we keep
about each lfun must also hold the number or arguments and their type.
Not hard to do, but I need some time...
--
Lgb
