All,
I have done some research and thinking about constraints and I want to share
it at this point.
I would appreciate first comments this week to be able to work it over.
I haven't concentrated to much on writing good XML so far. I may try that
the next days in case we agree about the general direction.
I will arrive in LA Wednesday night very late, will have a breakfast late
Thursday morning and could talk about constraints further more in detail
after that, if people are interested and available.
If you have WinWord available you may want to read the attached doc file. I
have copied it below. But the tabs are translated badly and the 'rectangles'
stand for bullets.
Start of WinWord document
UI constraints in UPDF
I thought about it a while and want to start the discussion to prepare a
section in the spec.
Up to now I limit myself to contraints in the UI, although we are facing
similar problems when printing, too. But this often results in CallBack
functions. That’s why I call it “UI constraints”.
Statement 1 (to be discussed): Constraints handle limitations and automatic
switches
To provide consistent functionality, we do not only handle limitations and
exclusions like “if DialogElement1 is set to Setting1, DialogElement2 cannot
show Setting2”, but also automatic switches like “if DialogElement1 is set
to Setting1, DialogElement2 is to be set to Setting2”. I do not think this
needs a lot of extra work either, but would ease the understanding of even
complex UI behavior.
Statement 2 (to be discussed): Installed options are to be identified
InstalledOptions must be declared as such so they can be identified for
specific functionality.
Statement 3 (to be discussed): All interdependencies between driver elements
are handled as constraints
Only the model itself or InstalledOptions like an Input or Output option can
own another driver element. So only the model and any InstalledOption can
have lists of paper sources, sizes, media types, duplex modes, etc.
This might be a kind of a revolution for some people, but it keeps the
printer’s description and later the driver very straightforward. It means
that the model owns e.g. paper sources and paper sizes in separate lists,
but this part of the UPDF does not tell that certain sources do only support
certain sizes. I know that this would require a significant change of the
sample XML of M.Yeung. But paper sources and even other driver elements have
so many different attributes between different manufacturers nowadays that
it would extremely hard to find a generic way to describe these
interdependencies within the listings of driver elements.
Now while I seriously think about constraints it looks more reasonable to me
to provide a separate constraint section and tell there as a constraint that
the envelope tray does not feed Letter and many other sizes.
Statement 4 (to be discussed): The list of conditional sets combined to a
constraint is infinite
We want to allow maximum flexibility. With combining two conditional sets to
a constraint this is only possible in a limited way. So we could tell that
duplex is only available with a certain amount of RAM and depending on
certain paper sizes and only from certain paper sources.
Simplifying that and ignoring perfect XML syntax at the moment this could
result in two constraints like:
Constraints
Model
Constraint
Set
Condition RAM <= 2MB /Condition
/Set
Set
Condition (PaperWidth x PaperHeight) > 2MB /Condition
/Set
Set
Condition Duplex != Off /Condition
/Set
/Constraint
Constraint
Set
Condition PaperSource != Manual /Condition
/Set
Set
Condition Duplex != Off /Condition
/Set
/Constraint
/Model
/Constraints
I’d like to define some rules with this simplified sample:
Rule 1: InstalledOptions will not be changed by constraints.
So condition 1 of constraint 1 will not result in any change in the UI.
This explaines Statement 2.
Rule 2: The definition of the constraint defines the order in which it will
be resolved.
This can be ignored in case of exactly two conditional sets per constraint.
In case of more conditional sets it may happen that a certain selection in
the UI is activating condition 1 of constraint 1. May be that resolving
condition 2 of constraint 1 is already resolving the complete constraint. So
condition 3 of constraint 1 can be skipped.
That means the order of conditions is Top-Bottom. The top condition is to be
resolved first and so on. That allows control about priorities.
Rule 3: The order of constraints define their priorities.
Not very obvious that we need that rule. But resolving a certain constraint
may activate another constraint. Hoping we will never get into an infinite
loop, it’s now important, what to do first and next.
Defining a global default element or message could help avoid crashing the
driver.
Rule 4: InstalledOptions have their own constraints.
They do not change or extend constraints of the basic models.
In case an InstalledOption is going to be merged into a basic UPDF file, the
corresponding block of constraints should be added after all other blocks
already listed. In the example above no InstalledOption is listed. So I only
show the Model section. The string Model is a technical variable, not the UI
string (I have seen cases, where models had different names in different
locales).
This procedure keeps it easier to handle InstalledOptions. Certain
constraint blocks can be easily removed without being afraid to break
anything. In case there are constraints between different InstalledOptions –
and this is known – the constraint blocks for both InstalledOptions should
list the corresponding constraints.
To-do-list
? We have to decide whether we define the good or the bad elements. In my
examples I defined the bad combinations in all the constraints.
This is causing some problems when trying to define automatic switches. See
further below in this document.
? Some syntax issues must be discussed.
Up to here that’s the basic part.
You may have wondered why I braced the conditions with “Set”.
? I can well imagine that we realize an OR by simply listing several
conditions:
Set
Condition PaperSource = Tray1 /Condition
Condition PaperSource = Tray2 /Condition
Condition PaperSource = EnvelopeTray /Condition
/Set
Set
Condition Duplex != Off /Condition
/Set
? I can well imagine we want to handle other settings within a set. Samples
could be “Action” and “Message”.
The Action tag
? The action to resolve could be to mark the bad element. This could result
in a red cross next to the bad element, e.g. in a combo box.
Action Mark = RedCross.JPG
? The action to resolve could be to gray the bad element. This would show
the bad element gray, but the others normal black.
Action Gray = 75%
? The action to resolve could be to hide the bad element, apparantly the
default, in case neither Mark, Gray nor Hide is listed under the Action tag.
Action Hide = TRUE
? The action to resolve could be to show an info button to allow the user to
activate a detailed message.
Action Info = INFO.JPG
? The action to resolve could be to select a certain driver element active.
In case Select is not listed under the Action tag, the first element of the
driver element list of this UI element will be activated. I can well imagine
several Select lines per constraint Set. This would result in a kind of a
fallback selection in case the first listed Select line cannot be used
because of a certain driver configuration.
Action Select = Manual
I can well imagine that several lines are combined to define a complex
action:
Set
Condition UIElement1 != DriverElementX /Condition
Action Mark = MARK.JPG
Action Gray = 75%
Action Info = INFO.JPG
/Set
Set
Condition UIElement2 != DriverElementY /Condition
Action Info = INFO.JPG
Action Select = DriverElementZ1
Action Select = DriverElementZ2
/Set
In case the driver provides all required functionality this would be
resolved in case UIElement1 is to be changed: DriverElementX would be grayed
and marked. An Info button would be visible next to the UI element, even
when the combo box is not open.
In case UIElement2 is to be changed: DriverElementY would be hidden. The
selected driver element would not be the first in the list, but
DriverElementZ1 – if available. Otherwise DriverElementZ2. Info button as
above.
The Message tag
This would only be used in case there is an Action Info line defined.
? We want to activate a certain text.
Message Text = Constraint_PaperSource_Duplex
? We may want to activate different levels of message boxes.
? Exit: Just the message and and Exit button. Default.
? Exit_Show: The message, an Exit button and a Show button. Pressing the
Show button would should another window with more detailed info. I think of
the list of constraints that has been used for the UIElement, where the
technical variables would be replaced by the locale specific strings.
Although this would still be quite a technical information in a strict
syntax it provides a lot of details with generic functionality. Just an
idea.
? Exit_Show_Save: As Exit_Show, except that the detailed info can be saved
to a file. Might be useful for the support or if somebody wants to
manipulate his UPDF file.
Message Window = Exit
So the latest example could be extended to something like
Set
Condition UIElement1 != DriverElementX /Condition
Action Mark = MARK.JPG
Action Gray = 75%
Action Info = INFO.JPG
Message Text = Constraint_UIElement1_UIElement2
Message Window = Exit_Show
/Set
Set
Condition UIElement2 != DriverElementY /Condition
Action Info = INFO.JPG
Action Select = DriverElementZ1
Action Select = DriverElementZ2
Message Text = Constraint_UIElement1_UIElement2
Message Window = Exit_Show
/Set
I think it is realistic to assume the same message text for both sets to
save translation effort.
Automatic switches
This is not much more than an idea up to now. The general problem to realize
something like “if this is selected here, something else should happen
there” is very similar to constraints in the basic sense.
So I wonder whether we can use this or a very similar kind of syntax not
only for the negative combinations (this and that cannot be combined), but
also for activating certain selections depending on others.
I will keep an eye on that.
End of WinWord Document
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UI constraints in UPDF.doc
Type: application/msword
Size: 35328 bytes
Desc: not available
Url : http://www.pwg.org/archives/upd/attachments/19991207/c21332d1/UIconstraintsinUPDF-0001.doc