From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16844 invoked from network); 26 Dec 2022 04:19:48 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 26 Dec 2022 04:19:48 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 3459741783; Mon, 26 Dec 2022 14:19:24 +1000 (AEST) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 65B4741782 for ; Mon, 26 Dec 2022 14:19:14 +1000 (AEST) Received: by mail-ej1-f52.google.com with SMTP id fc4so24021717ejc.12 for ; Sun, 25 Dec 2022 20:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KM4HW4wktP/PfbTquR/1PKKWjHbOoVINBC9PDQXA48A=; b=RDDs9i5S3/X0qxU27Qt6StbzNx6syeUhl2OrmDAFKe04hIy4SHQ9lKKhKwA4Axi6dP wHfE9ogX54mfTC/Kw7BoRzYyqSKbrT+M8PJslIj0K+5EiF5VBlC5xPUisCSn8MDafEJ9 eT3wBYTgjml/mHpGYmYRHt52koDBNOhK4tqt/xo8hiOl04AlqgFGescGqGtxqHqy+KlM TVmY15oebxBhgl5GbbVdSuVHPxG8C/tzMf+QL5mz89vyfUIp1pL++lxyB+v5xVrNkwSG BqH7JktpSeYdMDP+g5ecspBQsuSwdutf0AHiz2HXLVcmvo+cVMKWn2CV1g1k0z7QtZdt DdRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KM4HW4wktP/PfbTquR/1PKKWjHbOoVINBC9PDQXA48A=; b=24dgz+cPl3EOnWW5MqXKVzK490Iif1YP7quR/quFzXjVWR3++zr5ngt5wecyI/532V cAipEXHZm2GZVhgx+DVZDvVEtS7485D4Etc1rG33a+OamNYCpOZiTBCGp5Sq61e3ayRd Wz8fXKKXYh1W1H7MgO9KKNPb2NGa8FiOEJ2aBfCb5ZpEY5TtELxKTZMEEltAQj4+uOY+ C55Xus8RUarEfYK8TASQbAwB2exGsi4S3Wt7usYjc/6O9lh9HzIDMGdRKskfE5ximXlZ by0EzXqopDStcA0l1ii1aK1v6Cfxz1Yi7akFtoZ+SGHng8hCAGo4KT1MzMTwJJokFWmG e+Og== X-Gm-Message-State: AFqh2kpdOYemotwPFYLU2XYlu8wh6QhinEt3ZPd9/1g2OCvmO5l3hHwe sbsBqKv6KDywicXTzrLMMQKH5akOKkZfBxvpsIZd2A== X-Google-Smtp-Source: AMrXdXslUqGdY/ZDXY1M1Okg6y5smBwfaChNrFwljHbS6+iLpmh62VebaDTMTgBVVl1gmmVbY9NhEVEkqM/k/lL/r9M= X-Received: by 2002:a17:907:bb87:b0:845:bb21:f62b with SMTP id xo7-20020a170907bb8700b00845bb21f62bmr737472ejc.140.1672028292562; Sun, 25 Dec 2022 20:18:12 -0800 (PST) MIME-Version: 1.0 References: <9E95A884-6101-4545-8638-CC1D0C94DEB9@ngelo.eu> <20221225205151.x3kflt7qrjc3b7i4@illithid> In-Reply-To: <20221225205151.x3kflt7qrjc3b7i4@illithid> From: Warner Losh Date: Sun, 25 Dec 2022 21:18:01 -0700 Message-ID: To: "G. Branden Robinson" Content-Type: multipart/alternative; boundary="0000000000006ed4d305f0b36c3d" Message-ID-Hash: 23BWLIFVXUH6VHDHMH6IKBCJUXCZE6OL X-Message-ID-Hash: 23BWLIFVXUH6VHDHMH6IKBCJUXCZE6OL X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: OLIT, MoOLIT, and NeWS (was: X11 Conservancy Project) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006ed4d305f0b36c3d Content-Type: text/plain; charset="UTF-8" On Sun, Dec 25, 2022 at 1:52 PM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > At 2022-12-25T10:15:19-0800, Michelangelo De Simone wrote: > > The X11 Conservancy Project (X11CP) pulls together the disparate set > > of programs which were being written between the very late 80s, and > > early 90s -- usually for Unix and Linux. > > It looks like this must have just gotten started. All that is present > is xtartan. Which I do at least remember. :) > If you go read their Mastodon feed, you'll see that there's a bunch of others... > Library support is going to be an issue for a lot of X11 legacy apps. > Indeed... There was quite the diversity back in the day... > I remember that the XForms widget library used to be proprietary, and I > recall that it had been freed, but not that this had been done 20 years > ago now[1][2]...albeit still too late to have made itself the center of > the Linux desktop environment, as it could have been if only the > copyright holders had not clung so tightly to The Precious. > Yea, it was one of many early contenders. > Motif and XView similarly got freed (the latter quite early in fact, as > I recall...but night had already fallen for the SunView UI). > Yea, XView was actually free from the start (or almost the start), but the SunView UII and programming model was a bit of a rough fit with X11 and never caught on, even though XView was widely ported. Motif was freed a few years later, in time for it to be used by a few projects before people moved on to things like Gnome and Qt. > But two tooklit variants I've heard of, I've never found out if they > ever made their sources freely available: OLIT and MoOLIT. > Now those are two toolkits I've not heard of in a long time... > As I understand it, OLIT was XView, but written on top of the X Toolkit > Intrinsics library (Xt) as opposed to bypassing it and going straight to > libX11. > Yes. OLIT implemented the OpenLook look and feel in the intrinsics programming model. It shared no code with XView, though. Sun was big on pushing OpenLook back in the day. > And MoOLIT was, apparently, some kind of shim--whether it supplemented > OLIT or replaced it, I am not sure--that, like XForms and Java's AWT, > allowed you to to write a "look-and-feel-neutral" application. > IIRC, and we're reaching back across 30 years at this point, MoOLIT was an attempt to implement both interaction models in one toolkit. > As I recall, such efforts often failed because they abstracted only the > intersection of available features rather than the union of them, so > except for very simple UIs, programs didn't look or behave > "idiomatically" anyway. > Yes. It was a poor implementation of all of them, and only kinda sorta looked right. It was OK for some things, but serious programs had big issues scaling. > I'd be curious to hear people's recollections of these and especially to > learn of any pointers to source. > I never was able to get my hands on binaries, despite trying to order them, let alone sources. They wouldn't ship them to Solbourne for some reason (well, the reason is below). > Ranging a bit farther afield, I wonder similarly about Sun's NeWS, which > I never saw in the flesh. > NeWS was about 3 years before OpenLook, etc. So I spent the 4 years just out of college in my second job at Solboune and later ParkPlace and Openware. I did the OI toolkit and UIB interface builder. It was a C++ toolkit that implemented both Open Looks (both 2d and 3d variants) and Motif. It did it in a neutral manner that allowed better layout than most other toolkits of the time (many other multi-model toolkits had issues where they'd render incorrectly if the fonts changed, or the model added 3d noo-dads that were different sizes for OpenLook and Motif). The interface builder I worked on would allow people to create real programs since it would create the right subclasses for you, allow you to expand the base toolkit either through composition of base objects, or via your own custom widgets. I even engineered the OI giveaway for Linux in the 0.99 days.... But the C++ ABI issues meant it never went anywhere... Sadly, there's little online about this toolkit these days. I found the following, which just gives the business news and no taste of the cool technology: https://techmonitor.ai/technology/att_takes_solbournes_c_object_library_for_designing_user_interfaces https://techmonitor.ai/technology/parcplace_systems_buys_solbournes_c_tool_division and an early paper on the technology before the automatic layout code was added: https://www.semanticscholar.org/paper/Encapsulating-a-C%2B%2B-Library-Linton/2421abe44375dca4620b5dcb1e717f43e2c538a5 It was a cool ride... I can dig up more info if people are interested... Warner > Regards, > Branden > > [1] https://web.archive.org/web/20110718230734/http://xforms-toolkit.org/ > Nowadays its web site does not even mention its proprietary past. > > [2] Before that relicensing, I was part of a team at Progeny Linux > Systems that was contracted by HP to port xforms (and a lot of other > stuff) to IA-64. xforms was given to me because I was "the X guy" > on staff. I don't remember it being difficult--just the usual > long/int punning issues. I don't recollect now whether xforms had > already been ported to Alpha or SPARC V9; it seems to me that it > should have been by 2001, or would have been, had it been FLOSS. > > Great merriment was had in those days dogging on IA-64, but the more > I learned about that ISA the more I liked it compared it to x86, > though that may be damning it with faint praise. But apparently > IA-64 made novel demands with respect to instruction sequencing that > caused compiler writers--or perhaps more accurately the people who > would have to pay compiler writers--squeal like pigs in hot oil. > Intel had a similar "fiasco" with the iAPX 432 fifteen years before; > that was the ISA for which, infamously, "Ada [was the] intended > primary language for application programming." Ada was also > reviled, ostenisbly because it was too damn hard to write a compiler > for it, but probably also because its keyword inventory more closely > resembled Pascal than C, which was already starting to eat the world > in the mid-1980s. Strangely enough, as I understand it, the > compiler innovations demanded by Ada and IA-64, respectively, came > to be standard and expected, and their benefits enjoyed unthinkingly > by x86 and C advocates. Thus do we reward innovation in this > industry. > --0000000000006ed4d305f0b36c3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 25, 2022 at 1:52 PM G. Br= anden Robinson <g.brande= n.robinson@gmail.com> wrote:
At 2022-12-25T10:15:19-0800, Michelangelo De Simone wro= te:
> The X11 Conservancy Project (X11CP) pulls together the disparate set > of programs which were being written between the very late 80s, and > early 90s -- usually for Unix and Linux.

It looks like this must have just gotten started.=C2=A0 All that is present=
is xtartan.=C2=A0 Which I do at least remember.=C2=A0 :)

If you go read their Mastodon feed, you'll see that t= here's a bunch of others...
=C2=A0
Library support is going to be an issue for a lot of X11 legacy apps.

Indeed... There was quite the diversity back= in the day...
=C2=A0
I remember that the XForms widget library used to be proprietary, and I
recall that it had been freed, but not that this had been done 20 years
ago now[1][2]...albeit still too late to have made itself the center of
the Linux desktop environment, as it could have been if only the
copyright holders had not clung so tightly to The Precious.

Yea, it was one of many early contenders.
= =C2=A0
Motif and XView similarly got freed (the latter quite early in fact, as
I recall...but night had already fallen for the SunView UI).

Yea, XView was actually free from the start (or almos= t the start), but
the SunView UII and programming model was a bit= of a rough fit with
X11 and never caught on, even though XView w= as widely ported.

Motif was freed a few years late= r, in time for it to be used by a few
projects before people move= d on to things like Gnome and Qt.
=C2=A0
But two tooklit variants I've heard of, I've never found out if the= y
ever made their sources freely available: OLIT and MoOLIT.
=

Now those are two toolkits I've not heard of in a l= ong time...
=C2=A0
As I understand it, OLIT was XView, but written on top of the X Toolkit
Intrinsics library (Xt) as opposed to bypassing it and going straight to libX11.

Yes. OLIT implemented the OpenL= ook look and feel in the intrinsics
programming model. It shared = no code with XView, though. Sun was
big on pushing OpenLook back = in the day.
=C2=A0
And MoOLIT was, apparently, some kind of shim--whether it supplemented
OLIT or replaced it, I am not sure--that, like XForms and Java's AWT, allowed you to to write a "look-and-feel-neutral" application.

IIRC, and we're reaching back across = 30 years at this point, MoOLIT was
an attempt to implement both i= nteraction models in one toolkit.
=C2=A0
As I recall, such efforts often failed because they abstracted only the
intersection of available features rather than the union of them, so
except for very simple UIs, programs didn't look or behave
"idiomatically" anyway.

Yes. = It was a poor implementation of all of them, and only kinda sorta
looked right. It was OK for some things, but serious programs had big
issues scaling.
=C2=A0
I'd be curious to hear people's recollections of these and especial= ly to
learn of any pointers to source.

I neve= r was able to get my hands on binaries, despite trying to order them,
=
let alone sources. They wouldn't ship them to Solbourne for some r= eason
(well, the reason is below).
=C2=A0
Ranging a bit farther afield, I wonder similarly about Sun's NeWS, whic= h
I never saw in the flesh.

NeWS was abou= t 3 years before OpenLook, etc.

So I spent the 4 y= ears just out of college in my second job at Solboune and
later P= arkPlace and Openware.=C2=A0 I did the OI toolkit and UIB interface builder= .
It was a C++ toolkit that implemented both Open Looks (both 2d = and 3d variants)
and Motif. It did it in a neutral manner that al= lowed better layout than most other
toolkits of the time (many ot= her multi-model toolkits had issues where they'd
render incor= rectly if the fonts changed, or the model added 3d noo-dads that were
=
different sizes for OpenLook and Motif). The interface builder I worke= d on would
allow people to create real programs since it would cr= eate the right subclasses
for you, allow you to expand the base t= oolkit either through composition of
base objects, or via your ow= n custom widgets.

I even engineered the OI giveawa= y for Linux in the 0.99 days.... But the C++
ABI issues meant it = never went anywhere...

Sadly, there's little o= nline about this toolkit these days. I found the following, which
just gives the business news and no taste of the cool technology:

<= br>
and an early paper on the technology before the automatic lay= out code was added:


It was a cool ride... I can dig up more info if p= eople are interested...

Warner
=C2=A0
Regards,
Branden

[1] https://web.archive.org/web= /20110718230734/http://xforms-toolkit.org/
=C2=A0 =C2=A0 Nowadays its web site does not even mention its proprietary p= ast.

[2] Before that relicensing, I was part of a team at Progeny Linux
=C2=A0 =C2=A0 Systems that was contracted by HP to port xforms (and a lot o= f other
=C2=A0 =C2=A0 stuff) to IA-64.=C2=A0 xforms was given to me because I was &= quot;the X guy"
=C2=A0 =C2=A0 on staff.=C2=A0 I don't remember it being difficult--just= the usual
=C2=A0 =C2=A0 long/int punning issues.=C2=A0 I don't recollect now whet= her xforms had
=C2=A0 =C2=A0 already been ported to Alpha or SPARC V9; it seems to me that= it
=C2=A0 =C2=A0 should have been by 2001, or would have been, had it been FLO= SS.

=C2=A0 =C2=A0 Great merriment was had in those days dogging on IA-64, but t= he more
=C2=A0 =C2=A0 I learned about that ISA the more I liked it compared it to x= 86,
=C2=A0 =C2=A0 though that may be damning it with faint praise.=C2=A0 But ap= parently
=C2=A0 =C2=A0 IA-64 made novel demands with respect to instruction sequenci= ng that
=C2=A0 =C2=A0 caused compiler writers--or perhaps more accurately the peopl= e who
=C2=A0 =C2=A0 would have to pay compiler writers--squeal like pigs in hot o= il.
=C2=A0 =C2=A0 Intel had a similar "fiasco" with the iAPX 432 fift= een years before;
=C2=A0 =C2=A0 that was the ISA for which, infamously, "Ada [was the] i= ntended
=C2=A0 =C2=A0 primary language for application programming."=C2=A0 Ada= was also
=C2=A0 =C2=A0 reviled, ostenisbly because it was too damn hard to write a c= ompiler
=C2=A0 =C2=A0 for it, but probably also because its keyword inventory more = closely
=C2=A0 =C2=A0 resembled Pascal than C, which was already starting to eat th= e world
=C2=A0 =C2=A0 in the mid-1980s.=C2=A0 Strangely enough, as I understand it,= the
=C2=A0 =C2=A0 compiler innovations demanded by Ada and IA-64, respectively,= came
=C2=A0 =C2=A0 to be standard and expected, and their benefits enjoyed unthi= nkingly
=C2=A0 =C2=A0 by x86 and C advocates.=C2=A0 Thus do we reward innovation in= this
=C2=A0 =C2=A0 industry.
--0000000000006ed4d305f0b36c3d--