[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    RFD: loading/pasting/DnD in Flake?
From:       "Benjamin K. Stuhl" <benjamin.stuhl () colorado ! edu>
Date:       2006-08-21 15:50:37
Message-ID: 20060821095037.4f99d0ca () localhost
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


All --
  So as ThomasZ continues to run ahead with kotext2 and .kwt loading
(very nice, by the way! ^_^), it occurred to me that that loading code
(and therefore pasting and DnD-accepting) for a given flake should
probably all be in the associated tool? It doesn't make sense to have,
say, multiple copies of the .odt style and text-loading code running
around, but every writable KoTextShape should, IMHO, be able to accept
(e.g.) text/plain, text/html, and ODT text pastes and drops. However,
given ODF embedding semantics, we can't just hand a raw ODF chunk to the
KoTextTool and expect it to completely deal with it: what if there is,
say, a formula embedded in that chunk? Also, what about pasting? Do we
need an explicit notion of a cursor, or do we just define that loading
a chunk of data into a Tool is defined to always occur at the current
insertion point, overwriting any preexisting selection?
  Also, what about the flip side? Tools should probably know how to
serialize their shapes, too? (After all, the tool is the logical
element to provide data sources for cut/copy operations, and probably
should be responsible for saving its shapes, too?)
  Some other possible complications to further muddy the waters:
*  multiple clipboard formats: both copying and pasting... and an
application should be able to provide a "Paste as..." menu, with e.g.
"Paste as... -> New Frame" and "Paste as... -> Unformatted Text" for a
rich text clipboard item in kword.
*  embedded objects and object references in ODF: how does a tool pass
back an unhandled object (e.g. a formula in an ODT document) to hand it
off to another shape? what about a reference, like an image in an ODF
document?
*  consistent menus and DnD behavior: should menus (like "Paste as...")
and drops be under the control of the tool or the application? Perhaps
give them to the application, but let the application delegate to the
tool if it can?

That's probably enough problems for one day, so all you folks who were
at the Flake meeting, let me know what you think! ^_^

Thanks,
-- BKS

["signature.asc" (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]