Re: [Gnome-print] Printer & model description files
- From: Lauris Kaplinski <lauris ximian com>
- To: Chema Celorio <chema ximian com>
- Cc: setup-tool-hackers ximian com, gnome-print ximian com
- Subject: Re: [Gnome-print] Printer & model description files
- Date: 15 Jun 2001 01:44:25 +0200
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.
Quite interesting that key= value= does not associate with shell me at
all. Instead HTML:
<option value="sel1">Fist choice</option>
<option value="sel2">Second choice</option>
<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
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
] [Thread Prev