[Info-vax] OpenVMS graphics - once more
IanD
iloveopenvms at gmail.com
Sat Aug 22 14:35:59 EDT 2015
On Friday, March 13, 2015 at 2:56:25 AM UTC+11, Stephen Hoffman wrote:
> On 2015-03-12 14:57:55 +0000, fhsjvl at gmail.com said:
>
<snip>
>
> Yeah; I used to use the DECwindows desktop. It won't be easy to
> convince me to return to DECwindows as a daily desktop, either. For
> reasons well beyond the graphics device and driver support, not the
> least of which is application support and file format support, I just
> can't see all that much use of DECwindows for myself, nor for other new
> users, nor for very many new applications.
>
Nor will I be easily convinced to return to it as a desktop either, it was horribly inefficient for me to use for operations support many moons ago
Great for pretty graphs displaying the status of things in a data centre but horrible for getting real work done. Endless clicking down menu structures to find what you wanted often to discover the option you needed was not available via the windowing system or in combinations requiring multiple passes to achieve the desired result. Lag lag lag was what I remember most about decwindows too
A windowing system has to have a huge amount of thought put into it and the cli is still king for many operational types of tasks
> I definitely can see some uses, such as development work, or for use as
> dedicated control and status displays and related processing. But I'd
> wager that these environments are a pretty small businesses. There
> are undoubtedly a few critical businesses here that really need
> DECwindows available, but -- strictly for general day-to-day OpenVMS
> desktop usage, and not as some sort of dedicated control system or a
> development-related application or such -- it's the rest of the
> application stack that's a (much) bigger problem for (most) folks that
> might otherwise consider it.
>
Well put imo
> Yes, other folks -- one posts here quite often -- don't want to or don't
> have to deal with other file formats or with multimedia, and don't need
> nor use the same sorts of tools, so DECwindows and OpenVMS can still
> work as a desktop. For some folks.
>
> Many of the usual sorts of remote displays where I would have once
> considered or used X for have been subsumed into web front ends -- some
> of which can be rather more embedded than might be obvious to many of
> the users, both in terms of the viewing applications, and in terms of
> the embedded web servers -- or subsumed into applications that
> communicate with the servers while managing the display using local
> display mechanisms and interfaces.
>
> Then there's that X has generally become little more than an RPC for
> most of its recent remote-graphics usage, and not really a particularly
> effective one. Related: <http://labs.hoffmanlabs.com/node/1680>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC
Every time I used to want to use PSPA decwindows interface I'd face endless issues with network security factions within companies to have them open up X as a protocol through their networks. Overly chatty, to security issues to we just don't like it excuse cards always were rolled out
Some of the collection displays used to take longer than 24 hours to display which would often fall foul of an imposed 24 hour maximum no response cut off timeout and because I had to pass through a few firewalls, somewhere along the line one would not register activity and so the sessions would be cut off at the knee's
No thanks, not again, I don't want to return to those horrible old days or anything resembling them for that matter
Decwindows for me was never the one stop productivity shop. It was more something that I had to use for certain tasks but I always lived 80% in the terminal world and 20% in the decwindows world - constantly having to straddle that fence hurts ;-)
Look at the fragmentation in linux offerings over what gui to use. Unity, Gnome, kde etc etc
Do we go via the virtual desktop model where the display is simply thrown back to the workstation or is the workstation part of a greater compute engine
I think VMS should have a vision for it's gui that's for sure because without one, hardly anyone is going to invest their time into something that may not be supported officially in the future but at this stage of the game I doubt VSI have the funds nor the time to be worrying about what gui to be developing for VMS, but a vision should be forthcoming
Personally, I'd like to see a system that is both virtual in that you can freeze your activity on the server side and undock from it and come back later with any other device and reattach and continue, but I'd also like to see something that allows the compute power of the docked in device to be used (local gpu, some processing cores etc), not just for display purposes but in the greater VMS compute stack/cluster itself - obviously this is going to have to wait until after x86-84 is a reality first and a grater vision for clusters emerge
Until there is an overall vision put forward by VSI for a gui direction, I doubt many are going to invest time and money into developing one
More information about the Info-vax
mailing list