sprog-users

[sprog-users] Abstracting the XML?

[Tony B. <ton...@gm...>]

Having a look at Sprog::Gear::ReadExcel posted recently, I'm wondering
if there might be a way to separate out the mechanics of the
translation modules from the glade XML? If there were a standard
format for a Gear translation, then people could write modules to do
the translations, even if they don't understand the widget format
(like me!).

This isn't just a selfish thought though. If the XML could be
abstracted further in some manner, it should theoretically be possible
for someone to write a different front end - e.g. a web-based one.
Drag and Drop is pretty well supported in browsers these days, so
there's no theoretical reason I can think of why we couldn't have a
web based front end. (Could also avoid all those nasty installation
issues!)

As I say, I don't know enough about the Gtk issues to know how one
might abstract this furthe, but, even if the web-interface idea is a
non-runner, anything that makes it easier for people to add their own
gears will only make this great project even better.

Tony

Re: [sprog-users] Abstracting the XML?

[Grant M. <gr...@mc...>]

On Sat, 2005-06-25 at 08:42 +0100, Tony Bowden wrote:
> Having a look at Sprog::Gear::ReadExcel posted recently, I'm wondering
> if there might be a way to separate out the mechanics of the
> translation modules from the glade XML? If there were a standard
> format for a Gear translation, then people could write modules to do
> the translations, even if they don't understand the widget format
> (like me!).

I'm not sure I fully understand what you're suggesting here.

The Glade XML section is only required for gears that have configurable
parameters.  So for example the 'CSV Split' gear doesn't need a
properties dialog and therefore doesn't have a dialog_xml method.
I'd recommend against having lots of configurable options.  It's
sometimes simpler just to have two separate gears with specific
hard-wired behaviours.

Also there's no need to understand the 'widget format'.  You just build
the dialog box in Glade, save it and paste the XML into the .pm file.

I initially planned to define dialogs using a simple YAML or XML format
but decided that re-inventing Glade was not going to help get the
project out the door :-)

I have considered supporting an alternative dialog definition for really
simple dialogs - eg: a single text entry with a label.  The problem is
that as simple as I tried to make it, people would always want to extend
it just that little bit further and in the end we'd re-invent GladeXML
and probably do it badly.  (I've learnt some lessons from XML::Simple).

> This isn't just a selfish thought though. If the XML could be
> abstracted further in some manner, it should theoretically be possible
> for someone to write a different front end - e.g. a web-based one.
> Drag and Drop is pretty well supported in browsers these days, so
> there's no theoretical reason I can think of why we couldn't have a
> web based front end. (Could also avoid all those nasty installation
> issues!)

Well I have tried to separate out the GUI code in the framework to allow
plugging in an alternative GUI layer.  I've even achieved that in a
perverse way with the --nogui option.

I'm certainly not discounting the idea.  If someone wants to come up
with an alternative way of defining the properties dialogs then I'm open
to ideas.  I have other priorities right now though.

Someone else suggested the web frontend notion to me recently.  It's an
interesting notion.

Cheers
Grant