[Printing-summit] [Printing-architecture] Printer dialog
spillner at kde.org
Sat Sep 2 11:24:34 PDT 2006
Alle 13:56, lunedì, 28. agosto 2006, Michael Sweet ha scritto:
> > At this point we are more in an information-gathering phase. I've
> > reviewed the (many!) XML (and other text-based) user interface
> > description formats that could be used and am preparing a report
> > for the printing summit.
I'm keen on looking on the list of formats. There seems to be a wide range of
pure declarative formats vs. those with scripting hooks or logical
constraints and operations.
> > XUL (Mozilla.org's XML UI language) is clearly the most widely
> > deployed and most capable, however it also carries a significant
> > overhead for implementation - code exists and could be fairly easily
> > integrated with KDE and GNOME via XULRunner, however you'll add a
> > significant amount of code (the XULRunner source code is 33 megs
> > bzip'd!), so I'm not too keen on using XULRunner or XUL as-is.
Do you talk about XUL being the source format for dialogs? I've onced used it
as a target format, thus allowing to switch to another format for situtations
where XUL is not suitable.
However, if XUL is to be chosen, then I can contribute a bit to KaXuL to make
things work for the KDE side of things. Right now, KaXuL is everything but
I'm also working with XForms generation and from what I've overheard in chat
with Mozilla people is that XUL 2.0, should it ever be finished, will contain
an XForms processor. I doubt this step will make it more light-weight - the
opposite is more likely the case.
(Since my last mail, http://dynvocation.selfip.net/ has gone online as a
temporary space to share some of the XForms auto-generation work of mine.)
> > Ultimately we need to get better requirements for *what* needs to
> > be supported, from printer and applications vendors *and* from users
> > and administrators who may want to add site-specific stuff to the
> > print dialog, too.
Yes, that's what is clearly missing especially for the people who're not much
> > So far our requirements list is pretty short (and challenging):
> > 1. Cross-platform (operating system, architecture, desktop, UI
> > toolkit)
> > 2. No binaries (executables or plug-ins)
> > 3. Embeddable in PPD files or some other way to package the UI
> > such that the UI and printer description/command data are
> > available via a single URI
How about translations? The "language pack" philosophy of XUL as a source
format would have to be changed to something which includes translated texts
in one file.
> > 4. Same level of localization possible as with current PPD
> > files.
Well I guess this covers my question above...
> > 5. Accessible to persons with disabilities
Does this extend beyond the usual magnifiers and text-to-speech desktop
frameworks, i.e. would there be a need for specific developments?
I could imagine access keys for dialogs just as they're used in web pages.
Auto-generation certainly helps with consistency here.
> > What we don't have is a list of required UI elements and behaviors
> > that need to be supported. I'd like to put together sample use cases
> > we can use as a baseline to determine these requirements and then
> > form the basis of a test, conformance, and demo suite for the new UI
> > "technology" that gets incorporated into CUPS and the various
> > desktops.
Since XUL not only provides form elements, but also a plethora of application
framework elements, I wonder if those are all needed.
XForms has definitely proven as being too limited in the number of offered
widgets, there's no numeric input control, for example.
I figure that something in between will be needed, and I hope that no
completely new format will have to be invented.
If there'll be something materialising before aKademy this year (Sep 23-30), I
can talk to the KDE people involved in the Kode framework (which is supposed
to be used for such tasks) and in accessibility. There's a BoF about Kode
among others chaired by me and we'll surely find some enthusiasts.
More information about the Printing-summit