KeymapsConvertedPkf_040308.zip (564kb)
Bootscreens_040209.zip (196kb)
TranslationNorm_040308.zip (24kb)

2004jul16 - Paulo Silva (correasilva_at_tugamail_dot_com)
(english grammar and vocabulary fixes and improvement are welcome =) )

This page is merely about ideas description about what i think i can help on ReactOS development, and the downloadable items above are what i think can be helpful. For now, the downloadable items are what i got until now - ideas about startup screens, keymaps, and so on.

•• Converted Keymaps:
As a newbie, i never compiled a keymap until recently.
This compressed folder has compilable keymaps and their txt keymap documents, both Ascii and Unicode (utf-8), and their respective converters.
Some bugs still exist, like missing Deadkey accenting (the strings are there in the sources anyway...).
I'm using AbiWord for these txt documents encoded as unicode-utf8 (i'm looking for a simpler unicode-txt editor while ReactOS hasn't their own with this feature - is someone skilled to port Yudit for ReactOS?) - from this way, you can convert foreign-encoded ascii pkf i have from ascii keymaps into uuencode-utf8 encoding for converting.
Overall, my idea for now were having universal ones would we can easily and fastly contribute with a large and good amount of keymaps - and better: making you able to create your own keymap for your personal needs (like phoneticals, maths, foreign, and other kind of characters, as seen from www.unicode.org pdf charts).
Since the compilable keymaps are result from a converter, some bugs still existing, like CapsLock on Swedish keymap, still exists, and may need be fixed by hand. (well, better than nothing...)
The indian keymaps (9 at all) were converted almost by hand (from my conversion results) - are from http://indlinux.org/keymap/keymaps.php, and is still temporarily using Ctrl+Alt and Shift+Ctrl+Alt instead of CapsLock changes (for now seems to be good enough for indian-unicode writing testing) - the method of character changing by CapsLock (which i'm curious to know) may be close to that one used by KanaLock on Japanese keymap (is Korean keymap working in the same way?).

•• 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.
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 - and this would be an interesting way for artists having ReactOS as their art gallery for more author visibility.
The main difficulty would be sorting the colour palette for this bmp resource, since the index colour 0x00 seems to be better as the darkest one or black (because it's also used at display border), and the 0x01 used for progress bar - i only could "easily" rle-compress these bmp using Gimp.
Suggestions for easier procedures are welcome.

•• Resource Translation Norm:
This would be a norm guide for app resource translation - each item like from menu, button, checkbox and so on is indexed, and each text document would be in each language, which can be information used from translation scripts (just like 'Find and Replace' from a text editor, but between 3 documents: original resource, original language, destination language) - this would work also as translation from a database.
The meaning of this idea is trying to uniformize the translation method, getting things easier, faster and accuraced.
If there are better ideas for translations please let me know.

__

More ideas and suggestions (i need to organize this better):
(please take a look again - i may updated this meanwhile )

•• VGA and SVGA/Vesa Drivers:
If i'm not that keymap coder expert, i'm less about VGA drivers - and this of course wouldn't lack me on having ideas about it.
- Gamma Adjust:
Would affect the pallete on up-to-8bitdepth screenmodes (like 640x480 4bit - generic vga) - algorythm for this is very easy, i think.
- 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. This is not about replacing the halfbright-primaries palette based generic vga driver, but beign able to choose from an alternate can be close for some ReactOS users needs (like me). This driver would work maybe in the same or close way to a SVGA screen mode, which index colour result is got from a rgb value with a formula like indexcolour=int((((b*11)+(r*30)+(g*59))/100)/16).
- 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.
- 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.
This also applies when we have a 16x9 display (lots more popular nowadays - like from some plasma and portable-computer monitors) you have very reduced choices of available resolutions - you know, even having available a resolution like 640x360 for these monitors sounds good...
The possibility of removing unused display resolutions (like 1280x1024) from the choice list (from the display settings control panel applet) seems to be also very welcome. (i think you can do it easily on those old versions of MacOS classic (8 and 9), for example)

•• Drive Letter Assignments:
At the mailing list some told about problems with it, about beign easier or harder to use compared to Linux.
My idea is you can assign any kind of string (unconflictable like A-to-Z simplicity) before colon, just like ArOS and AmigaOS does - these ones uses a command like: 'Assign Workbench: dh0:', when 'Assign' is the command, 'Workbench:' is the desired assigned drive name (folder, imagedisk or device, for example), and 'dh0:' is the device to be mounted (on ArOS and AmigaOS, 'dh0:' is theorically the same of 'C:') - 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).
Some people may imagine it's impossible, keeping compatibility, FreeDOS and ReactOS using more than 1-character-size device assign - but when Linux is now supporting machines with 512 processors, why not making FreeDOS and ReactOS able to access 512 devices as well, what i think is not impossible, since the easiness we have now on connecting and mounting lots of usb devices, imagedisks, and network devices - here may comes 2 and 3 character device names, and so 8, 32 and 255, and here comes the possibility on mounting devices by name instead of just one character.

•• 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... - this may have the same difficulty as from keymap drivers, so the alternate suggestion is all inkjet printer drivers coming from the same sources - only changing the needed codec.)
Features available (lacking on now considered obsolete printers and drivers) can be like postscript emulation (very important for halftoning effects), poster tile printing, paging, choosing and/or creating custom halftone patterns (very needed indeed - the difficulty on custom patterns would be, if hard getting external files, beign only possible to edit from sources or resource editors), 'unlimited' paper lenght (for banners and tile printing), mirror and rotation (useful also for border avoiding), pantone-like overprint separation (?), printfile to picture conversion (and vice-versa), etc.

•• SVG and TTX 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.
In the meaning time, ttf-svg converters are also welcome...
More news about svg and ttx - .ttx is a .xml font format obtained from .ttf, as well as human readable - i started, for personal curiousity needs, to make some readers in SdlBasic for understanding how both works. Ttx looks as very interesting available choice on getting txt-like instalable fonts, which i hope freetype libraries (as i think used on ReactOS) would support it...

•• More Unicode Fonts:
Next versions of ReactOS maybe may need to have more fonts, not about typeface family diversity, but more focusing cover more unicode characters (like Arabic, Japanese, Chinese, Korean, Georgian, Cyrillic, Thai, Indian, Maths, Phonetics, Ligatures, etc.) (i'm really curious about it!). Linux distributions may have these fonts as ttf maybe or surely ReactOS can use it without further problems.

•• Tape Backup Drivers:
May have interest on people want to focus ReactOS usage on servers and workstations - some travan drives (the most popular i think), not obsolete at all, which some manufacturers seems to not supporting even NT4... My concern about this item was, with open-source driver development, solve this important need - my problem is for now having enough coding knowledge for doing it, since i'm really a C newbie (so we ReactOS developers and users surelly need help about it).

•• Human Interface Guidelines:
Coders would atempt do need creating forms, icons and all that gui-resource may need to follow or create these documentations.
The first excellent documentation i got knowing were from Apple (for MacOS 7 to 9 and OS-X) - all rules for visually and ergonomicaly optimize these are there.
There is also HIG available about Gnome somewhere. I still don't know none about w32, BeOS, OS2, Motif (Irix4dwm, Solaris, etc.), NextStep, and so on (if someone know, please tell me).
Also related to HIG, KDE 1.0 developers made a huge mistake on control panel form, which applet form is sized as 800x600, which makes it unusable on generic-vga resolution (640x480) - just one control panel having everything is interesting, but i really hope ReactOS developers wouldn't repeat this mistake on using that 'huge' forms.

•• Background Pictures (Wallpapers):
Since it's not available yet, i'd focus suggesting .xpm support as well .bmp and others known, like .png and .jpg (who knows also vectorial ones like .svg) - the advantage of .xpm is being text editable, and surely i think this format needs more popularity in the w32 world.

•• System Sounds:
Would be not bad idea supporting .mp3 and ogg-vorbis formats for this as well .wav (maybe also .mod-like formats).

•• ROS-Apps:
I'd suggest a small list of very needed basic and small apps for Reactos i think everybody may also say as useful:
- Hex editor (i think this must come with every OS)
- Txt editor (a notepad-like, not file-size limited, and with txt encoding support (like unicode-utf)) - command highlight for programmers may be welcome too (from a folder with respective customizable libraries) - maybe apps from sourceforge like ProgrammersNotepad, SharpEdit and Notepad++ can be interesting - a good reference for simple text editors can be also StyledEdit from BeOS. - Yudit would be a very interesting app ported to ReactOS.
- A paint-like editor (useful as DeluxePaint (with grid and stencil features), and also with .xpm support) - would be an useful app for testing PrintScreen clipboard screenshots
- a Resource editor (like ResourceHacker, or ResEdit from MacOS)
- a .mod tracker (it can be fun...), which you can save tunes in txt format, and also useful for gui and soundboard testing. (some people may think there are better applications for it - it's just a suggestion like any other)
- Post-Its (or Stickies, from MacOS-Classic) - from Sourceforge some app projects like this are related to Gnome or KDE which i think can be used with needed changes for running over w32api.
- a clipboard repository (like the ScrapBook from MacOS-Classic) - this is very useful

•• Ctrl+Alt+Del:
This one is really missing! ;)

•• Compiling ReactOS - step-by-step tutorial for newbies:
This one applies on me too, i really need this (maybe also 99% of the ReactOS users wanting to try it and is as C newbie as me)- so if someone will do it, please use a readable format for it, like txt, pdf or xml-based (AbiWord or DocBook) - please people avoid the only-online html tutorial messed with hundred of rooted hiperlinked pages, like lots of people used to do.

•• Installers:
This can be an interesting issue - maybe installers is not very close to a OS development, maybe it's more about ethics issue: there are still no good installers available to w32, at least as good as RedHat RPM - (i'm not talking about dependencies) what RPM have excellent (BeOS Valet works in the same way, afaik) is it shows a very detailed pre-log about everything (like where each file will be placed and what may be changed) before we ever think on clicking the install button (on w32 this can be applied on registry and config changing) - this can be one more ReactOS (and/or open-source w32 installer app development) goal- the compression format support used, like .zip, .gz, .7z, .rpm, .deb, .cab, .msi, and so on (some focusing probable compatibility) may depend of the availability of these formats as open-source.
This is mainly why i normally, when beign able to choose, download a .zip app instead of a installer-based app - explaining why: this reflects a bit my paranoid about installers, when the concern about maybe having to reinstall the whole operative system after an application installing always exists, and i think i'm not alone saying this.

•• One-button Mouse Support:
Very important issue too, since some MacOS-X users are curious about ReactOS and running rootly ReactOS on their machines over PPC architecture. As well, the usage of one-button mices are lots more comfortable to use. MacOS Classic, MacOS-X and Linux-PPC distributions (like Debian and YellowDog, i think), seems to use ctrl+click as right click - would be interesting ReactOS also defaultly supporting it as choice (but i don't know how possible it is).
Simplifying the question: how can the mouse driver see if ctrl key from keyboard is pressed or not?

•• Keyboard shortcuts:
Some developers insist on translating keyboard shortcuts - in my oppinion it's a huge mistake - some people, like me, likes more using the english version mainly because it keeps the english standard shortcuts are almost used everywhere, it's like a norm - who doesn't hate to press ctrl+t for Select All and ctrl+a for Open? (i'm almost sure not only english and american people are deeply laughing now reading this...)
More: maybe some rules (from programming guideline documentation) are needed for developers about keyboard shortcuts - in my oppinion, Ctrl+Alt and Shift+Ctrl+Alt, over the 48 Querty key group (those 4 rows), shoud be reserved for typing only, and only Ctrl and Shift+Ctrl for shortcuts (i think more than 80 shortcuts for an application is enough), and Alt and Shift+Alt for menu/context-like stuff - of course situations like Alt+PageUp are another issue.

•• From-and-to Linux Keymap conversion:
I think i told somewhere, converters beyond from txt configurations, like converting from Linux keymaps, will be really needed (as well vice-versa), specially when the sinergy got between both Linux/ReactOS are very welcome, as well in this keyboard issue. Btw, this pkf method can be also useful on creating keymaps for Linux and other OS may have even different ways of reading keymaps (like ArOS, BeOS and so on).

__

More:
Around July '03 i tried to start some Sourceforge projects i thaught would help a bit the ReactOS development - maybe these ones can be inspiring or hold from people can handle these ones: [chibema] [ngoro] [mbulu]

__

Links:
•• ReactOS site
•• ROSwiki site

__

Old Files:
KeymapsConvertedPkfUtf8_040224.zip (27kb)
KeymapsConvertedPkfAscii_040223.zip (230kb)
IndianKeymaps_040209.zip (48kb)