2010/10/23 Povilas Kanapickas <email@example.com>
On Sat, Oct 23, 2010 at 1:42 PM, Ian <firstname.lastname@example.org> wrote:
On Sat, 2010-10-23 at 01:58 +0300, Povilas Kanapickas wrote:
all, Office suite should include a tool to make at least moderate
schemes and similar things. That tool should be also integrated within
suite, so it'd be possible to edit embedded graphics directly.
Yes but ideally also able to stand alone from the suite for use in other
circumstances. Integration through internal messaging between
applications is perfectly possible. In Inkscape, raster graphics can be
embedded and various effects applied through the extensions. I can't see
it being impossible to add editing as another extension but maybe a
better approach is to communicate with other editors already in
existence. Embedding pngs seems to produce svg flies about 30% bigger
than the originals from a quick and unscientific check. Double click a
graphic and automatically open it in a raster editor would be another
possibility with "save" returning the edited image back to Inkscape.
That would require some open standard protocols to be defined for
transfer of data between apps (if it doesn't already exist). Drag and
drop between different apps supporting the standard would be another
possibility. It's really only a way of short-cutting cut and paste.
By saying 'integrated' I didn't mean that we should have one application to
do all the things. I meant that the interaction between these two
applications should be polished. The word processor and drawing application
must be able to work independently (and be installed as such). But when the
user wants both of there two applications for one document, he shouldn't be
forced to do awkward things such as to open the drawing
application manually and so on.
This reminds me of a good presentation on how applications' features tend to
overlap and how, ideally, they should integrate with each other instead:
Ideally, LibO should have a practically unlimited feature span. A user
should be able to get to every command that's POSSIBLE, not just built in.
The goal would be to have a search box that would do everything. A user
would type "Make this text bold" and a result would come up that would make
his text bold. Ideally, there should be even results for vague entries, like
"Make this document pretty" -- that should at least return a result with
How would that be done?
Well, there is a bunch of OOo tutorials, guides, and walkthroughs online
already, and this number will only get bigger. If the creator of these could
only in some simple way mark the actions described in the tutorial for LibO
to read, LibO could reproduce all the steps taken in the tutorial.
This kind of tutorial could also use commands from third-party extensions
How would this tutorial get made? I'm thinking a simple extension that gives
you a "Record my steps" button.
powerful the integrated graphic editor is, the less there will be users
need to do the 'long trip' just to edit a graphic object (by saying
trip I mean deleting the object, finding the image in the file manager,
opening it, editing, embedding into right location and adjusting image
parameters). This is the reason, why the solution 'Let's just have
leave Inkscape for the advanced users' isn't viable. In addition to
why to decentralize the (scarce??) resources available?
Of course, I wouldn't be saying all that if there were usability
with Inkscape. But IMHO it has quite low learning curve while providing
lot of features.
Agreed. What we need is innovation to get away from the megalithic
approach and build cross platform standards that support data messaging
between applications. Then smaller applications that are easier to
develop and manage are possible, working together or apart as required.
With phone technologies moving into the computer space this becomes more
important to help with power consumption, cost etc.
Exactly. Actually that's why I'm advocating for using external graphics
such as Inkscape. Inkscape is too big that it could be merged with LibO,
even if we wanted. The only way for LibO to work with Inkscape is to
an API and to make Inkscape to use it. Then, since the API is the only link
binding LibO with Inkscape, it would be very easy to add support for other
tools. Ideally, the user could choose whatever supported graphic editor he
wanted and to have good user's experience at the same time.
E-mail to email@example.com<discuss%2Bhelp@documentfoundation.org>for
instructions on how to unsubscribe
List archives are available at
All messages you send to this list will be publicly archived and cannot be
E-mail to firstname.lastname@example.org for instructions on how to unsubscribe
List archives are available at http://www.documentfoundation.org/lists/discuss/
All messages you send to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] UI proposal · Charles Marcus
Re: [tdf-discuss] UI proposal · Charles Marcus
Re: [tdf-discuss] UI proposal · Marc Paré
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy