🚀 go-pugleaf

In article <bjorn.757443367@box.ludd.luth.se> bjorn@ludd.luth.se (Bjorn Fahller) writes:
>I tried to mail you, but the letter bounced:
>
>
>>GLOBAL CHANGE OPTION FOR THE WPS
>
>I like this one.
>
>>COMMON INSTALL PROGRAM
>
>Very much needed. Also, see later...
>
>>NEW FILE SYSTEM
>>INSTALLABLE FILE SYSTEMS FOR REMOVABLE DEVICES
>>MOVEMENT OF SHADOWS IN TO THE FILE SYSTEM
>>MOVEMENT OF INFORMATION FROM THE OS2.INI TO THE FILE SYSTEM
>
>All of these can be made the same. Take the "NEW FILE SYSTEM" as described,
>and add a new file type "Abstract" (in addition to the two available, "File"
>and "Directory"). The Abstract file type is for "shadows" (links), Program
>objects, etc.
>
>>LONG FILE NAMES IN FAT
>
>Good, but probably difficult to implement with the current EA handling scheme.
>
>>MULTIPLE INPUT QUEUES
>
>Very much needed.

Second on the list.

>
>>A SIMPLE, ROCK SOLID INSTALL PROCESS
>
>needed.
>
>>RELIABLE WORKPLACE SHELL BACKUP/RESTORE (OS2.INI AND DESKTOP DIRECTORY)
>
>Good, but automatically solved if the additional file type "Abstract" is
>incorporated, and a file backup program.
>
>>MAINTAINING THE NUMLOCK STATE (AS DEFINED BY THE BIOS)
>
>Good.
>
>>COLOURFUL ICONS
>
>Agree. Changing the default colours and redrawing the icons did an awful lot
>for WIndows 3.1.
>
>>SCROLL-BACK BUFFER FOR OS/2 WINDOWS
>
>Good.

Would be great.

>
>>MOUNTING DRIVES INSTEAD OF HAVING DRIVE LETTERS
>
>Desirable, but probably unrealistic, since just about any program aware of
>drives would break :(

This could possibly be done in a seamless way through the use of some
sort of sybolic link which pointed to the volume label [ie sybolic link
volume-d in the root of C: points to the volume which has a volume label
xxx].  This should allow the best of both worlds as the drive letters
would still be there for programs which needed them but you could still
have mounted drives.

>
>>MAKE "/" AND "\" ACT THE SAME FOR DIRECTORIES
>
>Easy to implement on the operating system level, but can lead to enormous
>difficulties with programs that are hard coded to take "/" as a flag separator
>for arguments.

Also there would be the problem that -filename is a valid filename under
OS/2 and DOS.

>
>>SUPPORT WILDCARD EXPANSION IN THE SHELL
>
>Good, but should be added to the file dialog boxes as well.
>
>>COMMAND ALIASES IN CMD.EXE
>
>Yes.

Agreed or simply replacing cmd.exe with something more like bash etc.

>
>>TABLE OF EXECUTED COMMANDS
>
>Very minor importance, but not too bad.
>
>>LIST/KILL PROCESS COMMANDS
>
>Yes.

Top of the list!!!!!.
>
>>UNICODE
>
>Very much needed.
>
>>DATE AND TIME FORMAT
>
>Necessary but not enough. OS/2 is unfortunately VERY lame on issues like this.
>I can't make 4 digit year display the default, for example, neighter is there
>any support for long date formats (Like "January 1st, 1994").
>
>In addition to this, the API needs to be expanded and include functions for
>converting date/time/floating-point-numbers/currency to/from string formats,
>otherwise the settongs in the country setup are more or less useless, since few
>programmers bother to parse the info (it's tricky as hell, especially with the
>floating point numbers).
>
>>FASTER BOOT OFF FLOPPY
>
>At least some indication that the system is still alive and working.
>
>>ADD SEPARATORS FOR NUMBERS RETURNED BY CHKDSK
>
>Would be solved by adding the above mentioned functions to the API, and acually
>USE them in all programs.
>
>>RESIZABLE SHELL WINDOWS
>
>Yes, and the default shouldn't always be 80x25, but something one can set
>in the program object.
>

Great idea.

>>RESIZABLE FONT FOR SHELL WINDOWS
>
>Same as above, make it possible to set it from the program object, so that
>different shells can have different font sizes on start-up.
>

Agreed.

>>DISPLAY POSTSCRIPT
>
>Disagree. Display PostScript is nice, but pig slow (talking from experience).
>Maybe include a program that converts display postscript to something else,
>in the development kits, so that the developers can work with display
>PostScript (since it really is nice), but not have to bother about the
>extreme slowness of it.
>

The idea of being able to display display postscript is nice but
considering that there are alot of people who do not have fast hardware
and that it would not really give a huge ammount in terms of
funcitonality over the present system I wouldn't be in favor of it.

>>DEFAULTS NOTEBOOK FOR SHELLS
>
>Right.
>

Agreed.

>>DEDICATED SWAP PARTITION
>
>Whoeheartedly disagree, since a separate swap partition on the same drive
>as the date/system will reduce performance. The better way to do it is to
>simply make larger swap files the default.
>

I;m up in the air over this but I would personaly be in favor of any
system which could reduce the possibility of the system going down due
to running out of disk space.

>------
>
>Now for my own additions.
>
>OPTIONAL DISABLING OF MENU DROP DOWN ON RIGHT ALT-BUTTON.
>
>Odd, it may seem, but on many non-US keyboards, the right Alt button is
>used when typing brackets and such, since many other countries have a few
>additional letters in the alphabet. Now, when writing something, and a
>bracket is needed, and you slip on the keyboard (happens once in a while)
>that darned meny drops down, and it can be pretty annoying.
>
>REFERENCE COUNTED RESOURCES
>
>Users won't notice this, except for a (hopefully) increased performance, due
>to reduced memory demands. As it is now, if you have an enormous lot of
>fonts, and you run a program displaying all your fonts, the system will be
>sluggish afterwards, until the next restart. This is because the system assumes
>that since a font was once wanted, it just might be so in the future, and keeps
>it in memory so that it can be used quickly. If, instead, a reference count is
>incremented for each font when a process requests it for the first time, and
>decremented when the process dies, the font can be unloaded when the count
>goes to 0. While I haven't calculated on this, I'm convinced the performance
>gains by not needing to have the fonts loaded will by far outweigh the
>losses of having to maintain the reference counters. I'm not sure if the same
>applies to other resources, but if they do, the same should apply to them as
>well.
>
>BACKGROUND COLOUR ON ICON TEXT
>
>I'm surpriced this wasn't listed, since just about everybody that ever used a
>background bitmap wants it.

Very handy.
>
>CASCADABLE MENUES
>
>I can add items to the object menues, even submenues, but I can't add sub-sub
>menues. Why?
>
>MORE DRAG DROP
>
>It should be possible to drop a file on the PATH entry field of program
>objects, a directory on the WORKING DIRECTORY on the same. To drop directories
>on the PATH entry field of the search dialog and so on.
>
>ASSOCIATE VIEW.EXE WITH .INF FILES
>
>Comments unecessary.
>
>STANDARD UNINSTALL PROGRAM
>
>Most programs fill your system with files a little here and there, your OS2.INI
>with some entries and such, and there's just about no way a user can clear
>the system of a program, short of reinstalling OS/2. If there was a standard
>uninstall program, and using it, from a developers pespectice, is simple and
>well documented, the pain will be reduced severely (I know a lot of programmers
>still won't bother, but if a few will a lot is gained).
>
>HEAVILY INTEGRATED WPS APPLETS
>
>The applets should be so neatly integrated with the WPS you won't ever see
>the programs, just the data objects.
>
>(as an addon, DEVELOPER DOCS ON HOW TO WRITE WPS APPS!!! How can lean WPS apps
>be developed when the docs are so few and vague?)

As an addtion to this I would like to see a set of sample interface
definitions for things like interfacing protocols to comms programs [ie
something like what is done in ZOC but as a general standard].


And for my wish list.

I would like to see a couple of additions to the WPS.

    the option to display the size of a directory - this can be done
    under the command line with no problem but seems impossible to do
    under the WPS.

    extension of the find command WRT shadows - this is more to do with
    the way the WPS handles multiple shodows with the orginal command.
    Where you have only one shadow selected you can use the orginal
    command to locate, copy or delete the option but this command
    disappears when you have more than one shadow selected.  If you
    could use this command on multiple shadows then the combination of
    this and find would make a useful file maintenace tool that would be
    fully intergated into the WPS.

    the ability to define program objects that will accept more than one
    item [preferably via a notebook setting]. This would make the WPS
    more consistent in my option as you would no longer have some
    objects like the shredder which will accept multiple objects whereas
    user defined objects can't. Also it would be very useful for obvious
    reasons.

That's it for the moment
Joe.

--

So sad I've lost my sig.  :-(.