Testing Xojo Linux 2021r1 on a Linux Mint 20.1 install - and before we drop-kick this out the door we want to make sure we’re not missing something simple.
I was in Xojo 2020R2.1 and got the notice inside the IDE that update was available. I went to Updates panel in IDE, hit Install, and Xojo immediately crashed. Had to install update manually (remove old Xojo and install new version). Probably want to check that out, Xojo. Maybe I’m just cursed.
Is there a way to adjust interline spacing in code editor? No matter what font or size we pick for editor, the text descenders are always cut off? It is really pissing everyone off who tries this Linux-version IDE out at our end.
So I go into the code editor, and realize that inspector panel is still shown, so I turn off inspector. OK, now I can see my code on wider panel (at least upper 75% of the text). Then I go back to app form display, and I get a whole blank panel where inspector should be. ?? I have to click around a while before Xojo wakes up enough to repaint the panels completely.
I was under the impression we would could have one set of sources and compile a correct end product executable for both Linux and Windows. Every one of the flagship golden examples provided by Xojo show up with text height chopped off on buttons, or some text-fit issue. OK, so we select Linux build and turn on " Normalize controls". The end result is still garbage - see screenshot. The controls resized, but with zero regard for over / underlapped borders. It seems like that could be done better. It would be helpful if the control height would be adjusted at design-time as well when “Normalize Controls” function is engaged.
If we setup and resize the controls in Linux and save the source file, then they are wonked out when we run on Xojo Windows. And yes we are using same system / control font and size on both OSs.
It looks like we’d have to maintain TWO set of sources, one for Linux and one for Windows?
What is going on with font selection? If I go to say, Options / Code Editor and try to select a font, I get this malformed, endless list. I want Verdana font. (Yes, MS TT core fonts are always installed on our 'Nix systems). I try to hit “V E R” while I’ve got that font list open, expecting it to jump at least the the “V” section…but no - Xojo is going to make me scroll and scroll and scroll all the way to the bottom of the toilet paper roll. Or is there another way?
Likewise, if I try to select a font at the drop-down box on Inspector panel, it will actually let me type “Verdana” as my font selection - and even corrects capitalization. Except I don’t get Verdana font - even though that’s what it says. When I open that drop down list box after manually typing in an entry, it will be pointing to some random font…like Courier New or Libre Sans or whatever entry it decides on. The only way I can get to the font I want on that list box is to scroll forever and select the desired font from the list - the slowest possible method with a long list.
What am I missing here? I talked to Xojo directly and they said it was hard to deliver Linux support due the multitude of different desktop systems. I understand that - except I’m using Linux Mint 20.1 Cinnamon, as recommended by Xojo. I ask Xojo if they could be inspired to fix these Linux issues if we bought Pro+ $2k licenses, but they said they probably wouldn’t fix “cosmetic issues”. This is a tool for building a user GUI, among other things - it is ALL cosmetic. And I thought the Xojo IDE was built with Xojo? The Xojo Linux IDE itself just doesn’t seem to be a stellar example of “cross platform application” - or we don’t have the setup tuned up right.
There’s a ton more issues we’ve found, but I have to move on today.! Maybe I’m missing some simple settings somewhere. I can see how the system is -supposed to work- on Xojo Windows, but it seems REALLY lacking on Linux side.
In addition, I found a tabpanel issue. If you want to pevent the user changing the tab, perhaps because the panel is for prefs and the user has changed one, but not saved it, then for macOS/Win it suffices, in the TabPanel change event, to set the PanelIndex. Under Linux the Tab will change to what the user selected anyway, but nothing gets drawn on the tab. Workaround: in the change event start a 1 msec timer and set the PanelIndex in the timer action event. That works nicely on Linux-Mint and RPi. I haven’t submitted a Feedback on that yet.
I was also stumped for a while because whereas in macOS/Win, an HTMLViewer which has an element expecting keyboard input will actually get it first, under Linux the KeyDown events of the HTMLViewer itself and its window get it first and may optionally not allow the HTMLViewer to receive the characters, even though it has the focus and a blinking cursor.
Finally I have some evidence that for a string with Nil Encoding, string.Length and string.Middle don’t quite agree on what constitutes a character, if the string actually contains a multibyte UTF8 character. But using .Bytes and .MiddleBytes() fixed that.
How many Fonts are installed in your boot system ?
Also: put so many things in a single document is not good. Take for example the UI size:
make a subclass of an element,in that element use #If Target and change its size, etc. for Linux only.
We are users like you and will not spend 30 minutes in a single row to explain.
I did find out that if you screw around with font select and size in Options / Coding there are some combinations that work, and some that are absolutely dangerous.
For instance Ubuntu Regular 14 point will hide all underscores, but at 18 point is OK. Other font / size combos will have different results. It would be neat if the text were rendered correctly always.
The number of fonts installed on any system is irrelevant - the interface should be fast and easy to select from a few or hundreds of fonts, and the selection box should display correctly no matter what.
If you’re referring to Zapfino font, no - we only select from the font set supplied by Linux Mint 20.1 Cinnamon package maintainers (see Xojo recommended requirements for Xojo Linux install) plus the few extra fonts supplied by MS TT core fonts. Ideally we would use Verdana, Liberation Serif, etc… In order to meet design specs we would need the system font & size identical for both Linux and Windows - at least until we get to various language translations. That’s another story.
For now: on the finished product the GUI will look -exactly- the same, no matter Linux or Windows OS. This is a full screen GUI where the machine operators probably won’t ever see the “desktop”, unless in some sort of maintenance mode. Product has to run reliably 24/7/365, reboots not allowed. System up time is measured in years.
Our GUI QC process would never pass any malformed or incomplete text, missing borders around controls, non-centered text, bad control overlaps etc.
I wonder how many of these Linux problems can really be blamed on Xojo. It appears that the vast majority of problems are text related—font metrics in particular. But Xojo isn’t alone in this regard. I’ve encountered this in a number of different Linux applications. I may be off base here, but I’m guessing that the problems originate in the GTK library, and there’s no one size fits all solution, because it also appears to be hardware dependent (screen resolution, graphics hardware, etc.). The GTK library and video drivers should be taking care of these differences, but it appears that they’re not. So, even if the Xojo team is able to get the GUI looking good on one hardware platform, there’s no guarantee that it will be acceptable on a different one. Linux has come a long way over the years, but it still appears to have quite a few problems trying to behave consistently across different hardware platforms.
Yes, I know what you’re saying - In the early days some of that was more of an an issue, but for the last decade or so we’ve had pretty good Linux performance across most all the desktop hardware we’ve been running - and much less headaches like we’ve had with various Windows graphics card drivers & updates.
Other cross-p IDE’s and apps have figured out how to handle fonts pretty well in Linux across different configurations - for instance Eclipse and Libre Office come to mind.
And we are using the Xojo recommended distro here - Linux Mint 20.1 Cinnamon, stock install. Which I was assuming that they are testing against. But in talking with Xojo recently they say they aren’t focused as much on Linux as they are on Mac/ Windows. OK - I see that. Oh well.
And there will be plenty of Pi users, waiting in the wings.
With a number of workarounds for all the issues I’ve filed feedbacks for, my app works fairly well under Mint 20.1 and on the Pi. But I have no workaround for the 100% CPU usage issue or the print-related crashes.
Just to help rule out hardware problems - we tried the same Xojo Linux Mint setup across several hardware combos - Intel i3 thru i7 / AMD Ryzen CPU’s, and Nvidia / AMD / Intel graphics chips, different motherboards, etc. Unless we’re extremely unlucky with hardware, Xojo Linux 2021r1 seems to have the same font rendering issue across all hardware we tested - and Xojo is the only application we saw exhibiting that problem. Qt, Eclipse, Open Office etc. are rendering fonts just fine, in any size, on all the test hardware we have in the lab. BricsCad (x-platform CAD) did have a problem rendering some menus under Linux a couple years ago, but they seemed to have sorted that out last year.
And I have this problem: after installing Linux in Hojo, the keyboard does not work. Either there is some problem with the drivers, or with the keyboard itself. I have already updated what I could, but there is no result. Maybe because my Logitech keyboard is already old? I was thinking about buying a new keyboard. Can you tell me if any of these keyboards are good for me?
I’ve always had formatting issues on Linux. I created a routine to adjust things (see below), I call this from the Open event in every window. This app hasn’t been used on Linux in the last few years so I’m not sure how things have changed. Note I also have some adjustments for dark mode for objects that exist on most of my windows. I’ll be looking at it again in the next few weeks as I’m anticipating some new Linux users.
I just did a fresh install of Mint/Cinnamon on an old Dell Latitude E6500, then installed Xojo. IDE looks fine on this computer. However as expected there are minor formatting issues with lots of controls.
Don’t expect this code to work as-is with your project, its a concept showing how you can adjust things at runtime so you don’t need a separate project for Linux.
Public Sub AdjustControls(w As window)
' Adjust controls
Dim i As Int32, r As Rectangle, t As Label
For i =0 To w.ControlCount-1
#If TargetLinux Then
If (w.Control(i) IsA PopupMenu) Then
PopupMenu(w.Control(i)).Height = PopupMenu(w.Control(i)).Height + 6
PopupMenu(w.Control(i)).Top = PopupMenu(w.Control(i)).Top -2 // just a little tweak
End
If (w.Control(i) IsA BevelButton) Then
' If parent is not a window then icon needs adjustment
If Not (BevelButton(w.Control(i)).Parent IsA Window) Then
BevelButton(w.Control(i)).IconDX = -18
BevelButton(w.Control(i)).IconDY = -10
End
End
' PushButtons are too tall on Linux but changes to the height or font size are ignored
'If (w.Control(i) IsA PushButton) Then
'PushButton(w.Control(i)).Height = 22
'End If
#Endif
If DarkMode Or Color.IsDarkMode Then
If w.Control(i).Name.Left(10) = "RectUpdate" Then
r = Rectangle(w.Control(i))
r.BottomRightColor = &ceeeeee
r.TopLeftColor = &ceeeeee
r.FillColor = &c000000
End If
If w.Control(i).Name.Left(10) = "UpdateInfo" Then
t = Label(w.Control(i))
t.TextColor = &ceeeeee
End If
End If
Next
End Sub
Well, just about anything to help. This is what Xojo Linux’s own gold-standard example looks like - WITH “Normalize Controls” turned on for Linux build. Oops. Looks like normalize doesn’t know about custom controls…
