| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2040.1 | No plans at the present | R2ME2::GRASS | Steve Grass | Mon Jan 15 1990 15:47 | 19 |
| > Will they be added to the toolkit?
We have no plans to add Steve Klein's widgets to the toolkit. The toolkit
will, for the most part, contain the widgets in OSF Motif. The only
additions to this at the moment are the color mix and help widgets.
For widgets that seem to be a superset of existing widgets (such as vlist),
we'd rather see the additional functionality added to the current widget
by OSF rather than adding a new DEC-proprietary widget.
However, for widgets which have little in common with existing ones (such
as vhist), there's always the possibility that it will be added in the
future to either the extended bundled toolkit (currently containing color
mix and help) or the application developer's toolkit (currently
containing GObE, NetEd, and SVN).
We don't, however, have any current plans for this happening soon.
steve
|
| 2040.2 | | OED::BEYER | Hugh R. Beyer | Thu Feb 01 1990 09:23 | 5 |
| Oh good. The V* widgets are much too useful to make generally
available. Better to ship the listbox widget, which essentially
doesn't work, than the VList widget, which does.
HRB, with his little box of matches
|
| 2040.3 | We SHOULD export our technology. | R2ME2::GRASS | Steve Grass | Thu Feb 01 1990 10:18 | 18 |
| Great. Sarcasm. Just what I need.
ANYWAY, we're in the business to give customers what they want, correct?
Believe it or not (and most of the time, I can't), these days, customers want
standard technology (i.e. Motif). Most ISV's are writing applications for
multi-platforms and could care less about Digital proprietary widgets.
Yes, I believe that there's still a need and a place for added-value components.
However, as I stated in 2040.1, if these appear to overlap existing standard
widgets such as the list box, we should work on upgrading the standard rather
than attempt to compete.
The other widgets (vhist, SVN, GObE, NetEd, print, help, color mix, etc., etc.)
should be made available to customers one way or another and plans are being
made to make that happen either through SSB, ASSETS, bundled with the base
platforms, or some other way.
steve
|
| 2040.4 | | DECWIN::KLEIN | | Thu Feb 01 1990 11:39 | 33 |
| Ok. You got to me.
The VList widget overlaps the functionality
of the toolkit listbox about as much as the SVN widget does.
I don't think this is a good reason to not offer VList to customers.
As far as being "proprietary", I assume that we would be
selling the sources as well. Now, VList works on all the DEC platforms:
VMS/ULTRIX/DWT/MOTIF/VAX/RISC/V1/V2. It seems it would be easy for
any customer to port the VList widget to another platform. Anyway,
why not let the customers decide for themselves what is good for them?
But I can see I'm fighting an uphill battle. So, I continue to pursue
other avenues by which DEC can profit (at least indirectly) from this work.
On the up side, VList, VHist, TList and VDrag will be
included in the DECW$EXAMPLES directory on the
next release of VMS DECwindows. Complete source kits for these
widgets will be "bundled" with VMS DECwindows as examples of
user-defined widgets, etc. At least this will be easier for me than
it was to make individual tapes and send them to the "important" customers who
requested them after seeing FileView and CardFiler.
No money, but at least some good-will.
Internally, I have sent out over 50 VList X2.0 kits in the last 3 weeks.
To me, this means that many people are finding it useful in spite of the
fact that it there is a toolkit widget with almost the same name. I hope
to continue spending more midnight hours working on VList and the other "V"
widgets, and will continue to make them available as widely and freely
as the company will allow.
-steve-
|
| 2040.5 | one can be useful and standard-conforming at the same time | PSW::WINALSKI | Careful with that VAX, Eugene | Fri Feb 02 1990 18:29 | 7 |
| Support of standards in DEC has never before precluded shipping added value.
Consider our compilers that conform to standards (COBOL, Pascal, FORTRAN, Ada,
etc.). They support the standards fully, but they also provide enhancements
and extensions to make the product more useful, and to compensate for areas
where the standard behavior may be weak.
--PSW
|
| 2040.6 | Open World? | SUBWAY::GRAHAM | if ya want home cookin, stay home | Sun Feb 04 1990 01:16 | 11 |
|
> one can be useful and standard-conforming at the same time
Paul has a point....
Could we standardize the Vlist and others by shipping source
code with them? This will differentiate Digital from the
rest of the Motif-cloning pack Let's provide leadership.
*NOW*
Kris...
|
| 2040.7 | | R2ME2::GRASS | Steve Grass | Mon Feb 05 1990 09:50 | 10 |
| > Could we standardize the Vlist and others by shipping source
> code with them?
According to .4, we will be shipping these widgets as source in DECW$EXAMPLES,
which I think is GREAT. This IS one of the options available to us and the
correct one for this set of widgets. Not only are we giving additional
capabilities for those writing DECwindows apps, but are allowing ISV's to
port them to other platforms.
steve
|