PureBasic Forums - English

@Kukulkan
Your statement was a great reading!
Thanks a lot for this!!!

At the end, it sounds for me that there are some minor disadvantages in small team projects but the errors are fixed very quickly and overall development of sciter and PureBasic is very dynamic.
You said, You needed much help from the forum; but as with the PureBasic forum, that help is given at the end!

Seems for me like a win win situation if PureBasic and Sciter would work together.

The risk remains due to the small team of both products.


Thanks again for the great reporting!

@Kukulkan?
Did you consider creating your own gui elements with the canvasgadget?
Would that have taken more or less time in the end?
Would the end result be so bad?

@Kukulkan, thanks for the detailed report. I'm considering trying Thorsten1867's modules. Initial trials with some of these modules looks good but I'll be checking how easy it is to integrate these into my existing app.

@HanPBF
We also considered waiting for PB to integrate Sciter. But it is like for libcurl. We use our own libcurl using OpenLibrary(). For example, we struggled with some buggy behavior of libcurl while sending smtp email. So we simply compiled a newer version and the issue was gone. At this time, PureBasic was still with some very old version. So we missed flexibility and the same will be for Sciter. If PB integrates Sciter, you are limited to the version included by Fred. What we've learned is that there are many bugs in Sciter and they are fixed fast. Using PB built-in implementation would not allow us to update the library if needed. So we decided to not wait for PB. And the next thing was using Sciter from PB. It seems very hard and the existing golang language binding came very handy. And so far, golang is really cool and powerful. I like it very much. I miss the easy maps and arrays from PureBasic, but after you found the golang way, it is also very usable and also productive.

@skywalk
> Did you consider creating your own gui elements with the canvasgadget?
I did my own Listview/Treeview, Buttons and others in the past:
viewtopic.php?f=12&t=62368
viewtopic.php?f=12&t=65572
viewtopic.php?f=12&t=49192
But I do not like to spend my time any longer on such. HTML+CSS are so handy for this.

@ozzie
Yes, they are great. But just imagine you want to change the colors for all the elements (eg some dark theme). I simply have to change some color variables in my Sciter CSS (if I used them wisely). How would you do with some gadgets from Thorsten1867? Yes, it is possible but you may even have to dig into someone else code to change what you want.

Yes, they are great. But just imagine you want to change the colors for all the elements (eg some dark theme). I simply have to change some color variables in my Sciter CSS (if I used them wisely). How would you do with some gadgets from Thorsten1867? Yes, it is possible but you may even have to dig into someone else code to change what you want.

You can change a global theme in de ModuleEx. It is an XML you can load and save. And there is a simple structure for doing it.

https://github.com/Hoeppner1867/PureBas ... duleEx.pbi

You can change a global theme in de ModuleEx. It is an XML you can load and save. And there is a simple structure for doing it.

Great, I was not aware of this. Anyway, I think HTML+CSS was the better choice for us. In the long run we will substitute PB code with golang and C. And Sciter will probably be the main GUI component (not yet decided). I really like PureBasic syntax and features, but the very limited GUI (remember, I initiated this thread), missing ARM support and the current development direction does not match what we need. Life is moving on and so must we. I still will be in this group and use PB for other products and tools. But not for the major company products.

Kukulkan wrote:If PB integrates Sciter, you are limited to the version included by Fred. What we've learned is that there are many bugs in Sciter and they are fixed fast. Using PB built-in implementation would not allow us to update the library if needed.

Some time ago I suggested the idea of an official repository of user contributed include files that can be accessed from the IDE.

Kukulkan wrote:I really like PureBasic syntax and features, but the very limited GUI (remember, I initiated this thread), missing ARM support and the current development direction does not match what we need.

I have also suggested in the past (which was met with derision by some ) that perhaps PureBasic should target the JVM.

Why target JVM, when LLVM opens up all available uprocessors to native code?

skywalk wrote:Why target JVM, when LLVM opens up all available uprocessors to native code?

Jvm would likely be significantly easier, merely swapping one ASM for "another". (Yes, technically not asm, but from a compiler perspective, it is.)

Llvm, on the other hand, has little in common with low level ASM. However, it would be a much better target... With so many targets that llvm hits. I think their spider basic forey have them the experience to output human readable higher (or mid) level code.

Hey guys, are you still on topic? It is about boring user interface and possible solutions, not possible future PB compilers

Kukulkan wrote:Hey guys, are you still on topic? It is about boring user interface and possible solutions, not possible future PB compilers

Hey, you gave lack of support for ARM as one of the reasons for moving on from PB

skywalk wrote:Why target JVM, when LLVM opens up all available uprocessors to native code?

Compile once rather than compile for each platform?

Plus look at all the goodies available for JVM... want Firebird or Sybase support? Just get the JDBC driver and off you go. Emails, HTTPS Servers, HTML Parsers, XLS, PDF, ...
With LLVM how would I get the functionality that Fred hadn't baked in? Would I be hunting for shared libraries for each platform I want to target?

Sorry to veer off Kukulkan
I chose PB for its simplicity, speed of development and native compilations.
I would not consider migrating to Java or a JVM middler before going back to straight C.
Though I am more in systems control than customer gui's.
It is a sad day when so much code must be written only to change the appearance of a gui.
I care about the bottom line in my spreadsheet, NOT THE SUPER FANCY RIBBON BAR.

-rant off.

skywalk wrote:Sorry to veer off Kukulkan
I chose PB for its simplicity, speed of development and native compilations.
I would not consider migrating to Java or a JVM middler before going back to straight C.
Though I am more in systems control than customer gui's.
It is a sad day when so much code must be written only to change the appearance of a gui.
I care about the bottom line in my spreadsheet, NOT THE SUPER FANCY RIBBON BAR.

-rant off.

Well said.

I wrote it already in this thread: If paying customers complain about the boring user interface, your very own preferences do not really matter. I also do not care about the look of the GUI, but if my customers do I have to follow. So sad, so simple.

In my first starting entry on this thread I lined out in detail what the issue is and what I tried. I mainly struggle with the incomplete and buggy layout engine (XMLDialog()) and the still incomplete DPI management (we do Cross Platform, so what about Mac?). In addition, the lack of options to manipulate the style of the application (eg dark mode). In the end, today, modern GUI is not possible with PB. And this is the reason I decided to take the effort to use Sciter and golang to re-do what is needed. With HTML+CSS I'm also able to follow any possible future trends. At least, much better than with owner drawn elements.

And, by the way, I started this thread in July 2018. I and others even offered Fred money to integrate Sciter. So, 1½ years later, there is still no change at all. The layout engine still does not render correctly and does not allow binding to owner drawn elements, bitmaps and their scaling in the dialog is not supported and so on. On Mac it is not even DPI aware. And there are Retina displays on Macs since 2006... So, was it a good decision to switch?

Kukulkan wrote:In addition, the lack of options to manipulate the style of the application (eg dark mode). In the end, today, modern GUI is not possible with PB.

JavaFX supports styling with CSS.

JVM
Java