[ros-general] Ideas (by Paulo Correa Silva)

[KJK::Hyperion]

At 01.47 22/02/2004, you wrote:
>• Indian keymaps:
[...]

from what I've heard, Indian support is going to be a bitch. Unicode 
support for Indian is badly designed - or so I'm told - and not able to 
represent all Indian text. Operating systems where file names are binary 
strings (like most POSIX systems) aren't going to be affected by this. We, 
being Windows, will receive the equivalent of a full frontal impact with a 
semi truck. Either we'll make liberal use of the user-defined Unicode range 
(hoping not to tread over other uses of this range - Microsoft Interix, 
IIRC, uses characters in this range to represent characters that would be 
otherwise illegal in file names on Windows, like ":") or we'll be left behind

>• Startup Screens:
>Is an idea i have about contributing and voting for different illustrated 
>boot screens (640x480 4bitdepth (16 colours)) on each version of ReactOS, 
>from anyone wanted to contribute.

Microsoft did, IMHO, the right thing in Windows XP: no boot screen. Just a 
progress bar and a logo. No cheesy new-age splash screen like in Windows 
98, no phony boot GUI like in Windows 2000. Just a logo in basic colors on 
a solid black backdrop. I'll add that we should consider freeing our kernel 
of legacy support - the assumption that all x86 machines have a display, 
and a VGA one at it, has to go. Boot screens sure are pretty, but they 
don't justify dedicated kernel support

>My idea for ROS boot screens were about illustrations, drawings, 
>paintings, photos and whatever (a bit like used on Gimp and Sodipodi), 
>which theme would mainly focus on the ReactOS idea

hrrrm. Your samples look very... dubious. I don't want ReactOS to be 
associated with blatant political propaganda art. Can't you find something 
a bit more neutral?

>• VGA and SVGA drivers:
[...]
>- Gamma adjust:
>Would affect the pallete on up-to-8bitdepth screenmodes (like 640x480 4bit 
>- generic vga)

Pass

>- Grayscale mode:
>Would be great having it available, specially on generic vga mode, like 
>provided by default from BeOS and NextSTEP. - this would be nice on 
>getting working the opentype driver smoothness over a low bitdepth 
>screenmode as generic vga is.

Can do. Not sure if the control panel will be able to tell the difference 
between grayscale and other paletted modes, though

>- Display rotation (90degree step) and flipping:
>I have not here the needed alghorithms, but it seems to be not that hard - 
>this would also work on generic vga mode - talking from me, beign possible 
>to use display in a vertical position has a vital importance.

Not sure if any drivers can be natively configured for this. If they can't, 
you'll only be able to implement it on bare framebuffers (no acceleration 
nor hardware-specific optimizations) and with a pretty big deal of 
resources. This is something better postponed to when there's a real need

>- Virtual screen mode:
>This would be very useful on, when we have just a 4x3 monitor, getting for 
>example, a 1280x960 resolution from a 5x4 resolution like 1280x1024, 
>avoiding so pixel ratio distortions or border vertical bars.

Same as above. If the driver doesn't support the resolution, 
double-buffering with a filter driver is the only way, and it turns your 
display into a cow - slow and eats a lot

>• Drive letter assignments:
[...]
>My idea is you can assign any kind of string (unconflictable like A-to-Z 
>simplicity) before colon, just like ArOS and AmigaOS does

and don't forget VMS. That drive letters in Windows NT are virtual aliases 
comes directly with the VMS heritage

>if this can work easily on FreeDOS, i think surely would work on ReactOS 
>(as well any kind of operative system compatible with DOS and w32 
>depending of the wish of making it possible).

Doable (I'd go as far as mounting removable volumes under their label, so 
you could e.g. insert a CD-ROM in any drive, instead of the first one you 
inserted it into), but programs will complain. Drive letters need to stay 
for some time, altough they can surely stay hidden for the time being. And 
using a single colon conflicts with the syntax for streams, but you'd 
probably usually put a backslash right after the colon, so that could be 
used to disambiguate

>• Generic inkjet printer drivers:
>Since all seems to work in the same way (maybe those prehistoric ribbon 
>printers also does), the idea would be using just one driver for whatever 
>printer you may have connected to your computer (which could be parallel, 
>serial or usb), getting these specs from a kind of plugin document you 
>also can choose when printing (well, i don't know if GimpPrint works in 
>the same way...)

Done! Sometimes Microsoft is painfully good at designing software. Printer 
drivers have *always* worked like this, in the Windows NT family. There's 
three master printer drivers (plotter, Postscript and universal), and 
virtually all drivers are plug-ins and/or data files for one of them 
(altough you can still write your own driver - even as a kernel-mode 
display driver!). Even the configuration UI is unified between the three - 
unusual even for Microsoft, but a welcome plus. All of this is widely 
documented

>• Fonts:
>Possibility of installing svg fonts as well you can the ttf ones - it 
>seems to be related to be freetype.dll issue or something like - the goal 
>of svg is you beign able to install fonts which you can edit these 
>beziers, hinting and kerning pairs as simply as using a txt editor, since 
>svg is a mere xml-based txt format.

The mention of XML worries me. If this will ever be supported by ReactOS, 
it will likely run on a non-validating engine, which may not be what the 
author of the font intended but is the only way to parse XML sanely in 
kernel mode (to the naysayers: XML adds no overhead, as it's only used in 
the very first pass. We don't need the bloat of DOM for this, a tokenizer 
like SAX will be more than adequate)

>• Tape Backup drivers:
[...]

Not a goal for ReactOS