What about having the full GTK widget set and Cairo drawings on all 3 platforms?

General
1

It is not secret that Linux apps created with xojo had many UI bugs and not really theming friendly. Maybe this is mostly because of the FIXED layout and deprecated objects that Xojo uses in GTK to emulate the layouts for MacOs and Windows. Also not a secret that the UI performance in windows has being problematic for years. And each time Apple made a new version of MacOs sometimes screw with the APIs, like the Listbox problem in Mojave.

Also Xojo has a limited set of “out of the box” controls, implementing all the GTK widgets will increase the available controls, get better Layout design with the Layout Containers, have a better multiplatform consistency and ptimize the Xojo team effort mantaining 1 tecnology instead of 3.

Cairo drawing also could improve consistency and quality along with the base for other user request like PDF capabilities. And of course, the new GTK uses GSK rendering API for widgets; it uses Cairo and OpenGL, OpenGL ES, or Vulkan, in order to render the widget current state using modern features, like hardware accelerated rendering on the GPU.

GTK has a great performace and could have themes for each platform, or each app can have a personalized theme.

I know this is a big thask, but, with the poor performance on windows and all the glitches on linux for having GTK not fully implemented, this could be the solution to solve this problems and MAKE xojo much more powerful and appealing to new customers.

If you decide to implement this, I think the best way will be to make NEW objects (gtkwindow, gtklabel, etc) while mantaining the current objects. in this way you can implement the full potential of GTK, Drawing, Layout Containers and widgets.

I think that quality is what really matters, not hust the kind of control that is ussed (native or not). Please see the 3 pictures attached with GIMP in Linux, WIndows and MAC (At least, on windows and linux have better look and feel that xurrent xojo apps) Also the new interface with a modern theme and icons.

GTK now has a new model to mantain API in all the new iterations until a new mayor version. Maybe set a targget to deploy with GTK4 Next year?

Just an idea, what do you think?

Feedback Case 52860 - Implement the full GTK widget set and Cairo drawings on all 3 platforms for better multiplatform compatibility

Gimp On Windows

Gimp On Linux

Gimp On Mac

New Gimp style On Windows

New Gimp style On Windows other theme

Feedback Case 52860 - Implement the full GTK widget set and Cairo drawings on all 3 platforms for better multiplatform compatibility[/quote]

So, not an easy solution.

But, Maybe if Xojo implement GTK in ALL 3 desktop platforms…

  • Lots of contros out of the box for xojo
  • Great Layout widgets to make modern interfaces
  • Awesome performance with hardware accelerated drawing
  • Consistency in all the 3 platforms
  • Cairo Drawing could be used to add PDF capabilities
  • Xojo team will focus in 1 UI instead of 3
  • Apps with themes in all the platforms.
  • Etc

Feedback Case 52860 - Implement the full GTK widget set and Cairo drawings on all 3 platforms for better multiplatform compatibility

Gimp On Windows

Gimp On Linux

Gimp On Mac

New Gimp style On Windows

New Gimp style On Windows other theme

Feedback Case 52860 - Implement the full GTK widget set and Cairo drawings on all 3 platforms for better multiplatform compatibility[/quote]

2

Seems unlikely given GTK is LGPL. While not as restrictive as the GPL still a potential IP minefield they may not want to risk.

3

Are you aware that Xojo ALREADY uses GTK for the linux apps? Why would be different to use it on other targets? Also, The Xojo team already have experience on this, so it should not be so difficult.

4

Color me mis-informed if you must…

But are not CAIRO and GTK both entities designed specifically for Linux?

So attempting to use them for macOS and Windows, would just be another “emulator”, and therefore not really solving anything, not to mention moving away from the “native” macOS and Windows asthetic?

Apps for any OS should maintain (as best as possible) the expected UX for that OS, and where possible leverage those tools that the OS provides

5

Of course but GTK is a requirement to be installed on Linux for desktop apps. They do not package GTK alongside your app.

On Windows/macOS this is extremely rare to find pre-installed (if at all) and thus would need to be packaged with the Xojo app.

6

No. Did not you see the pictures attached? GTK is designed to be cross platform. Also cairo which one of its main benefits are native hardware accelerated drawings on any platform along with consistent output on all output media.

Xojo already do this for all the libs. And GTK documetation says this is the best option to avoid a DLLhell. And, the licence doesn’t care if the SO has preinstalled libs or those are along the app. It just cares about the app using them.

7

[quote=398886:@Pedro Ivan Tellez Corella]

Xojo already do this for all the libs. And GTK documetation says this is the best option to avoid a DLLhell. And, the licence doesn’t care if the SO has preinstalled libs or those are along the app. It just cares about the app using them.[/quote]

Xojo does not bundle GTK with the app. You must install it on Linux first. The same would be necessary on WIndows/macOS as they are not likely to bundle it. That would be detract from the apps usefulness though as many would be upset about needing to install pre-requisites. Might as well use Java or .NET at that point.

8

no offense… but all of those looked rather 1980’s to me… not a one looked “Native”…
being “consistent” in this case is not a “good thing”
I see no benefit to installing some GUI framework to override what the native OS already (for the most part provides)

So, yeah I am failing to see the merit to your argument… sorry.

9

@ Pedro Ivan Tellez Corella

Using GTK for all platforms might make it easier for Xojo engineers to provide cross-platform apps, but it takes away one of the selling points of Xojo: native controls.

And a lot of the current problems seem to be due to Xojo not using native controls when they said they were (eg Labels on Windows).

So it seems to me the way forward is to use more native controls rather than a non-native framework.

10

no offense… but, you should have your eyes checed if you see that… The only difference is that GTK actualy uses Cleartype on labels, so, much better quality on screen.

1281×720 34.8 KB
[quote=398898:@Markus Winter]

And a lot of the current problems seem to be due to Xojo not using native controls when they said they were (eg Labels on Windows).[/quote]

I know, it was me the one who report that :stuck_out_tongue: But it is way different creating a bad implementation of the win32 and D2D, than using a framework already working great with high performance and hardware accelleration.

About being native, The final user dont even care, they just want some that works. Also I’m looking for that. I queality cant be archive with “native” controls, I preffer using another framework. Just consider, even Microsoft uses its own framework for .Net apps instead of “native” controls.

11

I have to disagree on that.
The drop down menus are different too.
I do agree that the text in the labels is much better in GTK.

12

Well we can agree to disagree… you like it… I don’t… your right, as well as mine.

13

Dave, don’t confuse poor layout with the usefulness of the underlying technologies. You can create a GTK app that is incredibly attractive and usable. The good news about what Pedro is describing is that it can be done cross platform.

I think The GIMP’s layout and UI design is still stuck in the 90s and might not have been the best example, but the point is that the design looks the same on all three platforms. This would translate into a good UI design also looking the same on all three platforms.

And tests with Cairo have shown to be on par with the current Metal implementation in screen update performance on Mac OS.

14

Question: Are the GTK controls recognized by the macOS system as controls that can be utilized by assistive services? GTK is NOT a solution unless this happens. When I moan about non-native controls, this is among one of the actually important reasons - visual appeal aside.

15

Again… disagree…
It is not important (nor should it be) that macOS looks like Windows looks like Linux…
and since “most” people (developers and end-users) tend to favor one platform, they aren’t going to care that their favorite app looks the same on someone else’s computer…

and with that I will be leaving this conversation, since it really at this time is moot, and any further postings will be people either trying to convince others how “good” it would be, and the rest disagreeing…

16

GTK 3 supports assistive technologies, touch, zoom, high contrast, braille, and text-to-voice, so I believe that you would be satisfied on that front. From GTK.org

Accommodating

GTK+ caters for a number features that today’s developers are looking for in a toolkit including:

  • Native look and feel
  • Theme support
  • Thread safety
  • Object oriented approach
  • Internationalization
  • Localization
  • Accessibility
  • Bidirectional text support (LTR/RTL, Left To Right/Right To Left)
  • UTF8 support
  • Full Documentation
17

The most important thing to keep in mind when examining these situations is that you can create a bad UI and UX design in ANY framework. However, having a framework that provides cross platform “consistency” in both the coding layer and the resulting UI layer is the holy grail of end user app development.

18

I think this is too different at what Xojo is delivering right now. A change like this will not be an easy thing to do.

If they think GTK+ is a good idea, maybe that could be delivered as an add-on.

I know Xojo wants to deliver mac, win, linux, web, ios, rasp, console and even android with native (or as close as possible) elements, and that’s a good selling point.

But how about a Xojo-GTK version? A desktop version (mac, win, linux) of Xojo that use GTK as the graphics framework. They could market to people that want the same look on all 3 platforms. I haven’t used Windows 10 much, but I believe many programs don’t look like windows programs but more like modern web or tablet apps.

19

Disagree. There are those that have our preferred platforms because of the paradigms we prefer. Some people prefer cost, some prefer visual appeal, and some prefer the paradigms.

There are people who choose Mac for the experience.
There are people who choose Android because they like the way the OS works, not because it’s cheaper.

Requiring the same design across every platform is bull* made up by designers who drank a bit too much of their own kool-aid.

20

You are correct IF you are dedicated to one platform, or have customers who are single platform focused (or don’t mind maintaining different code bases for each platform that you support)

On the other hand, my team supports 14 different platforms, so we use the best tools for the platform set involved. One of the biggest compliments that we received from a huge number of our BRU Server corporate level users was the consistency in the UI look and feel of our management console app - thanks to my choosing REALbasic/Real.Studio back around 2004. They can move from Linux to Mac OS to Windows and the app works and looks the same. That also makes training departmental staff on the app - regardless of their potential platform - one training session instead of 3. They can have an internal training session for the business, engineeing, and creative teams all at once and not have to caveat the differences in their platforms to manage departmental backups.

For the other platforms, we tend to use Python/Tkinter, but we’re bringing a couple of our engineering folks up to speed on Java10/JavaFX.

And this? People don’t choose Android. They choose a phone or tablet that either meets their budget or their functional requirements. Verizon has admitted that they sell more Android-based devices due to the cost sensitivity of many customers or because they simply have an anti-Apple bias. But, if the customer has the budget to buy an equivalent iPhone, it’s a no-brainer and the iPhone is what gets taken home.

Again, this is a view that you can only take if you’ve not been involved with large scale development environment. Going back to the 80s, MOTIF was the answer for X11 in large business environments. Corporations licensed MOTIF for tens of thousands of dollars so that the source code and resulting app design was easier to manage. It wasn’t until Linux and the free X11 alternative provided in the mid 90’s that we saw this start to change. Even at the C layer, POSIX was a godsend. In 1997, I was able to start paring the BRU source code from over 180K lines (not counting comments) to less than 90K lines because we were able to start removing vast segments of code that were wrapped in #ifdef … #endif blocks. We now have one BRU Source tree hat compiles on an of our Unix, Mac OS, and Windows platforms with less than 8% of the code being platform-specific.