22 Feb
2004
22 Feb
'04
6:59 p.m.
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