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