Need help about future decision of my PB apps

[Kukulkan]

I want to ask the community to maybe get better inputs. As mentioned in my thread here, I have to offer modern and DPI aware user interfaces (GUI). Please also consider that these apps are currently running for many thousands of users all over the world (German, English, French and Chinese). They have to support Windows, Linux and Mac.

The decision is also having a huge impact on future development and also affecting budgets, employees, strategy and even support effort.

During the last Months, I found several options and now have to decide the way to go next year. Sadly, every option is having it's pros and cons.

Stay with PB and use the XML Dialog (like today)

• Pro
  • No changes
  • Full control over all aspects
  • Very small footprint of setup (~2MB)
• Con
  • Users complain boring user interface
  • Restrictions (like no header clicks in ListIconGadgets etc)
  • Optical issues (DPI awareness is incomplete, layout engine is bad etc)
  • A lot of platform dependent hacks (API calls) are needed

Stay with PB and use WegGadget() with HTML/JS to do the GUI

• Pro
  • Many code can stay as it is
  • Small footprint of setup (~3MB)
  • Full control over all aspects
• Con
  • PB WebGadget is not fully featured on all OS. Many API hacks are needed.
  • Unsure about OS support. Some Linux Distros may lack the WebKit libs. No idea what Apple is doing.
  • There might be future PB changes that stop this kind of usage.

Use Sciter for the GUI

• Pro
  • Modern and DPI aware GUI and skins
  • Created with GUI in mind, supporting extra GUI related stuff
• Con
  • Medium footprint of setup (~8MB)
  • No JavaScript support, TIScript is limited and not wide used
  • Can not re-use many existing GUI libraries (JS)
  • Needs a C++ wrapper to work with PB
  • Sciter may be a target for attacks with no real control about

Use Electron or nw.js for the GUI

• Pro
  • Full control over mostly all aspects
  • Modern GUI with DPI awareness and full JavaScript support
  • Huge function library (node.js) and big community
  • Seems proven for serious development (Skype, Atom, Visual Studio Code and many others)
• Con
  • Existing PB code only usable as DLL/SO/DYLIB which makes it hard to debug and develop in two worlds
  • Huge footprint of Setup (~45MB)
  • Electron and node.js may be a target for attacks with no real control about

Redo all in another Language/Toolkit/Framework like Go or RUST and QT or wxWidgets etc

• Pro
  • New code always may fix all failures and bad design decisions from the past
  • We can choose any other language (like GO, Rust, Python etc) with many Frameworks (Sciter, QT, GTK, wxWidgets etc)
• Con
  • No re-using of existing PB code
  • Need to learn a new language and get comfortable with it
  • Will need a lot of time to re-create all products

There is also some factor that is out of the above list: I personally like PB very much. But I'm also really sad that PB lost track over the last years regarding user interfaces and modern UI concepts, DPI awareness and portability. Some of my issues are lined out in the first post of the above linked forum discussion about "Users complain boring user interface of my apps".

So, do you have any additional input that might affect my decision?

[diskay]

https://github.com/mestnyi33/Widget

[Kukulkan]

Hi, maybe I forgot to mention that our tools have to be cross-platform (Windows, Mac and Linux). GUI libraries like CodeJock or BCTools are Windows only. Also, using such with PureBasic are not DPI aware and not compatible with the XML Dialog layout (which is mandatory for modern software I believe).

The owner drawn GUI controls of "Widget" (thanks diskay) are suffering from the same. They are not DPI aware and not compatible with the XML Dialog layout.

Basically I do not look for more alternatives. I look for more Pros and Cons regarding the existing options I lined out in the first thread.

[mestnyi]

https://github.com/mestnyi33/Widget

You have already found my creation !!!
I had a ready-made solution, but my ssd stopped working, so I lost everything. Now I am trying to recover the memory, but this requires a lot of work.
If anyone has the desire and opportunity, you can join

They are not DPI aware and not compatible with the XML Dialog layout.

Now for this, I think it's not a problem.

[Shield]

From a business perspective, I'd recommend to move on to another language that enjoys a wider community and more support. While PB has it's advantages (hence I still frequently use it for prototyping), it's a niche language with little support and a very small ecosystem (comparatively).

However, if PB floats your boat, as it seems, you might as well go all in given that you have already written your application in PB. I'm not sure what your exact requirements are, but what you could do is use PureBasic as the backend of your application and run a simple HTTP server locally. You could create the front-end with SpiderBasic, which allows you to reuse your code and stay within the PB realm while also taking advantage of modern browser/JS frameworks. Everybody has a browser that's reasonably modern these days.

[chi]

I'd recommend Qt + Visual Studio Community. It takes a while to get used to both, but it's definitely worth it.

[mk-soft]

A Purebasic program looks like a Windows program under Windows. Under Linux it looks like a Linux program and under OSX it looks like a mac program.

What more could you want?

You don't have to install a GUI framework for the program.
Furthermore, you can create your own controls with the CanvasGadget without big problems, which also run all OS.

[Kukulkan]

Hi mk-soft,

I think you read neither my first post nor the linked post

A Purebasic program looks like a Windows program under Windows. Under Linux it looks like a Linux program and under OSX it looks like a mac program.

Sadly not. It looks outdated and even Windows own dialogues looking very(!) different. You cant create dialogues like for Windows settings or MS office using PureBasic.

What more could you want?

DPI awareness, more flexibility regarding gadgets etc. See here.

Furthermore, you can create your own controls with the CanvasGadget without big problems, which also run all OS.

No, they will not fit into the XML Dialog functions (can not integrate and recalculate). Also, it is really hard to make this DPI aware. At least, if you mix owner drawn with generic ones. Also, I really do not want to re-invent many Gadgets by myself just for today standard functionality. And I'm really sick of using different API calls on all three OS just to make things looking or behaving the same.

And trust me, I know what I'm writing about. I did my own button Gadget, my own ListView/TreeView and some others (just search the forum for my name and posts). But that is not really a good solution to me. I would have to rewrite nearly all standard Gadgets. Also, because the XML Dialog layout engine does not work with such, I would have to rewrite the layout engine, too. Trust me, I tried. But then it becomes to slow because I need to draw all Gadgets first to get all the sizes (becoming very slow). This is not acceptable. I really like PB and the syntax and even Fred and team. But I turns out to fall out of time since a few years and it does not follow the evolution. At least for user interfaces.

So, maybe you can help me with some Pros and Cons about my first post here?

[skywalk]

Yes, many choices to achieve nirvana, if even possible?
I am more concerned with function and speed than frilly gui's.
But, you infer lost customers without the latter.
If no care to bloat, consider Qt, (C++, ~25-50MB support dll's based on some app's I use).
Or go client(JS/SpiderBasic/browser overhead/delay)/server(PB) approach.
You already tried native canvas gadget gui and it fails dpi?
I have not been disappointed with the canvas performance so far?

[Little John]

Hi,

you wrote a lot of valid points. It's not easy to add something to the list.

Use Sciter for the GUI

• Con
  • ...
  • Needs a C++ wrapper to work with PB

Maybe you can pay someone who does that for you.
When it's finished, you could even sell it to PureBasic users.
Personally, I probably would buy it at a reasonable price.

[mk-soft]

Thats right... I'm not reading alls.

I think the QT 5.5 is a good alternate for all OS and like it as subsystem for Purebasic (Linux)

[Kukulkan]

Hi mohsen,

did you ever try to use your own gadgets in bigger layouts using XML Dialog library? I've had a lot of trouble using my owner drawn Gadgets with this library. Also with ImageGadgets. The missing vertical alignment for XML layouts caused a lot of my layouts looking very bad. All workarounds finally failed in DPI awareness (eg adding extra pixels here and there). And I really do not want to re-invent all sorts of Gadgets

I also found it annoying that the canvas gadget is not able to be transparent. If your gadget is not fully rectangular, you have a lot of code to make the background perfect if your windows do not use the same or default color. For example, I wanted to have a slight gradient in the back. I was able to do so, but all overlaying gadgets failed (standard and canvas based). The same for my owner drawn. I finally had to stop the gradient. Finally, after years of struggling with this, I find the GUI in PB all so limited and restricted...

Little John

Selling some libs to others is not my business and I do not have time to support others with such lib. I'm willing to pay something for such wrapper, but the other Cons still remain. To be honest, the possibilities of Electron impressed me. How easy things would be if you can do CSS and use all these node.js libraries and existing JS/CSS gadgets. But it is soooo big and using PB code as DLL/SO/DYLIB in the backend does not make any fun...

[mestnyi]

And why are you using xml? what exactly do you like in xml auto stretching gadgets?
Can you draw me which user interface would you like to make?

[idle]

logic would suggest a full gui framework like QT or use an embedded application server
with a js gui framework, EasyUI perhaps, which can be used in an embedded browser or the clients web browser.
https://www.jeasyui.com/demo/main/index.php

I don't think electron and node.js are good options yet.

Scitter, yes it's a ok possibility

I really think the path forward is with application servers, I don't like the idea that much but
it offers the flexibility to run locally or remotely in a window or clients browser and is at least
future proof and means your applications can be used from any device.

As for PB canvas it's just the draw to the screen that needs fixing and it'd be pretty trivial to add a CSS and html5 parsing
lib that would calculate the layout and use callbacks for rendering, obviously this would require 20-30k lines of code to
get a basic set of widgets but it'd easily become a community effort.

[Kukulkan]

Hi idle,

thank you very much for your opinions.

I don't think electron and node.js are good options yet.

Maybe you can give me some more information about why? I found no real drawbacks yet (except the huge size). Do you think there is something I should have an eye on?