On 9/20/2018 1:36 AM, Peter Moylan wrote:
> On 20/09/18 05:55, David Kleinecke wrote:
>> On Wednesday, September 19, 2018 at 8:04:31 AM UTC-7, Peter Moylan
>> wrote:
>
>>> Eventually Linux will come up with a desktop paradigm based on the
>>> OS/2 ideas, but probably not within my lifetime. Microsoft never
>>> will, because it lacks vision.
>>
>> You are dealing with ideas that interest me. But I have not been
>> able to locate any forum where they are being discussed. Do you know
>> of any?
>
> If you'd asked me that some years ago I could have pointed you to the
> OS/2 newsgroups, but you know what happened to newsgroups. There are
> mailing lists -- I run a few myself, for the software I distribute --
> but those are for specific interests, and tend to stay on topic.
>
> IBM once published specifications for the object-oriented approach, but
> I no longer know where to find them. Searching for "presentation
> manager" might find relevant things.
Object-oriented is a very general topic and it can be
used to describe many ideas in the presentation manager,
as well as many ideas in Windows GUI for that matter.
Can you be more specific? I especially do not understand
why you say MS "lacks vision".
>> Is it possible for you to explain in a few sentences what those OS/2
>> ideas that you prize are?
>
> Mostly it's little things that you only notice when you have to do
> without them. Simple example: suppose you have a frequently-used program
> that you want to keep a pointer to, on the desktop or in a "useful
> programs" folder or something like that. To do this, you have a choice
> between creating a shadow or creating a program object. A shadow is the
> same sort of pointer that Windows provides. A program object is more
> flexible because it has its own settings: whether it's to open
> full-screen, windowed, or minimised; what the working directory is; what
> sort of data files are associated with it; whether it's scheduled to run
> periodically; perhaps some parameters; etc. It's not unusual to have two
> or more program objects for the same executable, with different parameters.
Many of these features already exists in Windows in that
one can use a LNK file to provide per-invocation
customization of an executable via the command line
and/or the environment variables. Of course one has
to program the executable to look for the per-invocation
data in the first place.
Windows has a scheduler and daemons and batch files are
centrally managed through it. From a management and
security point of view, I prefer this arrangement than
having program objects scheduled themselves.
> There are many context-sensitive menus. For example, if I want to open a
> folder view of a specific directory, I just click on the "Drives"
> object, and a menu opens with a list of the disk volumes. Click on one
> of them and a submenu shows the top-level directory, and so on down to
> the subdirectory I want. That gets me to where I want to go in about a
> second. Doing it the Windows way takes many seconds. If I want a command
> prompt I click on the "Command prompts" object, and I get a choice of
> OS/2 window, OS/2 full screen, 4OS2 window, and so on. (The DOS and
> Windows shells don't get much use these days, but they're still there
> for anyone who likes playing ancient games.) I can add to the menu if I
> wish, for example to add a command shell that opens in one specific
> directory.
I am sure what is it that you want here. In Windows,
programs are selected from a number of places: the
desktop, the start menu, or the taskbar. One rarely
needs the directory browser (Explorer.exe) to access
the programs. Nonetheless, if one wants, one can
type in a complete path into Explorer.exe instead
clicking through the intermediate directories.
And yes, Cmd.exe is just another executable (one that
has a console interface).
> (By the way, my drives object includes drive H, which is actually mapped
> to directories on two other computers. A convenient way to move stuff to
> and from the server machine under my desk. (The other computer is an
> OS/2 file repository in the USA.))
Yes, Windows can mount remote directories and other
o/s and standalone devices can implement the SAMBA
protocol.
> Because object classes can be subclassed, a suitably skilled programmer
> can add desktop extensions. One that I use often is called DragText. If
> I see some text, on a web page for example, that I want to keep, I can
> highlight it and drag it to the desktop (or any open folder), where a
> data file will be created. Or I can drag a complicated arithmetic text
> string from a text file, and drop it on the calculator I wrote, which
> will evaluate the expression. Just this year someone introduced a new
> kind of folder view, which combines some aspects of the traditional icon
> view and tree view. I can open any folder in that view if I wish.
Copy-&-Paste and the similar Drag-&-Drop are
application level features. The o/s should not
handle them other than providing the underlying
inter-process communications facilities. In any
case, MS published the protocols and implemented
the functionalities in its own programs and run-time
libraries. Thus, almost all the programs in Windows
support copy-&-paste for plain text and many also
support that for formatted text. Likewise, drag-&-drop
for file objects is almost universal wherever
applicable.
Supporting specific folder views is a matter of
run-time libraries and has even less to do with
the o/s.
> One very valuable (to me) extension lets me click once on the desktop,
> and I get a menu of the programs I want to get to easily (some on the
> top-level menu, most in submenus arranged by category). It adds what the
> Windows Start menu would have done if it had had a better designer.
Underneath the Start Menus in Windows are just regular
folders.
> If I'm in a command-line shell, and I want to open a GUI view of the
> current directory, I just type "oo ." where oo is an "open object"
> script, and the dot parameter means "current directory". I could equally
> well have typed "oo firefox".
In Windows, one can type "Explorer ." in Cmd.exe to open
up the current directory. Not sure why anyone needs
to do that though. Note that "current directory" is a
deprecated concept in Windows. Programs generally do
not look into the current directory for anything.
Btw, Windows also has the PowerShell in addition to
Cmd.exe. While few have bothered to learn this program,
it has an advanced design in which objects, rather than
just plain text, flow in the pipes.
> That's just a sample. Basically it's about user convenience. There's not
> a lot that you can't do with any other OS, except that every other OS
> does it in a more roundabout way.
With due respect, I disagree with your assessment.