+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Chatting and Socializing (https://staging.qb64phoenix.com/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://staging.qb64phoenix.com/forumdisplay.php?fid=2)
+--- Thread: suggestions for future QB64 (/showthread.php?tid=24)
RE: suggestions for future QB64 - Pete - 04-29-2022
I saw everything except what you wrote to the right of.. acknowledge
Kidding aside, I've never seen that red-box alert for posts.
Pete
RE: suggestions for future QB64 - bplus - 04-29-2022
@Pete
Try loading up a post with pictures, maybe a certain corner store before the owner arrives?
Pizza and soda, coffee and donuts, an Open House atmosphere!
RE: suggestions for future QB64 - Pete - 04-29-2022
Oh I've seen warnings like size over-limit for uploading avatars. Sam refused to go on a diet, so I had to post him at The QJurassic Forum. I just haven't seen a post was made before mine alert yet, but I'm keeping an eye out.
Pete
RE: suggestions for future QB64 - bplus - 04-29-2022
Yeah avatar size does have same little read flash of a warning, top right corner just when you start to read message it's gone!
RE: suggestion for future QB64 - Fortran66 - 04-29-2022
(04-26-2022, 11:03 PM)Pete Wrote:(04-26-2022, 10:28 PM)justsomeguy Wrote: Forgive me, if this is presumptuous, but if it were me, this is more or less what I would do.What do you use QB64 for? Do you want to modernize it? Do you want it stay the same? Do you want it to include more platforms. What is one small feature or bug fix that you want the most? Perhaps take specific polls on what people are happy with, and what they are not happy with.
- Work out a roadmap of the future of what you guys want it to be, and what you guys want it to become.
As far as I know, we are almost all hobbyist and working for free, because we enjoy it. Whomever takes the reigns of developer, will need to balance this project and life.
- Work out who your core dev team is, and what their constraints are.
Not everyone is at the same skill level, and we don't all have the programming style. Outline some best practice's in the Wiki.
- Decide on a programming style.
This is a no brainer. The current code base is not very approachable, and can be difficult to track down bugs.
- Prioritize bug fixes and refactoring
This shows the community that you are active and as you get better with the code base, new features will be quicker to add.
- Trickle out small features somewhat regularly, and work on big features as time allows.
This is my 2 cents.
Your 2-cents is pretty much the way things have worked since 2007. The creator and first developer, Rob (Galleon) was a loan gun. He did an astonishing amount of coding on the project. For for whatever reason he was overly fond of using GOTO statements. That was a double edged sword. It helped him develop faster, because he had a good memory of the code, but after he left the project, well, I can imagine some of the shocked faces of folks who looked at the coding style. Luckily, Fell and luke jumped in, and handled it extremely well with the existing construct. That was probably around 2012 or 2013, I think. Anyway, Fell sure seemed to be tired of all the work involved, quit the project, is not coming back, and my guess is we will need to find someone like him if the project is to continue forward. As for fixing a few bug issues, that will probably get taken care of by those familiar with the project within this community. As for new platforms like mobile devices, I think that would require a re-write in JAVA. That's a tall task. Personally, I'd love to see a version of QB64 to write mobile apps.
Pete
Pete,
If Fillippe is permanently out of the QB64 project, then who will maintain the Inform RAD?
John
RE: suggestions for future QB64 - SMcNeill - 04-29-2022
Quote:Pete,
If Fillippe is permanently out of the QB64 project, then who will maintain the Inform RAD?
John
Currently, no one is.
RE: suggestions for future QB64 - madscijr - 05-05-2022
Some features I would find helpful for future QB64:
* Native dictionary (associative array) type. The basic of which can hold strings, but maybe make it like VBA's which can hold different types?
* Arrays inside of user defined types
* Commands to read multiple USB mice / keyboards as separate input devices (!)
* Sound commands like the Web Audio API, and/or basic sound commands to specify waveform / attack / decay / sustain / release / volume for up to 4 (or more?) independent channels, possibly control panning (left/right) or even fader (front/back) or 3D location (up/down) of each sound or stereo pair.
* Built in MIDI commands (input / output)
* Built-in / expanded support for hardware images. Built in hardware image commands for shapes (circle, square, line, etc.) and copy portion of hardware image. Maybe commands for tilesets? Or 3-D & isometric graphics? Whatever will make hw images and graphics easier to work with.
* Form/GUI editor and with events (just like VB6 & VBA) built right into the IDE.
* Optional "variant" type? (useful for operator overloading, would need an accompanying typename function)
* Operator overloading for routines?
If I think of any more I will let you know!
RE: suggestions for future QB64 - Pete - 05-05-2022
...And a partridge in a I.D.E.
RE: suggestions for future QB64 - Tim - 05-05-2022
(04-28-2022, 08:28 PM)aurel Wrote: hey Steve
I remeber your old SDL version you posted me long time
i think that one run faster than this GL version
do you still have it somewhere?
Also i think that
QB64 phoenix really deserve modern GUI code editor not just console looking blue thing?
what you think?
I like the console looking blue thing.
Although...I do modify some of the colors.
RE: suggestions for future QB64 - madscijr - 05-05-2022
(05-05-2022, 06:23 PM)Pete Wrote: ...And a partridge in a I.D.E.
Haha! Okay, maybe the wysiwyg GUI editor built into the IDE should be named "Partridge" then, ?