Re: Scripting in Gnome

On Mon, 2004-02-02 at 16:29, Sean Middleditch wrote:

> > 
> > No it allows some of us to extend functionality rather than it being
> > fixed and static. Theres nothing wrong in allowing for further
> > customisation (like sawfish allowed lisp to be used to script in
> > extensions)
> Yes, there is.  It's horrible UI.  There is absolutely no good reason
> for that kind of stuff.  Anything you could possibly do by over-riding
> UI of other apps you could do cleaner and with a much better design.
Allowing scriptable extensions to functionality or UI is not wrong. The
HIG defines the standard and default UI - having extensions that allows 
a particular user to change things for the better is not wrong. Having a
one size fits all approach is wrong in my opinion. A default is great
but lets allow some freedom for the few who care to differ.

> MouseOvers shouldn't even be allowed on websites, much less on the
> desktop.

> > > > GDesklets is another example all though it is rather limited. What
> > > > we need is a standard way of scripting in Gnome apps with the ability
> > > > to create apps using just XML with embedded scripting as well as allowing
> > > > existing apps to be extended or controlled.
> > > 
> > > There was a project called Entity iirc that did the XML thing.  Never
> > > took off.  Might be indicative of something.
> > 
> > >  
> > If it were incorporated into core Gnome rather than being a little heard
> > of add on then it would get used.
> No, because nobody wanted it.  It was a pain in the ass.  It's much
> easier and more efficient to just use Glade and a real language, then
> try to work with embedded code in an XML document hack.

I disagree. The XML doc would be standardised so once its layout is
learnt u can then use it with any supported language very efficiently.
> > >   The API should simply be generic/extensible from the
> > > start (as we *already have* with Bonobo/D-BUS/ORBit/etc.) and thus
> > > automatically usable from any language with bindings.  One just needs to
> > > get apps to embrace this.  I guess the GNOME Office framework has some
> > > code to make this easy and consistent.
> > 
> > Stuff the bindings - they just create extra work every time a library
> > changes. Say I wanna use VBA - so what ur telling me is that I have to
> Um, hello - you have to write the bindings just for the XML language
> engine to even work.

Only *once* with my proposal. Once that binding is done all suportted
languages will not require separate bindings.

> > create a whole new interpreter for VBA complete with all the necessary
> > language bindings - thats crack. A simple generic scripting interface
> Ya, except, that's exactly what you're asking for.  A language binding
> that somebody has to write just to get JavaScript/VBA in GNOME.  Your
> method not only requires that binding, but *also* some kind of hacked up
> XML document type do... well, something.  Not sure what, since it isn't
> needed to do anything.

Write once and use with any language = much less work/effort. The XML
provides standardisation as opposed to propriety layouts using different

> > with syntax defined by XML is a quick and easy way to getting integrated
> > scripting into Gnome with the least overhead. The only objects that the
> > scriptiong language should use are bonobo and/or glade.
> A simple, generic scripting interface *doesn't need XML*.  The scripting
> interface would be an API that applications would use to expose
> functionality to the scripts, be in inprocess plugins or out-of-process
> remote-activation kinds of things.
> You'd have to write glue no matter what.  Whether that glue be to some
> kind of weird XML-language-wannabe or a real language that actually
> exists is irrelevant.  And all you'd have to do is add a little bit of
> glue to the script interface library and all applications would
> automatically have full support from the new language.

Only the XML bindings need glue so again write once only. New languages
just need an XML language definition - no glue or bindings required.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]