Angus Leeming wrote:
The gmane interface remains down. Sorry about the mess
I'm making of message threading...
Abdelrazak Younes wrote:
Angus Leeming wrote:
However, what happens when we have multiple
views onto a document?
AFAIU, views and workarea are not the same.
views are handled by the core and workarea by the
frontend. Two workareas can work on the same
document independently.
Only the contents should be synchronized (a la
EMACS).
There's a one-to-one correspondence between visible
BufferViews and WorkAreas. A buffer can have multiple
BufferViews, not all of which need be displayed. A
BufferView that is displayed will be displayed on a
WorkArea that is assigned to that BufferView.
At least, that's how I see this all panning out.
Yes, I think I have the same understanding.
Then your proposed interface would become something
like:
std::auto_ptr<frontend> frontendFactory();
I am not sure yet how this instantiation would be handled as this might
conflict with Georg' recent initialization patch.
class frontend {
public:
virtual ~frontend() {}
Clipboard& clipboard() = 0;
WorkArea& workArea(lyx::size_type id) = 0;
Screen& screen(lyx::size_type id) = 0;
};
Or do I miss something? (Note that I imagine that the
frontend would manage the creation of new workAreas,
screens if it were passed a new-to-it "id" parameter.)
Yes, something like that. I see that you prefer reference type API
instead of pointers... that's fine with me. I am not so sure about
screen though. I guess the rationale behind the screen/workarea
distinction is that a screen has the focus. So screen would always point
to the WorkArea that has the focus. That said, I really don't see why a
cursor should not blink because its workArea doesn't have the focus. I
still don't understand what the Screen is useful for... Somebody could
enlighten me?
"workArea(lyx::size_type id)" would automatically create a new instance
if not in the internal map. That should work pretty well. I already have
a vector of WorkArea in my qt4/Application class, I will switch to a map
instead.
At the moment your ideas aren't thought through. I'd
suggest that you use your personal branch to create
the interface and a sample, Qt4 implementation and
then follow Michael Gerz's lead in merging your work
back into the truck. If the merger proceeds slowly,
and if you provide a prescription for what needs to be
done in the other frontends, then you'll make
progress.
I reserve my opinion on that branch business until I see how Michael's
work will be merged and until I see other people helping me.
I don't suppose you need much more encouragement on
that front ;-) Dive into the core and find out what
needs to be changed to make your QPicture work.
Nope and I hope Peter will help me on that.
Thanks,
Abdel.
