suggestions for future QB64

[Pete]

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

[bplus]

@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!

[Pete]

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

[bplus]

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!

[Fortran66]

Forgive me, if this is presumptuous, but if it were me, this is more or less what I would do.

• Work out a roadmap of the future of what you guys want it to be, and what you guys want it to become.
  

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 who your core dev team is, and what their constraints are.
  

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.

• Decide on a programming style.
  

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. 

• Prioritize bug fixes and refactoring
  

This is a no brainer. The current code base is not very approachable, and can be difficult to track down bugs.

• Trickle out small features somewhat regularly, and work on big features as time allows.
  

This shows the community that you are active and as you get better with the code base, new features will be quicker to add.
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

[SMcNeill]

Pete,

If Fillippe is permanently out of the QB64 project, then who will maintain the Inform RAD?

John

Currently, no one is.

[madscijr]

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!

[Pete]

...And a partridge in a I.D.E.

[Tim]

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.

[madscijr]

...And a partridge in a I.D.E.

Haha! Okay, maybe the wysiwyg GUI editor built into the IDE should be named "Partridge" then, ?