Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Let me start you off:
class GUI {
This is my BaseFrontend class, do you prefer BaseGui instead?
Having slept on it, I think I prefer "GUI" rather than "Frontend".
If you let me choose something then that would be "Gui" not "GUI". Agreed?
We used to
have BasePainter and Painter and people ended up disliking it intensely. (This
was in the days when core and frontend were intertwined; people ended up using
"Painter" when they should have used "BasePainter".) So, on reflection, I think
that the files in src/frontends should be "Base-less".
Now don't tell me that's a pain. It's 5 minutes to write the script ;-)
May I recall you that I chose the BaseXxxx naming just to please you? ;-)
> and I would call the virtual interface lyx::frontend::Window and the
> implementation lyx::frontend::qt::Window ;-)
I am perfectly fine with this but note that this could pose problems WRT
include paths ordering. In principle not because '.' should have
priority over anything else but who knows...
So, everybody, if you don't like this naming scheme, please tell it *now*.
I think this should be merged with the Clipboard class as Qt4 does
LOL! What an ugly interface! And you go from compile time checks to run time
ones. So, no, I think you should have two classes.
OK.
(Your Qt implementation could
use a shared_ptr<QClipboard> if you want them to use the same QClipboard?)
No, the QClipboard instance is unique per application and can be
accessed by qApp->clipboard(). That's what I am doing in my Clipboard class.
Anyway, moving on...
* (Should the GUICursor be owned by the WorkArea then?)
No, only connected to it by the owner when the kernel commands a
switching to this WorkArea.
Hmmm. Each WorkArea "has-a" GUICursor seems like a natural fit. The frontend can
tell the workArea that it is now "active" and the WorkArea will change the
cursor appearance. I guess that there's the corresponding issue of telling the
old work area it's now "inactive"...
Things to mull over ;-)
For qt4 the inactive state is as simple as letting the cursor visible
(without blinking). Once/if we remove the blinking management from the
kernel, the frontend would decide how to show the "inactive" state by
itself.
I would call that View for the implementation and BaseView for the
virtual interface.
Thanks for the help,
No worries. I'm doing some boring stuff here and you provide me with light
relief ;-)
Ahhh the joy of coding ;-)
Abdel.
