My little test program to load graphics asynchronously to produce a pixmap of
a given (requested) size seems to work beautifully although the logic is a
little hard-coded at the moment. It also has a daughter ChildProcesses dialog
that displays all currently running forked processes and can be used to kill
them. (Asger Feature Request!)
I have given a little thought to using the greater capabilities of (eg) the
Qt library to load different graphics formats itself (asynchronously of
course) and produce a resultant pixmap of the desired size.
A GraphicsCacheItem instance should take some input graphics file. It can
either produce a scaled pixmap directly if it knows how to deal with this
input format, or it needs to define a conversion process run asynchronously
through execvp.
For those simpler GUI libraries like xforms, the only allowable image format
is scaled_xpm. Converters need to be defined from the input format all the
way through to scaled_xpm. Eg,
eps -> ppm, using "convert $$i PPM:$$o"
ppm -> scaled_ppm using "pnmscale -xysize $$w $$h $$i > $$o"
scaled_ppm -> scaled_xpm using "ppmtoxpm $$i > $$o"
My little program does exactly this at the moment, although the conversion
script is currently hard-coded. I think that the logic is in place however to
modify the converter class to produce a shell-script automatically. This
script is then run through execvp.
More powerful libraries like Qt could probably act on most input graphics
formats direct. I haven't given much thought to the details.
I've taken the opportunity my little program to also explore some of the
remaining issues with LyX's frontend, namely:
* How do we control a generic Main dialog?
It should have show() and hide() methods. The hide() method tells
closes all daughter dialogs and tells its owner that it can be deleted.
More specific Main dialogs (eg, LyX's and this apps') derive from this
simple base.
DONE.
* A better way of posting multiple Error and Message dialogs.
I was thinking of defining a messagestream class. Its user-semantics
would be something like:
messagestream lyxmsg;
lyxmsg[LyXMsg::ERROR] << "This is a horrible mistake << popmsg;
lyxmsg[LyXMsg::WARNING] << "this is ugly but ok" << popmsg;
lyxmsg[LyXMsg::INFO] << "You might find this info useful" << popmsg;
messagestream would be connected to the active LyXView.
If it was not connected, then messages would be posted through
lyxerr.
If is was connected, then closing the LyXView would close these
(daughter) dialogs.
They control there own destruction. Ie, "hide" destroys the dialog.
VAPOURWARE
* A better way to browse file lists.
Should be able to have multiple instances of the File Browser
open, connected to the dialog that posted the "Browse" request.
They should not block future action, but should emit a signal when
there own Apply button is pressed.
They should also control there own destruction. Ie, "hide" destroys
the dialog.
VAPOURWARE
Ultimately, my aim is to create a small, stand alone app that "solves" these
remaining frontend issues.
Any comments? Am I thinking along the right lines?
I'm away in South Africa for a couple of weeks as of the end of this week, so
won't have much time to do any of this for a while, but thought I'd post a
road plan (for my own benefit really!)
If anyonw wants to tinker with some source code (eg give this thing a Qt
frontend --- a truly GUI-independent app using the LyX model to
GUI-Independence) then drop me a line. I think we could go a long way to
finishing off a lot of the GUII stuff in the process.
Angus
