Re: [Gnome-print] Printer & model description files

[Lauris Kaplinski <lauris ximian com>]

On 14 Jun 2001 17:25:21 -0500, Chema Celorio wrote:
> Ok. What about my proposal to call gnome-spooler with the flags so that
> we can later take care of that ?

You mean using just 'system ("gnome-spooler blablabla")'?
I would like to see synchronous solution.
The other bad thing is, that there is no gnome-spooler yet...

> > > Yes, i think the "Key" is just saying that it is a node. I would prefer
> > > if we removed it :
> > > 
> > > <Settings>
> > >   <Id>0009090900900</Id>
> > >   <Name>Default</Name>
> > >   <Engine>
> > >      <Backend>omni</Backend>
> > >   </Engine>
> > >   <Output>
> > >      <Media>
> > >         <PhysicalSize>A4</PhysicalSize>
> > >      </Media>
> > >      <Resolution>
> > >         <ResolutionX>360</ResolutionX>
> > >         <ResolutionY>360</ResolutionY>
> > > ... etc
> > 
> > Well, we can add aliasing for well-known options. But if everything
> > would be written that way, AFAIK writing DTD will become major pain.
> 
> The key= value= thing makes me think of shell config files. I don't
> think that the dificulty of writing the DTD should be an issue of 
> deciding how to define our data.

Hmmm...
Quite interesting that key= value= does not associate with shell me at 
all. Instead HTML:
<select name="myselect">
  <option value="sel1">Fist choice</option>
  <option value="sel2">Second choice</option>
</select>
or SVG:
<defs>
  <linearGradient id="mygradient>
    ...
  </linearGradient>
</defs>
<rect id="myrect" width="60" height="80" style="fill:url(#mygradient)"/>
comes to my mind

> > Agree, that existing technology should be used.
> > Still, there is specific problem - quite possibly gnome-print definition
> > files are more dynamic, than (maybe) gnome-print intself, and certainly
> > more dynamic than bonobo ui definition files of well-known projects.
> > Which creates po-updating problem. I.e. there is no other way to add
> > printer definition with translation, that to update some big existing
> > po file.
> 
> yes, this is a problem. Lets fix it later ;-).
> All the problems we can fix later lets leave them for later.
> The task is already very big and we can't solve everything on
> the first implementation. We will need to revisit this issues, but
> i am tryting to make the smaller task we can. 

I agree, that currently we leave out translating at all. I.e. let there
be:
<Name>Minu Printer</Name>
Whether it will be translated via .po files or some other way, can be
decided later, although in that case we may be forced to maintain
some ugly compatibility :(

> I think it is importatn if we write a couple of sample xml files while
> we discuss the format. The sample files are very helpfull. Lauris :
> can you modify the old format to the new format at least for one printer
> so that we can start writing down the desitions. Based on this format we
> can then propose chagnes to it.

OK. I'll try to convert. I'll do that without <include>, but including 
is certainly a thing, that has to be present in fiorst version - maybe
without constraining and overriding, but in format extensible to
support that.

Best wishes,
Lauris