Barbara,
Again, this was great...
In a message dated 2010.06.13 10:59 -0500, Barbara Duprey wrote:
There may be no compelling reason, but I did think the recovery
aspect [has] a real benefit. As I indicated, the current system does
leave the possibility of having closely related documents recovered
to different points in the workflow. Other than that, it's a
convenience issue -- not having to come up with and remember
different names for all the documents, and not having to use multiple
actions for opening and closing. For two or three, it's not a big
deal, but if you have a fairly large set it could get tedious.
That alone is already a very interesting way to think about this, beyond
what Dotan originally proposed (or at least draws out more explicitly an
advantage implicit in the original proposal). But then you make the case
even more powerful:
If this were done with an eye towards increasing modularity of
functions, so they are done under a common interface and with
common code, there could definitely be advantages.
Yes! - a common theme on this list. [Cf: Impress v Writer, Calc v
Writer, etc.]
I know there is a lot of common code already, but I'm guessing that
there are also plenty of similar capabilities that have diverged over
time. For example, I'd love to see Writer tables able to use the
formula replication aspect of Calc.
Or even - if it is not practicable to use Calc and tables
interchangeably - to be able at least to copy a table into Calc and have
it reliably recognized as such(*), or to link in at least one direction,
if not both.
[(*) "Reliably recognized" by Calc as a table means that Calc should
reliably accept a Writer table of N columns by M rows into a Calc space
of N columns by M rows. I have never been able to figure out why some
examples work and some do not work to file a bug report, but the fact
that this often does not work seems a weakness of the common model.]
An extension or purely packaging fix would be more on the lines of
what we used to call "quick and dirty" -- but certainly might be
useful to some people as an interim measure.
Yes; I think Dotan might have been thinking in those terms, and might
well settle for that now. However, thank you for making the larger
case: that it is in the interest the whole OpenOffice project. From a
modest proposal, this could be one of those seminal cases that clarifies
a paradigm. One can imagine OO being both lighter and more capable as a
result.
Thanks for being a technically eloquent advocate,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@openoffice.org
For additional commands, e-mail: users-h...@openoffice.org
