QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: bartok on August 12, 2021, 12:38:48 pm
-
Hi,
how we can see in the attachments there is a difference between some characters in the IDE and a text editor. The same difference for character like "à, è, é, ù, ò" and so on. For example, if I write "à" in a text editor, in the IDE, I have a different character. If I write "à" in the IDE, I have a dofferent character in the text editor.
Is there a way in order to have the same characters opening the file in the IDE and in a text editor?
-
The IDE natively operates in Code Page 437, using all original ASCII line drawing characters. Other editors must be configured to display such characters - you will have to either change font or encoding in those.
-
@Bartok
this is a old thread
see these two thread, but you can find also as to remap font for I/O from file and Keyboard
https://www.qb64.org/forum/index.php?topic=569.msg4262#msg4262 (https://www.qb64.org/forum/index.php?topic=569.msg4262#msg4262)
https://www.qb64.org/forum/index.php?topic=569.msg4293;topicseen#msg4293 (https://www.qb64.org/forum/index.php?topic=569.msg4293;topicseen#msg4293)
https://www.qb64.org/forum/index.php?topic=2121.msg113594;topicseen#msg113594 (https://www.qb64.org/forum/index.php?topic=2121.msg113594;topicseen#msg113594)
-
Indeed, old thread. It turns out that the first few characters in the original IBM extended ASCII characters set, those common accents used in French, Italian, Spanish, British pound symbol, and so on, are the same in the IBM original extended character set, and in UTF8. But then, from character 166 on, they diverge.
From my own point of view, I use the drawing symbols of that original IBM character set, 176-223, so I'm happy with the IDE set up be default as it is. Of course, editors that use UTF8 will show weird stuff.
I don't know about the Euro versions of MS Word, but the US version allows you to choose what ASCII extension you want, when opening a file which includes characters beyond 127.
Just wanted to add, for some reason, in their original extended ASCII, IBM was biased to French, and languages that use the same accents as French. And also biased to a subset of Greek symbols, not all of them. The more odd characters used in German and the Scandinavian languages are not included.
-
Just wanted to add, for some reason, in their original extended ASCII, IBM was biased to French, and languages that use the same accents as French. And also biased to a subset of Greek symbols, not all of them. The more odd characters used in German and the Scandinavian languages are not included.
Hello Bert22306.
The reason is obvious: the size of the market.
I wonder if QB64 will adopt the same philosophy!
Failing to follow this path shows a certain form of arrogance and disrespect for the non-English native developers who are legion.
Just my two cents.
Cheers.
Fifi
-
Those other countries can kiss my White privileged ascii. If it's so important to them, why don't they ban together and make Third-World-BASIC? We could do our part by donating _MAPTRIANGLE, so they could auto-cad their mud hut villages. Oh wait, did someone mention Italy in this thread? Yes! Well, that makes this a whole different story. The Development should jump on this immediatamente!
In all seriousness, I have been bitten in HTML coding by some of those Italian Unicode characters. I use QB64 to sort them out, when parsing those pages. So kidding aside, certainly it would be nice to be as universal as possible, but to what degree of effort? What about Mandarin characters or more diversely put CJK? Do we have that working yet in QB64?
Also, forgive my spoof on the "arrogance" issue. As a hobby language, the few people who contribute to the advancement of QB64 have to pick and choose the most beneficial additions to the platform. For instance, would it be better to make more programming features or try to make the language more universal? Certainly if we had developers from China, Japan, and other countries working on the project, things might be different. Certainly if we had millions of users world wide, the same would apply. Frankly it's amazing to me the project is as universal as it is, but it's like my mamma always used to say, "It's always something!"
Good night my little Roseanne Roseannadanna,
Pete
-
Those other countries can kiss my White privileged ascii. If it's so important to them, why don't they ban together and make Third-World-BASIC? We could do our part by donating _MAPTRIANGLE, so they could auto-cad their mud hut villages. Oh wait, did someone mention Italy in this thread? Yes! Well, that makes this a whole different story. The Development should jump on this immediatamente!
In all seriousness, I have been bitten in HTML coding by some of those Italian Unicode characters. I use QB64 to sort them out, when parsing those pages. So kidding aside, certainly it would be nice to be as universal as possible, but to what degree of effort? What about Mandarin characters or more diversely put CJK? Do we have that working yet in QB64?
Also, forgive my spoof on the "arrogance" issue. As a hobby language, the few people who contribute to the advancement of QB64 have to pick and choose the most beneficial additions to the platform. For instance, would it be better to make more programming features or try to make the language more universal? Certainly if we had developers from China, Japan, and other countries working on the project, things might be different. Certainly if we had millions of users world wide, the same would apply. Frankly it's amazing to me the project is as universal as it is, but it's like my mamma always used to say, "It's always something!"
Good night my little Roseanne Roseannadanna,
Pete
Hi Pete,
Thanks for your fun post.
I have always appreciated your humor and as a Frenchman, I do not feel at all insulted by your message which makes me laugh.
However, let me tell you that I fundamentally disagree with one important point:
If you are rightly saying that there are not enough developers contributing to the development of QB64, one of the main reasons is that even today, this surprising language is nothing but a hobbyist project.
Why ? Precisely because there are too many limitations in its code to make it evolve easily.
Now, if integrating vWATCH64 into the IDE seems like a very good idea to me, for QB64 to become a world-class tool for example to be accepted by the Raspberry foundation, I think the following steps must be taken:
1- separation of the IDE code from that of the compiler so that the latter can finally behave really like any other classic compiler (example gcc). This would allow, among other things, to see developers concentrate on the evolution of the language itself, and other to take care of the IDE. Some time ago, Fellippe told me that this should not pose a big problem. And that would also make it possible to interface with other IDEs easily.
2- extracting all the "messages" from the IDE code and setting up these messages in external files. This would make it very easy to create multiple translations in different languages. In addition, it is so easy to do and does not pose any technical problem. This also makes it possible to offer a dynamic change of language. Cf above for developpers wanting to contribute to the project when only translating the messages.
3- Unicode support and in any case at least no more default setting in code page 437. Indeed, as said above if the extended character table of IBM and Microsoft was "European biased", the reason and that this choice was not binding for English-speaking developers but simultaneously opened their tools to all European developers who alone represent a much larger market than that of the USA.
4- that vWATCH can work with programs placed in subdirectories and also with large programs (see my post: https://www.qb64.org/forum/index.php?topic=4123.msg134750#msg134750 )
There are surely other points to be addressed but these first 4 seem to me really essential for QB64 to acquire a real place on the worldwide market to gain millions of users (and developpers).
And adapting QB64, InForm, and vWATCH64 for use on Raspberry 4 seems like a great way to get there ... except to let Google and Microsoft take their place once again.
BTW, your telling about the number of contributors is the story of the snake that dies its tail.
Cheers.
Fifi
-
this surprising language is nothing but a hobbyist project
That's exactly what it is.
for QB64 to acquire a real place on the worldwide market to gain millions of users
Not in the plan.
We're going as we're having fun. I have a day job to bring bacon home. This is where I have fun.
Sorry to disappoint. We plan to keep having fun.
-
I personally don't mind. Windows dialog boxes write text correctly and legibly, even though the text in the IDE source code is unreadable. But there is a possibility to use fonts in the IDE. It's just text, it can't be used to translate disk paths (for example, you can't open files in diectories with unicode names) but it can be handled by direntry.h by StevemcNeill (and a big thank you for that). You can use _MAPUNICODE in your programs, so if you find out what code page your computer uses (the library I use for this is here: https://www.qb64.org/forum/index.php?topic=2014.msg112399#msg112399) then you can write in the program as you need. It will be ideal to use an external file written in an editor with supported accents for the texts in the program and then display it correctly thanks to _MAPUNICODE. I think that _MAPUNICODE clearly proves that the QB64 team thinks of people who do not use English but also other characters.
-
I’d also like to point out that one can also use QPrint with unicode, as well as my KeyHit library, which can be mapped to any keyboard configuration imaginable. It’s not like it’s impossible to use QB64 with any codepage/hardware out there — one just has to be willing to use the proper libraries to do so.
-
In all seriousness, I have been bitten in HTML coding by some of those Italian Unicode characters. I use QB64 to sort them out, when parsing those pages. So kidding aside, certainly it would be nice to be as universal as possible, but to what degree of effort? What about Mandarin characters or more diversely put CJK? Do we have that working yet in QB64?
Don't forget the Braille so we don't discriminate against the visually challenged.
-
I have actually been approached by a blind user recently who used qb64 but not the IDE, because our text mode is actually graphical and his screen reader couldn’t help with it.
-
Sorry to disappoint. We plan to keep having fun.
Sorry Fellippe but I do not see the connection between "having fun" and extending the use of QB64 to the greatest number and especially to the most disadvantaged children of all languages who are the privileged target of the Raspberry foundation.
So, is QB64 a private garden, kind of a closed club for adults only?
Honestly, I didn't see it that way.
I'm disappointed. It seriously lacks empathy.
-
"having fun"
That's our goal.
extending the use of QB64 to the greatest number and especially to the most disadvantaged children of all languages who are the privileged target of the Raspberry foundation
That's never been our goal.
-
That's our goal.
That's never been our goal.
It's a shame given the potential of this tool.
But I understand, maybe having more developers would make you lose your hand on the toy.
Too bad.
-
More developers are always welcome.
However, your belief we should act a different way - and especially the tone with which you bring it to the table - is what's annoying right now.
I appreciate your intentions, but right now you are not properly making us wanna collaborate with you.
-
I'm with Fellippe.
Your being rude.
If you want to develop a native language version of the IDE for your region then go ahead and branch the GITHUB.
We have no problems with people working on addons or additions for QB64. As long as it does not break things, or stray(too far) from qb64's original vision.
One example is the BIT routines; _SETBIT, _READBIT, _RESETBIT, and _TOGGLEBIT. QB64 did not come with these, and I needed them. So I put forth the effort and learned enough to create them. A very limited number of QB64 users use them so it wasn't a big enough reason for the others to put forth the effort themselves. And that is fine, I don't expect others too. Which Doesn't mean I don't ask(ARRAYs in UDTs please) but I don't put them down, or QB64, because they don't jump on it with disregard.
QB64 is a hobbyist project, always has been always will be. Nobody gets paid for the work they do on the code, any money from donations or sales of 'stuff'(which really doesn't amount to anything) goes into keeping this website up so it doesn't become another .NET and so we don't have to put up with seeing ADs every time we visit the forum, along with a few other upgrades for the site.
As a community, I believe anyway, we appreciate all our members. But its also a community, not a cult. So you don't have to stay.(Heck even Galleon left, and it was his project to begin with!!!) If your not happy you are free to go and find something that does make you happy. It remains your choice as to whether you go under good terms or not. And we have had both, unfortunately. I for one miss any of our users that depart, they all added something to the community. Even if it was just head shaking absurdity.
Okay, that is enough of that. Back to work.
Have a nice day.
-
Personally, I just don’t understand WHY you keep asking for folks to change QB64 so it’ll DO WHAT IT ALREADY DOES.
Case in point, you *ALWAYS* bring up, “If you separate the IDE from the compiler, like any other language….”
The issue is: IT IS! IT HAS BEEN! YOU CAN USE ONE, WITHOUT THE OTHER!! YOU’VE BEEN ABLE TO USE THEM INDEPENDENTLY FOR AGES!!!
If you just want the compiler, then code in whatever IDE you like — hell, Word, Open Office, Wordpad, and even Notepad works — and then just call QB64 from the command line and compile your text file. Rho even offers all the necessary tweaks to have syntax highlighting and such with Notepad++, if you like to use it as he does.
If you want to use the QB64 IDE as nothing more than a basic text editor, then simply check the option to “Disable syntax checking” and feel free to type your favorite recipe, novel, or stardate entry into it, if you want. When finished, save it as a text file, and that’s it.
You *CAN* use the IDE without the compiler. You *CAN* use the compiler without the IDE. How the hell can you get more separate than that?? Both *ARE* quite capable of being used without the other already!!
And yet, *EVERY* time you show up on the forums, you painstakingly explain how QB64 could be better if we’d just do things your way and separate the IDE and compiler….
Honestly, *I* couldn’t do your request, even if I wanted to. I can’t conceive, in my brain, any way to make the two anymore independent and exclusive than they already are.
-
@Fellippe, Cobalt, SMcNeill & others.
Hello all,
I am so sorry if I have hurt any of you because it was never my intention to be "rude" (and it is not in my upbringing).
For those who don't know me, I'm not really a "coder", never was, ever will.
My background of more than 40 years in the microcomputer industry is that of a software publisher and my job was to be the designer of the applications that the group that I had founded published (3 companies in the USA whose head office, 2 subsidiaries in France, 1 in England, 1 in Germany and more than 70 distributors in the world), products which were developed by my team of developers according to the specifications and the architects that I gave.
As an example, the last software I designed was the Remote Services Management suite for DOS, Windows and OS / 2 which has sold over 120 million copies worldwide.
Another example was Turbo Text Professional developed in Turbo Basic at Borland (Scotts Valley) with my late dear friend Bob Zale (sole developper of TB, then Power Basic) and my partner Medhi Ammaoui.
The other part of my job was also to enter into OEM agreements with large partners such as Compuware, IBM, or ICL and to negotiate licenses with large groups such as Amadeus, for example (80,000 copies alone).
It is therefore in view of the enormous potential that I see in QB64 that I have dared to make repeated proposals a few times.
I understood that the very few developers who continue to develop this superb tool are a small group of hobists and do not plan to embark on a larger adventure and I would therefore refrain in the future from any proposal that may offend you even if for me it makes good sense.
So, as for my involvement in your project with regard to my skills, my participation may be limited only to translation and localization, if one day that is technically possible.
I therefore offer you my sincere and most flattering apologies and the administrator of this site can close this thread.
Cordially.
Fifi
-
Hi guys and gals
fine to see all us sit at the table of discussion about QB64 and its future!
It is a powerful thing if it is able to take us here to discuss with energy for each own idea about its entity and evolution!
Seeing at the different points of view it seems to be at the centre of a crossroads, everyone comes from a country bringing with him/her own personal experience. Indeed this thread let me remember the phrase of Ghandi: "Anger is a gift" with this explanation: “La rabbia sta alle persone come la benzina alle automobili: è il carburante che ci fa muovere per raggiungere un posto migliore. Altrimenti ci mancherebbe la spinta necessaria ad affrontare una sfida. È l’energia che permette di reagire a un’ingiustizia.”
My bad translation (I'm learning English for a natural speaking)
Anger is to persons as gasoline is to cars: it is the oil that let us move to reach a better place. Without it we have no spin to face a challenge. It is the energy to re-act to an injustice.
Mr Google translate so: “Anger is to people like gasoline to cars: it is the fuel that moves us to reach a better place. Otherwise we would lack the drive to face a challenge. It is the energy that allows you to react to injustice. "
Well, it seems that discussion (or exchange of points of view) has arrived at these trues
1. QB64 community is not a place where child cry and mum and dad do everything to stop that crying, here requests are welcome, but no orders. In the measure that a question is very interesting and meet the qb64's original vision, it can be implemented by official developers. In the meanwhile a good coder can develop its own solution to a singular request of a member of QB64 community. This solution can be included into QB64 official after an evaluation of QB64 official developers.
2. new official developers are welcome. The enrollment is each Sunday , you can post your curriculum vitae at this email volunteers@qb64.org, please don't spam. If you have no response within 7 days you can claim the help of Pete with his guns or laser sabre so justice will win. For now roles aren't yet defined.
3. Marketing consulting are not requested but if they are made for free please post it as private messages here Future@QB64.org and not public discussion, moreover take as first point the needs of actual official developers.
----------------------------------------------------------------------------------------------------------------------------------------------------------
my customized answers
@Pete
Oh wait, did someone mention Italy in this thread? Yes! Well, that makes this a whole different story. The Development should jump on this immediatamente!
Hi Pete I remember you that in our USA, Mike Corleone has made a proposal that cannot be refused! Think at the horse.
So you mustn't do it immediatamente but only " 'esubbet pecchè mammà nun saddà dispiacè' "" And if you find this reason not enough I'll send you the Pope!
Apart all these jokes... Certainly if we had developers from China, Japan, and other countries working on the project, things might be different. Certainly if we had millions of users world wide, the same would apply.
I agree with these two points of view
1. if we have developers from.....so many countries working on the project....
IMHO there are so many clever coders into the community, (except me), and is it clear the path to be a good developer?
Is it a cooperative or cooptive role that of developer? Are there rules to cooperate without waste your time and time of
official developers? Must the candidate get the general consensus of official developers or must he only be cooperative?
These can be important answers to know.
2. if we ha millions of users world wide....
in that case the actual developers would be driving a millionary no profit society... I sometimes think to Ubuntu community or
to OpenOffice community just for example...or to Minecraft community before it was got by Microsoft
a QB64 visibility on Microsoft Store will condam you to the acquisition by Microsoft as soon as you got half million of followers
Thanks to let me talk with you.
@Petr & SmcNeill
I agree totally with you! There are now many ways to solve the issue. I have posted the links in my response to Bartok questions. Sorry Steve I have not linked your library because originally Bartok talked about QB64IDE and not only I/O of QB64.
@SMcNeill
dear Steve you're right and I agree totally with these sentences
You * CAN * use the IDE without the compiler. You * CAN * use the compiler without the IDE. How the hell can you get more separate than that ?? Both * ARE * quite capable of being used without the other already !!
simply check the option to "Disable syntax checking" and feel free to type your favorite recipe
So today if I use another text editor (say Notepad ++ or Dav IDE) I can compile my source code! But I cannot have syntax cheching, I cannot use _Option Explicit and _Option ExpliciArray. Moreover with the next version of QB64 I cannot use the Debug mode that is in refining state.
At the end something I loose using an external IDE.
Are these features, that today I loose using another IDE, in the compiler section or in the IDE section? Because if they are in the compiler section there is no issue because I can interact with the compiler to get syntax checking, _option checking, debug checking.
Thanks for let me talk about these topics with you
PS I find very interesting your I/O library and I have posted time ago the sub for European ASCII codemap, It works in my little attempt of code for my language but it seems cover Western Europe ASCII that can be tested.
@Fifi
QB64 arises in you strong passions! But passions are like a running horse, it must be under control.
I find very useful your tool for installing QB64, vWatch and Inform for Linux OSes.
PS
LOL It seems that I have found a bug in Html of post going over 6000 characters!
-
Thanks for reaction, @TempodiBasic,
I thought deeply about this problem. Since the IDE is based on US ASCII, implanting non-US characters would mean writing a special feature that would make the text composed of images, because the IDE must not be remapped to maintain its appearance.
Good. But then how the hell to read unicode characters from the keyboard? If save characters as images and compose text from them in the IDE ... that's a lot of work, but will I even be able to read unicode characters according to user settings without remapping the ASCII table?
I was just thinking. Let never occurs to anyone that I would like to try it.
-
Thanks for reaction, @TempodiBasic,
Good. But then how the hell to read unicode characters from the keyboard? If save characters as images and compose text from them in the IDE ... that's a lot of work, but will I even be able to read unicode characters according to user settings without remapping the ASCII table?
My KeyHit library can be configured to work with unicode input, but it requires a graphical screen to function properly with QPrint. The QB64 IDE is a text screen, so your idea of images won’t work.
As text, you’ll never have more than the 256 characters of an extended-ASCII set to display, meaning remapping would be essential to support a small subset of unicode characters — and I really don’t know of anyone who’d be willing to undertake such an extensive job to remap for every keyboard/language. It’s simply easier for folks to use a different IDE in those cases, than it is to try and rewrite the existing one we already have. Honestly, it’d be easier to build a new IDE from the ground up, than it would be to rewrite the existing one, in my opinion.
If the current ASCII code pages don’t fulfill one’s needs, then they’re honestly better off to find a different IDE to program in.
-
Thank you for clarifying the situation, @SMcNeill. As I wrote above. I am satisfied with the current IDE, I just thought about the technical feasibility of such an adjustment.