• Print

Author Topic: I've begun work on a new GUI for QB64 Code Editing  (Read 733 times)

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
I've begun work on a new GUI for QB64 Code Editing
« on: February 15, 2013, 05:26:26 AM »
This will be a full featured GUI which could be applied to any QB64 project with support for non-pixel based metrics and dynamically re-sizable indwelling (grid-dividable) containers. Imo, the true measure of a GUI is not how many controls it can display but how it resizes and readjusts itself in different situations, so a lot of planning has gone into this aspect. The "aha" moment for me was when I realized that only through the combining of optional pixel-based metrics and optional ratio-based metrics can a modern GUI be achieved. The other distinctive feature of my GUI will be that all containers will effectively be grids, and each individual grid row & column can have distinct restrictions/ideals applied to it.

I believe we do need a modern GUI system for QB64 and this change will springboard improvement within the IDE itself as well as providing a set of functions others can use to improve their programs. Expect to see some interactive examples soon (the current code just partitions grids and doesn't include user-friendly wrappers).
Something old... Something new... Something borrowed... Something blue...

Mrwhy

  • Hero Member
  • *****
  • Posts: 2890
  • My Dad called me Mr Why when I was 5.
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #1 on: February 15, 2013, 05:44:38 AM »
Yes, roll out the EXAMPLES - then even I will be able to understand what this does and SEE WHY I need to use it.
It sounds very premising, even exciting, to me!

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #2 on: February 15, 2013, 06:38:51 AM »
I've been working on a somewhat simplistic GUI for a while now. You can see it here, though I'm not sure how much of it applies to your system. I was going to set-up a parent-child set-up, so things such as color and location get inherited, but it's notably hard to do that without complicating the code a ton (And since I didn't have that in my original plans, nor needed it for the project I was working on, I skipped over it). Personally, I guess I'm just not planning for the future, but I did kinda feel that since we don't have any really good way to resize the text-based Windows anyway, simpler is better and defining the location for GUI elements makes it much easier for programmers, especially QB64 programmers who don't have any type of idea of a parent-child setup and how that works, etc.

And also, have you considered how you're going to theme it? The best GUI system would detect the system and then theme based on that (Or even better use that directly to draw the elements). You could have the .NET bindings (Whatever the Windows theming system is called...) and I may be able to write GTK bindings for Linux. I think that alone would be a huge leap in usability, since it would look native (And basically be native).

Any idea on how hard that would be to pull off? It would require adding something to QB64 to toggle code based on the system, like #ifdef for C, so you could have the Linux GUI code and the Windows GUI code and still have it compile. Besides that though, I think it would be doable.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #3 on: February 15, 2013, 07:29:21 AM »
Quote
And also, have you considered how you're going to theme it? The best GUI system would detect the system and then theme based on that (Or even better use that directly to draw the elements). You could have the .NET bindings (Whatever the Windows theming system is called...) and I may be able to write GTK bindings for Linux. I think that alone would be a huge leap in usability, since it would look native (And basically be native).
I'm going to be rolling my own. There are pros and cons of using native controls. As for the theme, I'm not that far into things yet to say except that it will be fully customizable.

Quote
Any idea on how hard that would be to pull off?
I'm sure it's possible.

Here's a screenshot of the screen grid partitioning doing its magic. Take note that I didn't tell it all of the metrics. I told it some ratios and some min/max restrictions for certain areas and it managed the rest.
Something old... Something new... Something borrowed... Something blue...

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #4 on: February 15, 2013, 07:49:16 AM »
Please don't use .Net.

The GUI in Windows is provided through GDI and User. The operating system handles the look and feel. I don't think that it should be the concern of the application.

Although I have no experience with either, wxWidgets seems preferable to GTK+:

http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits
Quote
Whenever possible, wxWidgets uses the native platform SDK and system provided widgets. This means that a program compiled on Windows will have the look and feel of a Windows program, and when compiled on a Linux machine, it will get the look and feel of a Linux program.

    A positive side effect is that wxWidgets is thus more likely to look, behave and feel native - sometimes including native features for free (e.g. possibility to have spellchecking built-in in all text areas on OS X).
    A negative side effect of this is that it is more likely that the behaviour is different between platforms; toolkits where widgets are lightweight lose some of the native aspect but also minimize platform-specific code (hence minimizing the risk of different behaviour from platform to platform and also minimizing the risk of platform-specific bugs). Concentrating on native looks also mean wx may not be best suited for applications that want a customized look instead of the system's theme.

If I understand correctly, wxWidgets tries to wrap around the Win32 GUI features, whereas something like GTK+ implements its own GUI, bypassing the higher level Win32 GUI features.

Regards,
Michael
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

fluffrabbit

  • Sr. Member
  • ****
  • Posts: 393
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #5 on: February 15, 2013, 07:57:41 AM »
It sounds like both DSMan and mcalkins want a native GUI. I would prefer a standard graphics-mode GUI. There is no need to get involved with operating system-specific code when making something as relatively trivial as an editor (or IDE if you prefer). The current editor works great and I would rather see Galleon work on fullscreen, sound, big fixes, and an Android port.

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #6 on: February 15, 2013, 08:09:37 AM »
Quote from: fluffrabbit on February 15, 2013, 07:57:41 AM
It sounds like both DSMan and mcalkins want a native GUI. I would prefer a standard graphics-mode GUI. There is no need to get involved with operating system-specific code when making something as relatively trivial as an editor (or IDE if you prefer). The current editor works great and I would rather see Galleon work on fullscreen, sound, big fixes, and an Android port.

The problem with a standard graphics-mode GUI is that it doesn't look good and can be confusing for users. It's always much better if the GUI looks similar to what users are already used to seeing, and that require using native drawing. It's not really *that* big of a deal, as really it's just a matter of wrapping the GUI drawing functions to use the systems native GUI and then going from there. The interface for the GUI system doesn't have to change, but setting it up the internal code so it will be easier in the future to add native drawing would be a good idea.

Steve:

WxWidgets isn't very active at the moment. WxWidgets also plugs right into GTK (There is a GTK binding library for WxWidgets). It's not a bad idea, but it's probably not best for the future. Using them directly shouldn't be to hard really, the tough part would be allowing the QB64 code to have both in and still compile.

The other option is Qt, which is completely cross platform (GTK has a Windows port as far as I know, but I don't think it uses Windows native drawing. Qt however does). Qt is very advanced and hard to use from what I've tried though, and I think that a QB64 wrapper for it would be a mess. Native Windows and GTK are probably the best bet.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

SMcNeill

  • Hero Member
  • *****
  • Posts: 2414
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #7 on: February 15, 2013, 08:26:18 AM »
Quote from: DSMan195276 on February 15, 2013, 08:09:37 AM
Steve:

???    Who?  What?  When?  Where?    I'm thinking you meant to respond to Michael, perhaps?   ;)

My opinion is simple on the matter:  I just hope the new GUI allows for better customization of colors, fonts, and such so that those that might be visually impared can create and use high-contrast color schemes with it.  What goes on under the hood wxwidget, spacely sprocket, or .net doesn't matter so much to me.   Just so long as the finished product is a little more customizable and user friendly.   ;)
http://bit.ly/TextImage -- Library of QB64 code to manipulate text and images, as a BM library.
http://bit.ly/Color32 -- A set of color CONST for use in 32 bit mode, as a BI library.

http://bit.ly/DataToDrive - A set of routines to quickly and easily get data to and from the disk.  BI and BM files

fatman2021

  • Hero Member
  • *****
  • Posts: 978
  • Lord Jesus Christ, Son of God, have mercy on us.
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #8 on: February 15, 2013, 09:02:18 AM »
Quote
And also, have you considered how you're going to theme it? The best GUI system would detect the system and then theme based on that (Or even better use that directly to draw the elements). You could have the .NET bindings (Whatever the Windows theming system is called...) and I may be able to write GTK bindings for Linux. I think that alone would be a huge leap in usability, since it would look native (And basically be native).

Personally, I think that the new IDE should use a custom theming engine. Something similar to what NeoPlanet or Classic Enlightenment used.   
Woe to those who call evil good, and good evil;
Who put darkness for light, and light for darkness;
Who put bitter for sweet, and sweet for bitter!

Isaiah 5:20

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #9 on: February 15, 2013, 09:22:38 AM »
Quote from: SMcNeill on February 15, 2013, 08:26:18 AM
???    Who?  What?  When?  Where?    I'm thinking you meant to respond to Michael, perhaps?   ;)

My opinion is simple on the matter:  I just hope the new GUI allows for better customization of colors, fonts, and such so that those that might be visually impared can create and use high-contrast color schemes with it.  What goes on under the hood wxwidget, spacely sprocket, or .net doesn't matter so much to me.   Just so long as the finished product is a little more customizable and user friendly.   ;)

Oops, sorry about that. 'Steve' and 'Michael' are just spelled so similar I think my finger just slipped ;)

I personally just feel that, as a default, the GUI system should try to use the native GUI drawing system. The reason being that this will look the most familiar to the user and less out of place. It'd doesn't really matter a ton how nice it looks, to a normal computer user hand-drawn GUI's just look odd because it's not what they're used to seeing. They also may have modified the default theme of the system, like Michael noted there are high contrast options on Windows, as well as Linux. When using the system, though, you really shouldn't have to worry about that, and if the default for the GUI system is to just use the default system theme then the users and programmers can both be happy.

Of course though, it should offer some ways of overriding this default and drawing/theming them yourself.  Being able to theme it yourself is a huge plus, just I think that using the native system theme by default will be a big help to programmers and users.

That's just my take on it though, I'm not 100% sure what Galleon has planned. None of this is set in stone though, GTK/Windows/Whatever-mac-uses bindings for the library could always be written later when people want to put the time in.

Galleon:

What are you plans for handling the actual elements? I'm curious what your intentions are. My system just has one type that holds all the info needed to draw everything. It's effective, it's not *that* memory efficient though (it's only like 200 bytes per element so it's not a huge deal either way). I was thinking of switching over to _MEM's completely for handling the elements, but I'm not really sure the added complexity of doing that is worth the memory gain to be honest. To be able to use a system like that requires SUB's and FUNCTION wrappers around the elements to be able to set or read any of the parts of the element.

And also, any idea if you'll implement function pointers to use with this system? That would obviously help out a GUI system a ton.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

fluffrabbit

  • Sr. Member
  • ****
  • Posts: 393
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #10 on: February 15, 2013, 01:22:39 PM »
Quote
The interface for the GUI system doesn't have to change, but setting it up the internal code so it will be easier in the future to add native drawing would be a good idea.
No, because that functionality would all have to be added to the QB64 standard library. Why bloat the framework or introduce new and unreliable features? We're so lucky to have executables under 1 MB now. No need to call specific Windows, Linux, and Mac libraries (or include wxwidgets [whatever]) and then you're stuck with it. I say it's a stupid waste of time. How the GUI controls are drawn doesn't matter, as long as the core functionality of QB64 works well. I mean, the QB64 editor is currently coded in QB64. Is that going to change or something? Because, when I make QB64 programs, I don't want any native GUI nonsense floating around.

codeguy

  • Hero Member
  • *****
  • Posts: 3552
  • what the h3ll did i name that code?
    • stuff at dkm
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #11 on: February 15, 2013, 01:26:03 PM »
native gui is fine, but for truly portable standardized code, it'd be nice to have it eventually coded in qb64, perhaps using RQBL or some such. we have even implemented listboxes using qb64. or perhaps a drop-down ribbon of commonly-used features of qb64 would be nice. but i agree people used to gui's of their native os would be happy with native gui.
http://denteddisk.forums-free.com/make-an-appointment-with-the-resident-code-guru-f34.html

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #12 on: February 15, 2013, 01:37:27 PM »
Fluffrabbit, it could all be done from DECLARE LIBRARY. Nothing would have to be added to the libqb. You're not understanding what I'm talking about. This GUI system is (presumably) not going to be built into QB64, it's going to be a separate library that you can use via '$include: or something similar. The Native GUI's can be used by this library to draw GUI parts IF desired. Very similar to how Qt is done, with Qt (A GUI library) all of the GUI parts are drawn by the systems native GUI (So that it will blend in with the system) by default. But, you can bypass this behaviour and use your own theme for all the elements if you want. It's all up to you. The option of using the native GUI to draw the elements should be there though, as it is an important feature.

But an important point, no matter how the GUI is being drawn it won't effect the GUI system's interface. It won't be like having direct access to the GUI system, it'll be more like a selectable option when using the library, this option doesn't effect how you could write the code and by just applying a theme you can change how it's being rendered. So, the code to use it looks the same but you have more flexibility in how it's being drawn.

But this is of course one of the less important points, the more important parts are how the library’s interface works.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

sjt1975

  • Newbie
  • *
  • Posts: 46
    • My Personal Web-Site
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #13 on: February 15, 2013, 01:49:41 PM »
One of the main features of QB64 for me, and the reason why I like it, is because the GUI looks like the old QB45 one (i.e. a nice plain text editor, like MS-DOS EDIT).  I realise that developing a new GUI is more exciting than, for example, adding/bug-fixing base functionality to/of the compiler (I don't know how much functionality the QB64-GL compiler is missing), but I hope that QB64 won't stray too far away from QB45.  Perhaps, we can have an option for which GUI we want to use, i.e. 'Classic QB GUI' (i.e. what we have now) and 'New QB64 GUI' (i.e. whatever funky GUI Galleon is developing) - maybe this might be too much code/work or cause problems in the source code.  It's just that, while I understand that developing a new GUI is more challenging/exciting from a Software Developer's point-of-view, I would have thought the making the compiler more complete/compatible with QB should be more important (to the QB64 project)?  Perhaps it's me being old-fashioned, but I kinda like the simplicity of the old QB45 GUI (especially after working with VB.NET for several years <<<scream>>>).  I'll probably get shot-down for saying this, but it is my mere opinion only...

Kind regards,

Stuart.

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: I've begun work on a new GUI for QB64 Code Editing
« Reply #14 on: February 15, 2013, 02:02:33 PM »
I agree Stuart, I to like the design. I kinda get the feeling that it's unlikely this GUI system will be ready to replace the one in QB64 very soon, so it's not an immediate concern.

Personally, I would really push to have the QB64 compiler separated from the GUI. If that was done, then you could just have multiple GUI programs that all use the QB64 compiler (And thus one could look like QB45 and one could look more 'modern'). Having the compiler separate would also help the coding effort in the long run and allow for the actual compiler to note require very many files to run (And overall be improved). It would mean that the QB64 IDE couldn't compile things without first saving them to a file, but I consider that a minor draw back (And, if someone gets an interpreter going, then that won't be an issue anyway). These are all things to probably be discussed after QB64-GL is going and working though.

Matt
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

  • Print