On Thu, Dec 05, 2002 at 06:23:17PM +0000, Angus Leeming wrote:
> > lyx_gui::getClipboard(BufferView & bv);
> >
> > lyx_gui::putClipboard(string const & str);
> >
> > What's the problem with doing this ?
>
> There is no problem. I'm glad that I understood the code.
>
> I was merely pointing out that this requires knowledge of the current
> BufferView and I thought that that was something we were trying to do away
> with.
It is only required for xforms. Qt does not need it. Each bufferview can
connect to lyx_gui selectionRequested slot.
Here are the operations and how Qt could handle them (thinking on my
feet ...) :
lyx_gui::haveSelection()
-> tell QApplication
lyx_gui::putClipboard
-> tell QApplcation
lyx_gui::getClipboard(bv)
-> fill bv from QApplication
QWorkArea::selectionRequested (event)
-> fire lyx_gui::selectionRequested
which fires all BufferViews::selectionRequested.
The one that has a selection calls putClipboard
QWorkArea::selectionLost (event)
-> fire lyx_gui::selectionLost
fires all BufferViews to de-select
For xforms, put/getClipboard requires a widget, for some odd reason.
That's where we need to get access to an xforms widget, but this is
xforms only.
> > xforms may indeed need a work area for handling the get/put, but this
> > can be any work_area at all, since it's not workarea specific. Such a
> > requirement should be behind the frontends firewall IMHO.
>
> Sometimes I'm not sure we talk the same language.
Oh, roughly the same ...
> I will note that there's a a one-to-one correspondence between BufferView and
> WorkArea, so I really don't see what point you're trying to make.
That there is no intrisic reason current_view has to exist outside of
frontends/xforms
regards
john
--
"Yeah, I woke up in the day accidentally once, the moon was on fire for some
reason and I couldn't see very well and all the bandwidth disappeared, it was
very scary :("
- Orion
