Guidelines for Contributing to QB64

[SMcNeill]

Our guidelines are the same as always:


Quote from Galleon:

I was recently asked for guidelines about the process for contributing to QB64's source code/core functionality.

I am supportive of ANY change to QB64 which:
1) Will not break existing functionality in any way
2) Is multi-platform compatible
3) Does not grossly/negatively interfere with the QB64 programming experience
4) Does not contain any known bugs
5) Is/Will be clearly documented so others can use it (either on the forum or in the WIKI)
6) Does not allow mixed language/CPU specific command integration (such as inline C++ code, assembly, etc)
7) Is not malicious in any way

Does your idea meet all of the above criteria? If so your next steps are...
1) Code it! (make sure you note any files you change and where for your own reference)
2) Submit it.
i) If you are a QB64 repository contributor, grab the latest version of the repository, make your changes and push them (I and the community will test the next dirty build [which is automatically created from the repository] and as long as it works, job done!) or...
ii) Become a repository contributor by asking me on the Q&A forum

Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
- Path finding
- Sorting
- A suite of string commands
- University-degree level math operations
- A circle fill command
- ODBC functionality
- OOP
- Name spaces
- Option explicit
- Web server interoperability
- Nullable/Reference types
...someone does.

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.

[Fifi]

Hi SMcNeill and all the others.

Would it be possible to have ALL the QB64PE messages in a single file and then referenced by numbers in the source code, then one message file per language such as:

Code: (Select All)

' File 01
' source.bas file
Arg$ = COMMAND$                ' the Arg$ parameter receives the message file name
$INCLUDE Arg$                  ' the messages file is included in the code
_Title msg001$                 ' msg001$ = "Hello"
Input msg002$ , (name$)        ' msg002$ = "Please enter your name: "
                               ' msg003$ = "Welcome to QB64PE 3.2.0 and its real time debugger"
                               ' msg004$ = " :)"
If name$ = "" Then
    name$ = msg005$            ' msg005$ = "my dear user."
End If
Print msg002$ + name$ + msg005$

' File 02
' US messages file
' msg-us.inc
msg001$ = "Hello"
msg002$ = "Please enter your name: "
msg003$ = "Welcome to QB64PE 3.2.0 and its real time debugger"
msg004$ = " :)".
msg005$ = "my dear user."

' File 03
' FR messages file
' msg-fr.inc
msg001$ = "Bonjour"
msg002$ = "Merci d'entrer votre nom : "
msg003$ = "Bienvenue dans QB64PE 3.2.0 et son debugger temps réel"
msg004$ = " :)".
msg005$ = "mon cher utilisateur."

.../...

' File XX
' IT messages file
' msg-it.inc
msg001$ = "Ciao"
msg002$ = "Per favore inserisci il tuo nome :
msg003$ = "Benvenuti in QB64PE v 3. e nel suo debugger in tempo reale"
msg004$ = " :)".
msg005$ = "mio caro utente."

This would allow to translate QB64PE in a vast majority of languages for a real worldwide adoption.

With the appropriate mechanism, this would also allow to dynamically change the user interface language as my devs team did in our glorious time for our product such as Turbo-Text or Remote Services Management (the first cross platform graphical remote control tool ever made long long time before all the TeamViewer and any competitive products).

I know it's a very "formal way" to code, and it's a big job to do but it's also a very easy habit to take for good developers.

Note: I use a very similar method in my QB64PE and InForm-pe installation script but all the different languages are integrated in the sole script file itself.

Now, if this effort is made in a future release, I'll be very happy to actively participate in the translations.

Same thing for the WiKi.

BTW, if this is to be done one day, this will be the excellent occasion to clean the code, but also mainly to document it. I've never ever seen a so poorly documented code in my 40+ years as software publisher. Obviously none of the devs ever worked for IBM or MS.  

Looking forward for your returns.

Cheers.
Fifi

[RhoSigma]

Fellippe made a program a while ago, to extract literal strings from a bas program, put it into an array in a include file (where you can add more languages). In the same run it will modify the original program to use the string array from the includes.

https://github.com/FellippeHeitor/Localizer

Forget that, now I see you spoke about QB64PE itself, not about one of your programs.

Unfortunately making QB64PE multi-language it is not done by exchanging the strings. You would also need _MAPUNICODE for the language and a proper unicode font to correctly print all those special chars in  some languages, but the biggest problem would be the input system. None of the various input functions does work 100% reliable with any other than US-Keyboard layouts, and only some kludges were implemented for other keyboard types, accented vowls, "AltGr" mappings and deadkeys. And that's the keyboard input only, what's about reading text from a chinese (ie. unicode/UTF-8 etc.) file?

To make QB64PE a reliable multi-language program it must 1st completely transposed from ANSI into a proper Unicode application, and I guess that will not happen soon. Currently we are just 3 main developers here, able to put an hour or two into the project every day. And as you mentioned the code and comments are in a desolate state, and one of the two hours we must already waste to find out what must where and how changed to get our new features implemented.

[mnrvovrfc]

BTW, if this is to be done one day, this will be the excellent occasion to clean the code, but also mainly to document it. I've never ever seen a so poorly documented code in my 40+ years as software publisher. Obviously none of the devs ever worked for IBM or MS.  

Try reading "libqbx.cpp" while Galleon was in control, not now that many things are indented and gathered more sanely. A bunch of close curly braces on the same row, or even worse, on the same line. Anyway the ones that coded the "libvorbis" library or something like that wouldn't win awards neither putting vulgar slang into comments, instead of explaining what is being done with the code, and pretending it's the only documentation ever needed.

[mnrvovrfc]

The likelihood is high most people interested in using the QB64 IDE expected it to be in English so it doesn't bother them. Otherwise they use NPPP or some other program that could be customized for language. It's unfair that Asians most of all have to learn European languages so more products are open to them.

I'd like to know the opinion of somebody else whose first language isn't English, if it looks strange to do a "PRINT" statement with a quotation not in English. Or if it looks strange looking at source code with mixed language. To me, it was strange looking at many contributions of the German programmers from the Purebasic Archive Vault. At the same time it was funny sometimes and entertaining, although I couldn't understand everything they said. On the other hand, the French programmers of the same were somewhat reserved. I don't know, I looked at more code from the Germans...

How about if it bothers somebody that could read right-to-left writing? More than likely he/she isn't going to be even interested in the QB64 IDE. It's not even going to be done with Cyrillic characters because there are a lot of pratfalls involved about the subtleties of Russian and other languages of the same family and a couple such as Mongolian which happen to use that alphabet.

If there is a great increase in the users not from U.S.A., not from Western Europe using QB64PE then there would be a need to do something to the QB64PE IDE, likely an overhaul. But now it's a low priority. As it stands, it's still slow, like the pre-version 1. Mostly I load it to format source code to get capitalized keywords (I really dislike the Freebasic-like manner I keep seeing on this forum).

BTW I could make a few translations en Español, but English is my first language. :tu:

[mnrvovrfc]

One more thing. Setting "C locales" could suck a lot. I had a music application fail because of it, because I was trying to use a plug-in in which the loaded sound names were in French, with accents and whatnot. I was forced to use a different program that could handle those names and save independent files with names as if they were in English. Another program didn't display stuff correctly due to a font it asked for a language other than English. The cases were rare, though, and this was 32-bit and a long time ago. Now we have Unicode to worry about which could present new headaches only because it has to represent almost every symbol that could be had in writing, especially Asian languages. No wonder a lot of programs cost money that handle elegantly switching from one language to another. The Linux distro builders such as the Russians of ALT Linux have to be praised as well as few other examples of free software.

Almost forgot to mention that I purchased a music plug-in that crashed after I acquired an update... because the developers moved it up to Unicode. Also no configuration would load into the new baby that I had saved with the older version. It was frustrating.

[SpriggsySpriggs]

I don't wish to speak for Matt or Steve but I think native Unicode support is not being considered right now. I know that you can write programs that take advantage of Unicode but it also adds a lot more problems. I think the amount of work needed to have this option would be staggering.

[Fifi]

Hi there,
So, it's now my understanding that the devs team is composed only of few persons.
May I guess: SMcNeill, RhoSigma, DSMan195276 and mnrvovrfc? May be few others?
In any event, congratulation for your excellent work and fabulous effort to bring QB64 back to life again.
Now, from what I read above, I suppose it would be better to restart from scratch than to try to modify the current code to create an unicode application.
From my part, even after reading the QB64PE code several times, I still can't figure the architecture of the project itself due to the lack of comment.
And if I had to start such a project with some friends, I guess I would do it in 4 different multi threaded parts communicating together, one thread for the IDE, a second for the Debugger, a third for the WiKi and the fourth for the compiler and my language of choice should surely be the pure ANSI C.
BTW, in the Options/language menu, what code page should I select to have the following complete string correctly displayed in the IDE and in any source: "à â ä é ê ë è ç ù û ü €" (French character set) that I need for programs used by the vast majority of froggies who don't speak a word of English?
TIA.
Cheers.
Fifi

[mnrvovrfc]

Hi there,
So, it's now my understanding that the devs team is composed only of few persons.
May I guess: SMcNeill, RhoSigma, DSMan195276 and mnrvovrfc? May be few others?
In any event, congratulation for your excellent work and fabulous effort to bring QB64 back to life again.
Now, from what I read above, I suppose it would be better to restart from scratch than to try to modify the current code to create an unicode application.
From my part, even after reading the QB64PE code several times, I still can't figure the architecture of the project itself due to the lack of comment.
And if I had to start such a project with some friends, I guess I would do it in 4 different multi threaded parts communicating together, one thread for the IDE, a second for the Debugger, a third for the WiKi and the fourth for the compiler and my language of choice should surely be the pure ANSI C.
BTW, in the Options/language menu, what code page should I select to have the following complete string correctly displayed in the IDE and in any source: "à â ä é ê ë è ç ù û ü €" (French character set) that I need for programs used by the vast majority of froggies who don't speak a word of English?
TIA.
Cheers.
Fifi

I'm not one of the contributors of QB64PE. I try to help disseminating my knowledge of how it was with M$ QuickBASIC and QBasic, and how QB64PE is the same or different.

A rewrite of a BASIC compiler might be possible with ANSI C but many things require C++ instead, and it's going to be frustrating trying to convert it into C. The "libqb.cpp" is almost all in C but it does benefit from a few C++ features. Somebody else created a BASIC that creates C code which has Internet functionality but nothing that could load images and music which would interest a lot of people over calculating with very-large or very-small numbers, parsing CSV files, emulating a LISP interpreter or some other esoteric use.

About the codepage, but this might not be enough for you:

https://staging.qb64phoenix.com/showthread.php?tid=855

[grymmjack]

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.

This is the way.