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.
>> Is there a one-to-one correspondence
>> between WorkArea and Clipboard?
> There should be exactly _one_ instance of the
> clipboard per application. This is the case for
> Qt and I would expect it to be the same for other
> frontends.
Then your proposed interface would become something
like:
std::auto_ptr<frontend> frontendFactory();
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.)
> I am quite sure that if I develop that in
> a branch on my own, other developers will loose
> interest. For now, I will do the minimal
> matching for all the frontend but qt4 which
> will have the full monty.
I see, however, that you *are* using your personal
branch. cvslog is telling tales on you ;-)
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 agree that GUII keeps the API stable but IMHO,
> you have to spend two or three more times to
> develop something.
Oh, I agree. I've been advocating killing XForms for
some time and the GTK frontend is essentially
stagnating. However, the LyX team are a conservative
bunch and the collective whole isn't quite ready to
kill them off yet. That's the reality of the world in
which you find yourself, so deal with it ;-)
The plus side of conservativism of course is that LyX
has a reputation among its users for being pretty
solid software. That's not to be sniffed at.
On a different note, I also find myself agreeing with
Georg about this; clean ups are nice but you're not
providing any new functionality here so your goal
should be to create a monotonic improvement over what
exists already. Take your time and do it right. Do it
in a branch ;-)
If you want to get people excited by this work, then
consider what would be needed to make multiple views a
reality. My understanding is that the core is almost
ready for that. (You might ping Alfredo Braunstein who
seemed to have a pretty good handle on what was
needed.) Note that I'm *not* saying that you should
implement multiple views but if you understand what's
needed, it'll help guide your design.
Contrast peoples' "take it or leave it" attitude about
your clean-up proposal to how they feel about your
experiments with QPicture. I'd suggest that if you can
make that work as you hope, then the one real problem
with the Qt frontend would have been addressed. IMO,
there'd no longer be any reason to maintain the XForms
frontend at all.
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.
Angus
