(no subject)

[James Vandenberg <james vandenberg dropbear id au>]

Hi Michael, Sorry if this reaches you twice, but I meant to post this
publicly and I didn't. For the convienience of the other subscribers, I'll
post it again. JV

On Fri, 23 Jun 2000, Michael Meeks wrote:
> Hi James,
> 
> On Sat, 24 Jun 2000, James Vandenberg wrote:
> > The problem that MS OLE and OpenDoc was designed to solve was that of
> > getting, say, A spreadsheets data into a word processor. Mostly the
> problem
> > was solved by 'embedding' the application into the document. ie, the
> > spreadsheet would be started when the wordprocessor came across some
> spread
> > data. The problem with this is that you need the ss already installed,
> and
> > alternative ss programs aren't able to cope. An entire app is loaded to
> > edit some small amount of data.
> 
> 	Well, you need something installed to view a certain type ( eg.
> Spreadsheet ) of data. Also, perhaps this 'not got it installed' thing is
> due to non-free software ? Either way we share your desire for small fast
> components that are omnipresent. As for alternative ss programs not
> coping, they should be able to do so fine with the current framework.

True. I think I should elaborate on how I think components should
communicate. If it is Identical to bonobo, I probably have missed something
in bonobo. Essentially, all communication is done using data objects, in
some standard formats, such as XML, SVG, Tabular, Image etc. Then, standard
manipulators can work on this standard format, and standard viewers could
also manipulate it. standard adaptors could also be used to turn say, SVG
into PostScript, or even tabular into SVG. To do a chart, you just send a
propertylist data object describing the format, and a tabular data object
containg the data to be plotted. Of course, situations would arise in which
your application needs some special data type, but it could be displayed
using a standard view, such as formatted text view. The solution would be
to write an adaptor to turn your special data into one that formatted text
view can understand.

> > What I was thinking of doing involved having standard kinds of objects,
> and
> > have well defined meanings for each component. The primary paradigm
> would
> > be data manipulators manipulating data objects. Essentially the
> > manipulators transform data objects, and pass them to other
> manipulators.
> 
> 	I find it difficult to think of a suitable abstract 'manipulator'
> interface to do an arbitrary manipulation.

interface manipulator {
	attribute data_object
	bool do_action(in string command, data_object parameters)
}

Actually I think you're right. Arbitrary manipulations are somewhat hard to
do. I don't think a single component should try it. Instead manips would do
one thing really well, such as sorting, or applying a function, or creating
a chart. Manipulators are in some ways similar to things like unix sort,
uniq, wc, awk, sed etc. Thanks for solidifying that idea. It was a bit
vague.

> > An example: A SQLQuery object is passed to a DatabaseQuery manipulator,
> > which returns a table object, which in turn could be passed to a
> > spreadsheet object which calls a function manip on all the rows in the
> > sheet, passes it to a drawing object, which creates a SVG Object, which
> is
> > passed to a standard SVGView object, which displays a map, with the
> data
> > all put on a map.
> 
> 	Well; this scenario is extremely feasible in the current setup,
> all that needs doing is a little code creating to find components with
> suitable interfaces to interact as you specify and then to activate the
> implementations and plug the references together. I agree however that
> the
> more standard, useful interfaces we create the better.

Yes, it is feasible. But I want a way for Joe Average to be able to do this
sort of arbitray component plugging. Similar to | on the command line. So
that you can see the results of each stage, as you do them, and keep
plugging in new manipulators as you need.

> > Also Data objects might be passed to a network 'pinboard' so that, say,
> > Mary in graphic design can put her new logo on the pinboard, replacing
> the
> > one already there, and all documents using it would be updated. It
> would
> > solve the problem of : "Could you put it on the network and I'll try to
> put
> > it in to the letter before I send it ... "
> 
> 	This is a rather different issue I think. A nice idea.

I think it would be trivial to do, using corba, and it would be that little
bit extra that would make gnome more useful. It could be implemented as
some kind of view component. 

> > Obviously this needs work, but I think it would be a lot more flexible
> and
> > less likely to cause component explosions (millions of nearly identical
> > components such as spreadsheets that differ only by file format)
> 
> 	I don't see this happening; people tend to just write gnumeric IO
> plugins.

Yes, you're right, that example was a little extreme. But say GTK+
underwent some major changes. Only the standard view objects would need
changing, and the rest of the standard components could continue as they
were. Or if you did a port to Windows, then the less that relies on the UI
architecture, the easier it could be. And manipulators wouldn't care what
breed of view objects they were talking to, just that they could talk to
them.

> > Essentially what I wanted was some way structured data could be passed 
> > between compenents without each knowing about the other, and having 
> > the GUI components as standard targets for data. ie, you can send any 
> > SVG data object to a Vector View object, no matter what it's source. 
> 
> 	This sort of abstraction is indeed nice; what needs defining is
> the generic interface that a Vector View object exports. Then it merely
> plugs into what we have already surely ?
> 
> > What do you all think?
> 
> 	I think that Bonobo + some extra, well defined interfaces and
> standard implementations solves all your design goals.

I agree that it would plug straight in, but I think that bonobo needs a
standard library. Make the library encourage this sort of abstraction, and
encourage it in the documentation as well.

As for writing the interfaces, I'll try and put down what I think they
should look like. Implementation I may not get done this week :-) Stay
tuned. 

> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot

Cheers,
James

--
This .sig kindly provided by /dev/random.