On Sun, 13 Aug 2000, Baruch Even wrote:
> The real question is whether the external inset has a use beyond that of
> inserting graphics files?
Obviously, 90%-95% of the uses of the external inset will come with
a graphical image:
- Raster format images (jpg, png, gif, tif, etc.)
- Vector format images and diagrams (svg, ps, xfig, dia,
chess boards, electronic circuits)
However, the external inset can also be used for non-image stuff:
- Time/date
- Chemical formulas
- Music score
- Database queries
etc.
Basically, the inset supports an hook for external material
to get into your document in a potentially dynamic way.
Therefore, this feature is essentially more general than
just a graphical image inset.
But this is not the primary reason for the existance of the inset!
The external inset is meant to lower the barrier for extending
the functionality of LyX.
Let's write that in a box:
+-------------------------------------------------------------------+
| The external inset allows you to extend the functionality of LyX! |
+-------------------------------------------------------------------+
For instance, with this feature it is easier for hackers to finally
interface LyX with their mail-database and produce mail-merging without
hacking the C++ code.
I consider it a light-weight instance of the different component
technologies developed in Gnome (Bonobo), KDE (KParts), Windows (COM,
ActiveX, OLE), and so on. The principal advantage of the external
material inset is that it is a light-weight mechanism. It provides just
enough hooks to be interesting, but the emphasis is on light-weight.
In it's current form, it is not meant to be the end-all, be-all inset.
For starters, it is developed to be minimal, but at the same time useful.
Over time, I hope it will develop to become the ultimate inset, but
this should never come at the sacrifice of the usability of LyX. More on
this below.
> If they both insert graphics files then they should be merged, otherwise
> they should be somehow differentiated, I suppose most users will be
> baffled with both an external inset and a graphics inset used both to
> insert graphics when the external inset can do a bit more.
For user interface reasons, it is indeed a good idea to provide
a taylor made graphical image inset, such as the inset you
are developing. I'm not proposing to remove that.
Maybe we can analyze the difference in this way:
An inset like this consists of two parts:
- A back-end part which interfaces with the LyX core data structure
and file format, etc.
- A GUI front-end which presents the inset. This front-end generally
consists of two parts when it comes to these insets:
1) An inline-view in the document
2) A dialog for customization and specification of the contents
The external inset provides the back-end hooks into LyX to include
different stuff of almost any character, including graphics. In this
way, the external inset can replace much of the back-end of the
InsetGraphics in regards to the interface to the underlying LyX data
structure.
However, since the external inset is so general, this necessarily has to
be reflected in the GUI. When it comes to the inline-view, the external
inset provides a simple mechanism for the different templates to customize
a string that is presented on a button. So this is obviously a very
limited form of expression.
This inline-view obviously is sub-optimal when it comes to graphics,
because then we would much prefer an inline-image.
When it comes to the dialog, the external inset also has draw-backs
because of the general nature inherit in it: The different templates can
customize the dialog to very little extend, but the overall framework of
the dialog is currently fixed.
These two restrictions imply that the external inset is not well-suited
for a user friendly interface for graphics. Both the inline previewing and
the dialog should be tailormade for the application at hand.
This is exactly what your work on the InsetGraphic concentrates on: The
inline previewing, and a tailormade dialog which allows domain-specific
customization: Resizing, rotating, and other graphical transformations.
Similarly, it is easy to argue that the external inset is not the perfect
interface to the other applications, whether it is chess diagrams or
database queries, time stamps or nodes for Beethoven 5ths.
But this is by design!
The core idea of the external inset is to enable and facilitate the
possibility of including any of this stuff in the first place. Until the
external inset came along, it was not possible to include any of the
mentioned things in your document without a lot of C++ hacking.
This is the view you should take: The external inset provides a lever to
get you started with including weird stuff in your documents. It is not
meant as the end-all inset that will obsolete all other insets in it's
current form.
On the contrary! You should consider it as an appetizer: By defining a
template for your favorite material, you get an easy way to include the
stuff in your documents. Over time, this template might turn out to
require a more sophisticated GUI. In this case, you can take two
approaches:
1) Develop a new tailor-made inset for exactly this material.
2) Extend the external material inset such that it can be customized
in such a way to serve the GUI needs your material has.
For most applications, you would want to take 1), as you do with the
InsetGraphic, because that will be the easiest way.
But you should not discard 2), because this is inheritly a stronger and
more general framework.
This is the primary reason I ask you to consider to integrate the
InsetGraphics inline-previewing into the external inset, and also posibly
the GUI dialog. If you do this in such a way that it can be sufficiently
controlled from the external templates, you will have made a larger
contribution, because it might turn out that other templates can exploit
the new functionality.
Instead of just providing the hooks to customize the text of a button, the
templates could point to a graphics file that should be inline displayed,
and suddenly the chess board templates, the musical scores and the
chemical insets will be much more interesting.
And if you also provide the hooks for specifying some geometrical
transformations in a dialog, this can also be useful for other material
than the raster format images. For instance, it is obviously well suited
for vector based formats, but it also has value for other stuff.
So, I propose to consider to extend the external inset such that both the
inline viewing can be more finely customized from the templates, and at
the same time consider a way to provide hooks for domain specific dialogs
that can be reused by other insets.
This should be done in such a way that the casual user will not notice: In
the menu, there will be separate entries: One for graphics, one for chess
boards, and so on. In the document, you can not see that it's all the same
inset that is lying in the background, and when you click on it to
customize it, you will get a special and domain-specific dialog.
In other words: Let's reuse the back-end of the external material inset
when it's feasible, and let's extend the front-end of the external inset
such that it can be customized more to the specific domains of
application.
> I'll need to take a look in the External Inset code to see what goes
> behind its curtains, I'd appreciate a list of source and configuration
> files that are related to it, I tried tracking it once but got baffled.
Hmm, I forget the exact names of the files, but you should be well off
if you start with the InsetExternal.C file, and trace the different
#include's.
For the most part, the code should be easy to follow once you have
grokked the general idea of the inset.
I hope I have managed to convey a bit of the apparent enthusiasm of the
external inset that I felt we had at the FILM: We agreed that it was a
step in the right direction. Hopefully, somebody will have the enthusiasm
and skills to bring us closer to the goal: The seamless integration of all
kinds of material in your documents in a dynamic, and at the same time,
with a domain specific interface that is easy to use and understand for
the user.
Greets,
Asger
