--===============1240038467==
Content-Type: multipart/signed;
  boundary="nextPart4370175.vBMVZ1kR4l";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart4370175.vBMVZ1kR4l
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 13 October 2006 22:10, Boudewijn Rempt wrote:
> But=20
> really, I think life would be a lot easier if we would actually have a
> proxy. Look at your own KWord code below: those lines would need to be
> duplicated in all canvas implementations in KOffice. Better have it in one
> place in KOffice, so there can be no inconsistencies between applications.
> Especially the code that handles the tablet proximity events!

The code I pasted didn't handle the tablet proximity events. That would be=
=20
handled by the tooManager already.
The pasted code does nothing but forward to the current tool. With a switch=
=20
for the tablet version since there Qt doesn't split the different move/etc=
=20
events.

Really I don't see the problems you think there are. Its just simple wrappe=
r=20
code. Adding a layer of abstraction (the proxy) makes things slower by addi=
ng=20
several items to the call stack. And since you were earlier worried about=20
doing a dynamic_cast I'd guess this is equally important.

> > So, the KoToolManager can just have the factory method for our event and
> > keep on using the member of the canvas to actually forward the events t=
o.
> >
> > Note we will not eliminate the usage of the m_tool member in Canvas even
> > if we stop forwarding events directly from the canvas.
>
> I was wondering about that -- what does the canvas actually use the tool
> for?
If you read the KWCanvas you'd see at least a paint on the m_tool.

> > I think you misunderstood. Nothing goes via the toolManager.
>
> Well, you were a bit inconsistent, but I liked the idea of going through a
> proxy (and the toolmanager seems the right place for that) much more than
> the factory idea.

If pressed, I'll have no objections to a proxy. I just feel its adding API=
=20
thats confusing for only gaining at max a dozen lines of code each canvas.
But you do this coding, so fee free to ignore this point :)

> Er... Experience learns that determining the current tool is everything b=
ut
> an atomic operation and that a mess will invariably result if there are t=
wo
> classes that keep the notion of "current tool" in their private variables.

Well, we both have >20 years of programming experience. Chances are we both=
=20
have very good reasons and are both equally right in most cases.
So, lets make sure we respect each others design and follow its lead when=20
building on top of, or extending the others code.

Cheers!
=2D-=20
Thomas Zander

--nextPart4370175.vBMVZ1kR4l
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBFL/3gCojCW6H2z/QRAmU0AKDfGtf/R9qWmLn9VnwIfw/t3xvVAgCg68x6
UGLrFED9haN9lBmXkXUvx20=
=yxdW
-----END PGP SIGNATURE-----

--nextPart4370175.vBMVZ1kR4l--

--===============1240038467==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

--===============1240038467==--