Results 1 to 14 of 14

Thread: [RESOLVED] What is the future of VB.Next's UI?

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Resolved [RESOLVED] What is the future of VB.Next's UI?

    I remember some people said that Web-based UI is the future of UI. So what is the role and significance of pixel-based UI libs (such as RC6Widgets)? In other words, will the life cycle of pixel-based UI libs be greatly shortened? Should TwinBasic or RadBasic provide a Web-based UI framework?

  2. #2
    Lively Member
    Join Date
    Sep 2016
    Location
    Germany, Bavaria
    Posts
    75

    Re: What is the future of VB.Next's UI?

    Hi,

    RC6 got a connection to the WebView2 runtime some time ago. With this, HTML based GUI are already possible today.

    http://www.ww-a.de/download/Urlaubsplaner.zip

    I will soon publish the source code for this application.

    Screenshot:
    Attachment 181624

    W. Wolf

  3. #3

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by wwolf View Post
    Hi,

    RC6 got a connection to the WebView2 runtime some time ago. With this, HTML based GUI are already possible today.

    http://www.ww-a.de/download/Urlaubsplaner.zip

    I will soon publish the source code for this application.

    Screenshot:
    Attachment 181624

    W. Wolf
    Your app is great, thank you very much, wwolf.

  4. #4
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by SearchingDataOnly View Post
    I remember some people said that Web-based UI is the future of UI.
    The current trends point in this direction, yes...

    Quote Originally Posted by SearchingDataOnly View Post
    So what is the role and significance of pixel-based UI libs (such as RC6Widgets)?
    In other words, will the life cycle of pixel-based UI libs be greatly shortened?
    I assume, with "pixel-based" you mean "classic, pixelbased positioning" of Widgets or Controls
    (on a classic, system-provided "Form- or Window-Rectangle").

    Well, I guess, the advantages are, that "classic" GUI-Frameworks (like GTK+, QT or the RC):
    - are well-understood and well-tested (with years of "hardening" under their belt)
    - are zip-deployment-wise smaller than a BrowserEngine (90MB Chromium vs. about 18MB for GTK or QT, or 3MB RC)
    - are better integratable into "classic Desktop-IDEs" (FormDesigners + Event-Interaction)
    - consume less memory
    - generally perform better (filling of large Grids ... etc.)

    I think, we will see a better picture (a better "trend"), when "true Desktop-support" (similar to Samsungs DeX),
    will be more common also on the cheap(er) Android-Devices (within the next 2-4 years).

    Quote Originally Posted by SearchingDataOnly View Post
    Should TwinBasic or RadBasic provide a Web-based UI framework?
    Modern js-based Web-Frameworks are based on "Widgets in Host-Containers, which support progressive Layouting"
    (a different paradigm, that's quite "alien" in classic FormDesigners as we know them for the Desktop).

    Meaning, once Layout-based js- or typescript-classes come into play -
    you don't really need any "mouse-dragged positioning" anymore.

    You basically just add "a bunch of Widgets" into such a Layout-Container (together with a few Layout- and DataBinding-hints),
    and the Layouter will then reposition (or stretch) these Widgets nicely, no matter on what Device you run this thing
    (nor does it matter, whether you are in "Landscape- or Portrait-mode").

    So, a "graphical Form-designer" is not really needed (just the "addWidget-lines" are sufficient).

    Olaf

  5. #5

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by Schmidt View Post
    I assume, with "pixel-based" you mean "classic, pixelbased positioning" of Widgets or Controls
    (on a classic, system-provided "Form- or Window-Rectangle").

    Well, I guess, the advantages are, that "classic" GUI-Frameworks (like GTK+, QT or the RC):
    - are well-understood and well-tested (with years of "hardening" under their belt)
    - are zip-deployment-wise smaller than a BrowserEngine (90MB Chromium vs. about 18MB for GTK or QT, or 3MB RC)
    - are better integratable into "classic Desktop-IDEs" (FormDesigners + Event-Interaction)
    - consume less memory
    - generally perform better (filling of large Grids ... etc.)
    Can it be said that the classic GUI frameworks still have great advantages in the "classic desktop-IDEs", "scientific research field", and "education field"? In other words, the classic GUI frameworks have at least a 10-year life cycle, right?

    Quote Originally Posted by Schmidt View Post
    I think, we will see a better picture (a better "trend"), when "true Desktop-support" (similar to Samsungs DeX),
    will be more common also on the cheap(er) Android-Devices (within the next 2-4 years).
    I haven't fully understood this sentence. Is it possible to think that the classic GUI frameworks may flourish again in the future, even surpassing Web-UI frameworks?

    Quote Originally Posted by Schmidt View Post
    Modern js-based Web-Frameworks are based on "Widgets in Host-Containers, which support progressive Layouting"
    (a different paradigm, that's quite "alien" in classic FormDesigners as we know them for the Desktop).

    Meaning, once Layout-based js- or typescript-classes come into play -
    you don't really need any "mouse-dragged positioning" anymore.

    You basically just add "a bunch of Widgets" into such a Layout-Container (together with a few Layout- and DataBinding-hints),
    and the Layouter will then reposition (or stretch) these Widgets nicely, no matter on what Device you run this thing
    (nor does it matter, whether you are in "Landscape- or Portrait-mode").

    So, a "graphical Form-designer" is not really needed (just the "addWidget-lines" are sufficient).
    Modern js-based web frameworks do show great advantages. Does it mean that they will speed up the elimination of classic GUI frameworks?

    In addition, I'd like to know, if CodeEditor is developed with a classic GUI framework, will it be more advantageous than VSCode based on Web-UI? (Or at least in certain aspects will be more advantageous?) Thanks.
    Last edited by SearchingDataOnly; Jun 9th, 2021 at 10:49 AM.

  6. #6
    PowerPoster
    Join Date
    Nov 2017
    Posts
    3,116

    Re: What is the future of VB.Next's UI?

    What is CodeEditor?

  7. #7

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by OptionBase1 View Post
    What is CodeEditor?
    A new code editor dedicated to VB6. Of course, it's still being conceived (in a dream).

  8. #8
    PowerPoster
    Join Date
    Nov 2017
    Posts
    3,116

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by SearchingDataOnly View Post
    A new code editor dedicated to VB6. Of course, it's still being conceived (in a dream).
    No one here is ever pressuring you to create anything. You seem to always have these grandiose projects that you promise will be forthcoming and then never materialize. I just don't get it. Are you just looking for admiration for the brief moment in time that people believe your next thing might actually be delivered? You seem to be consistently asking Schmidt lots of questions that make it at least appear that you are working on something. If all you are doing is wasting his time then you are doing the entire community a disservice.

  9. #9

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by OptionBase1 View Post
    No one here is ever pressuring you to create anything. You seem to always have these grandiose projects that you promise will be forthcoming and then never materialize. I just don't get it. Are you just looking for admiration for the brief moment in time that people believe your next thing might actually be delivered? You seem to be consistently asking Schmidt lots of questions that make it at least appear that you are working on something. If all you are doing is wasting his time then you are doing the entire community a disservice.
    In my opinion, you have been hurting the entire community. Not only do you have no contribution to VB.Next, you are also hindering the progress of VB.Next. Now you are starting to quarrel again. Please leave from my thread or you will be the second person on my ignore list.
    Last edited by SearchingDataOnly; Jun 9th, 2021 at 11:14 AM.

  10. #10
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by SearchingDataOnly View Post
    Can it be said that the classic GUI frameworks still have great advantages in the "classic desktop-IDEs", "scientific research field", and "education field"? In other words, the classic GUI frameworks have at least a 10-year life cycle, right?
    I'd make this at least 20 years or more...

    There's a whole lot of professions/branches, where you *need* to use a large Screen
    (many workplaces with even dual-screen-setups)...

    So the "market" for such classically written Apps (which feed these large "landscape-screens" with "a lot of dense information")
    will always be there... I think it will level down to a certain percentage, but demand will always be there...

    Quote Originally Posted by SearchingDataOnly View Post
    I haven't fully understood this sentence. Is it possible to think that the classic GUI frameworks may flourish again in the future, even surpassing Web-UI frameworks?
    I'd think we might see a kind of "second wind for classically written Apps",
    as soon as such "PowerPhones with built-in Desktop-Screen-support" become more common-place in modern Offices
    (replacing the classic-DesktopPC-boxes, which these days often come already in a "mini-PC-format").

    Android had "official Desktop-support" already included in Android10- and 11 BetaVersions -
    but then Google removed it again (and I think it's still not officially there even in the upcoming Android12).

    I think Google made that decision, to not cut into their own ChromeOS-sales...
    There's a lot of ChromeBox-Devices out there currently from a lot of vendors: https://en.wikipedia.org/wiki/Chromebox
    I think it's quite clear, that such new, upcoming "PowerPhones with DeskMode" would destroy the ChromeBox-market immediately.

    So, currently they place the burden on the device-vendors, to come up with their own Desktop-Mode for their new Phones.

    I think a medium-level Phone (in about 3 years), will come with:
    - a CPU-Power, comparable to Apples current M1-chip (currently built into their new MacBooks)
    - 8GB Ram (comparable to, what most Office-PCs currently have)
    - 256-512GB SSD-storage (comparable to most current Office-PCs as well)
    Now, add Desktop-Mode and nice "Wireless docking" (to large-screen and Keyboard/Mouse) -
    and you have a device which can act as a full replacement for all the Mini-PCs which are currently used in most offices.

    Working from home (due to whatever reason)?
    No problem, just take your phone with you...

    Quote Originally Posted by SearchingDataOnly View Post
    Modern js-based web frameworks do show great advantages. Does it mean that they will speed up the elimination of classic GUI frameworks?
    Not really - there's always certain parts (when you develop for "big screens"), where classically placed Elements (via FormDesigner) will make sense and save a bit of time.

    In addition, you can of course use "Layouter-Classes" also in conjunction with "classic Widgets" -
    (e.g. the little GUI-Demo I wrote for twinBasic makes use of such a Layouter-Class, to avoid Pixel-Coords when adding Controls/Widgets).

    Quote Originally Posted by SearchingDataOnly View Post
    In addition, I'd like to know, if CodeEditor is developed with a classic GUI framework, will it be more advantageous than VSCode based on Web-UI? (Or at least in certain aspects will be more advantageous?)
    FWIW, (in case you mean the cwVList derived cwEditor-Widget I'm currently working on)...
    I will upload it into the CodeBank in the next weeks (had a lot of other stuff to deal with recently).

    Olaf

  11. #11
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: What is the future of VB.Next's UI?

    Android desktops really were "a thing" for a brief point in time. That lasted under a year though.
    Google moved Android support to the Chrome team about the same time they began to cripple desktop use of Android in newer versions.

    Oddly, the only one left trying to do this is Microsoft with their massively unsuccessful Metro (a.k.a. UWP) experiment that is still limping along today. I suspect that only lives on because (1) it will take time and effort to refactor all of the UWP settings applets back to normal Control Panel code again, and (2) the Azure faction still imagines a time when desktops are all demoted to terminals running Windows 10X on ARM hardware.

  12. #12
    Hyperactive Member
    Join Date
    Mar 2018
    Posts
    460

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by dilettante View Post
    Android desktops really were "a thing" for a brief point in time. That lasted under a year though.
    Google moved Android support to the Chrome team about the same time they began to cripple desktop use of Android in newer versions.

    Oddly, the only one left trying to do this is Microsoft with their massively unsuccessful Metro (a.k.a. UWP) experiment that is still limping along today. I suspect that only lives on because (1) it will take time and effort to refactor all of the UWP settings applets back to normal Control Panel code again, and (2) the Azure faction still imagines a time when desktops are all demoted to terminals running Windows 10X on ARM hardware.
    have you tried chomeos with android apps or any android device with desktop mode (eg samsung DeX)?

  13. #13

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by dilettante View Post
    Android desktops really were "a thing" for a brief point in time. That lasted under a year though.
    Google moved Android support to the Chrome team about the same time they began to cripple desktop use of Android in newer versions.

    Oddly, the only one left trying to do this is Microsoft with their massively unsuccessful Metro (a.k.a. UWP) experiment that is still limping along today. I suspect that only lives on because (1) it will take time and effort to refactor all of the UWP settings applets back to normal Control Panel code again, and (2) the Azure faction still imagines a time when desktops are all demoted to terminals running Windows 10X on ARM hardware.
    Maybe one day everything will change. When the seed is buried, there is hope to see it germinate and grow into a big tree.

  14. #14

    Thread Starter
    Frenzied Member
    Join Date
    Aug 2020
    Posts
    1,421

    Re: What is the future of VB.Next's UI?

    Quote Originally Posted by Schmidt View Post
    I'd make this at least 20 years or more...

    There's a whole lot of professions/branches, where you *need* to use a large Screen
    (many workplaces with even dual-screen-setups)...

    So the "market" for such classically written Apps (which feed these large "landscape-screens" with "a lot of dense information")
    will always be there... I think it will level down to a certain percentage, but demand will always be there...
    Well. I'll continue to use the classic GUI frameworks for at least 20 years.

    Quote Originally Posted by Schmidt View Post
    I'd think we might see a kind of "second wind for classically written Apps",
    as soon as such "PowerPhones with built-in Desktop-Screen-support" become more common-place in modern Offices
    (replacing the classic-DesktopPC-boxes, which these days often come already in a "mini-PC-format").

    Android had "official Desktop-support" already included in Android10- and 11 BetaVersions -
    but then Google removed it again (and I think it's still not officially there even in the upcoming Android12).

    I think Google made that decision, to not cut into their own ChromeOS-sales...
    There's a lot of ChromeBox-Devices out there currently from a lot of vendors: https://en.wikipedia.org/wiki/Chromebox
    I think it's quite clear, that such new, upcoming "PowerPhones with DeskMode" would destroy the ChromeBox-market immediately.

    So, currently they place the burden on the device-vendors, to come up with their own Desktop-Mode for their new Phones.

    I think a medium-level Phone (in about 3 years), will come with:
    - a CPU-Power, comparable to Apples current M1-chip (currently built into their new MacBooks)
    - 8GB Ram (comparable to, what most Office-PCs currently have)
    - 256-512GB SSD-storage (comparable to most current Office-PCs as well)
    Now, add Desktop-Mode and nice "Wireless docking" (to large-screen and Keyboard/Mouse) -
    and you have a device which can act as a full replacement for all the Mini-PCs which are currently used in most offices.

    Working from home (due to whatever reason)?
    No problem, just take your phone with you...
    Hope to see "second wind for classically written Apps" again.

    Quote Originally Posted by Schmidt View Post
    Not really - there's always certain parts (when you develop for "big screens"), where classically placed Elements (via FormDesigner) will make sense and save a bit of time.

    In addition, you can of course use "Layouter-Classes" also in conjunction with "classic Widgets" -
    (e.g. the little GUI-Demo I wrote for twinBasic makes use of such a Layouter-Class, to avoid Pixel-Coords when adding Controls/Widgets).
    It's an excellent solution to combine the classic GUI frameworks and Web-UI frameworks (js-based Web frameworks).

    Quote Originally Posted by Schmidt View Post
    FWIW, (in case you mean the cwVList derived cwEditor-Widget I'm currently working on)...
    I will upload it into the CodeBank in the next weeks (had a lot of other stuff to deal with recently).
    Looking forward to cwEditor-Widget, I'll study, test and use it in depth.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width