There is another discussion going on:
How shall a driver behave when it comes to dependencies for composite
features.
Two weeks ago I was coming from a position that a composite feature is a
feature as any other. So it may as well have its own dependencies. The
'old' ones referring to basic features used as components are to be
ignored.
I'm not that sure any more.
Basically most of the old ones would have to be redefined while just
replacing the condition. May be even the same warning messages are used. If
not, a new localization effort is necessary.
In the meantime I'm leaning towards 'use what you have'. It's there. If it
can be used, no extra effort is necessary.
Once creating messages be a bit careful with the wording as they may pop up
with composite features later.
So there will not be any new localization.
To be clear: If the composite feature needs something special, go ahead and
create a new dependency.
Sample:
If !simplex, don't use media type transparency.
Assume we have that dependency for the two basic features and we have a
composite feature 'Media' with media size and type as components.
If long-edge is selected and the user tries to select a ComponentSet, which
involves transparency, the original dependency should pop up.
I understand that people can have different opinions on this, but we'd like
to recommend an expected behavior for UPDF drivers in the spec.
So let's hear some opinions and see, if we can agree.
Norbert
This archive was generated by hypermail 2b29 : Mon Sep 16 2002 - 14:37:10 EDT