On Sun, Mar 10, 2002 at 03:41:03PM +0000, John Levon wrote:
> The big one turns out to be the relationships between BufferView_pimpl,
> WorkArea, and lyxscreen.
IMO the work area should have total control over lyxscreen (i.e. it not
even need exist for the qt frontend) and it should handle expose events
itself.
This means bv->getPainter() needs changing. In particular the Qt way is
to instantiate a QPainter only when it's needed (could be represented by
Painter & startPainting() and endPainting() pair in bv, or ...)
I've started a tasks page, attached. Comments please.
thanks
john
--
I am a complete moron for forgetting about endianness. May I be
forever marked as such.
<?
// What's the title of the page?
$title = "GUI Independence Tasks";
// What's the short name of the page in the navigation bar?
$item="GUII Tasks";
// Who is the author?
$author="[EMAIL PROTECTED]";
// Full name of the file (relative path from LyX home page -- i.e., it should
// be "foo.php3" or "bar/foo.php3")
$file_full="guii-tasks.php3";
include("start.php3");
?>
<p>
This page details the tasks necessary to get GUI independence. See also the
<a href="guii.php3">dialog matrix</a>. The dialog work is essentially complete in
design terms.
<br />
This page is most definitely a work in progress...
</p>
<h2>ColorHandler</h2>
<p>
This class caches GC's and is only useful for the xforms frontend, so needs
to be moved there. Painter is the only serious user of this class, so most
of it goes away with a GUII painter.
</p>
<h2>Painter</h2>
<p>
This actually paints stuff. There is a difficulty with the Qt frontend in that
this needs to get access to the WorkArea/screen widget so it knows where to
paint. The current heirarchy doesn't allow this. The painter to use needs to come
from the WorkArea widget.
</p>
<h2>WorkArea</h2>
<p>
Geometry management, events etc. need to come from the toolkit. This is actually
quite easy due to the signal/slot mechanism in place already, with the exception of
expose events. Eventually canvas widgets should be real QWidgets but this isn't
necessary for a first iteration: we can continue to use the manual mechanism.
</p>
<h2>LyXScreen</h2>
<p>
This has no real reason to be represented at the GUII level at all, as far as I
can see. The work area widget should manage this, calling the relevant LyXText
drawing routines when necessary.
</p>
<h2>LyXView</h2>
<p>
This is mostly done, just a few tweaks I think. This class creates the main window
and instantiates the WorkArea, menubar etc.
</p>
<h2>BufferView</h2>
<p>
A few dependencies on X need removing. the painting of the work area needs to be
managed
in work area itself, rather than BufferView doing it.
</p>
<h2>lyxfont</h2>
<p>
The interface is OK I think, undoubtedly needs some tweaking.
</p>
<h2>LyXFont</h2>
<p>
?
</p>
<h2>FontLoader</h2>
<p>
Qt manages this itself, only really needed by xforms.
</p>
<h2>LyXLookup</h2>
<p>
xforms-specific (possibly). Someone needs to work out RTL etc. for Qt, this can get
done
later.
</p>
<h2>Minibuffer</h2>
<p>
Needs splitting into two parts for GUII.
</p>
<?
include("end.php3");
?>
