Trying to move a project from Ubuntu VM to a Mint VM to see if this improves IDE performance issues on Ubuntu. I evidently do not know how to do this… I copied the project folder from the Ubuntu to Mint, but when I launch Xojo in Mint it does not see it as a project. Using Properties to change the … well, properties … of the folder to .xojo_binary_project does not help. Xojo on Mint seems to see it as a folder, and the items within it are not seen as a project. What do I do to do this properly?
When Xojo starts up, are you using the “Open an Existing File…” button in the lower left, are you able to navigate to the project that you copied over?
Xojo has three project file formats (Binary, XML and Text). Binary and XML are both single files with xojo_binary_project and xojo_xml_project extensions, respectively. Text projects consist of a folder containing multiple files and the project file has an extension of xojo_project.
Simply copy the project file (or files) to Mint and then open the actual project file using the “Open an Existing file” button on the Project Chooser window.
In XOJO I click “open an existing project” and click on the folder “myproject.xojo_binary_project [BE7EC061]”. It opens it as if it was a folder to show me what is inside (nothing, if I have “all project files” in the drop menu). If I do the same thing on the Ubuntu VM it opens the project. (Same thing means click on the original, not the copy. I suspect something breaks in the copy process.)
Perhaps the file open dialog is treating the binary project as if it is a compressed file. Are you sure that it is uncompressed in the directory that you’re trying to open it from?
I have no indication it’s compressed. If I open it in the Mint file manager I see the folder contents as App.o, FileTypes1.0, MainMenuBar.0, etc. I also see Project.md5. Everything in the folder is identified as file type “object code” except Project.MD5, which shows as plain text document. Hmm… Now that I look, the permissions for the project that will not open are drwxr-xr-x. I think the d means it’s seen as a directory, which would account for why xojo seems to treat it like one.
OK, somehow (a couple of times) the project was transformed from a file (on a mac I would say package) into a folder, and it’s components became files.
I recopied by installing dropbox on all systems involved and dragging the file rather than use the ‘upload’ button. This seemed to work, moving it as a project rather than a folder.
Now I have a few trivial items such as font sizes in the app are different, requiring either changing the font or point size or enlarging buttons, but that’s nothing.
I post the solution here since someone else may need to know that at least sometimes dropbox upload and drag do not work the same, and this can break a project.
Thank you for posting your solution back. As you said, it will potentially help future Xojo devs that run into the same issue.
The big question is … did it help with your IDE performance issues? I’m guessing that it did but I’m awaiting your response.
Everything you describe here indicates you did not move the project over, but instead moved over something else. These “object code” files are not the project, but are the intermediate compiled code generated by Xojo when you Run or Build.
Hmm. OK, I guess that could be. I’ve little experience in Xojo, on Linux in particular.
As to performance, using the right click/contextual menu for copy and paste went from five seconds for a menu to pop up after click to less than one second. This is after only a few minutes of use, but it sure seems so much faster that it’s not the same thing but faster, rather it’s a whole different thing…
Here come’s Tim’s broken records again …
It’s not Ubuntu or Mint specifically - but rather the fancy and overloaded nature of the desktop environment used. Ubuntu has a much more complex Desktop / Windows Manager than Mint.
If you set up Ubuntu (or any other Linux distro) to use a minimal desktop environment, you’ll see that IDE performance is OK on all of them. A hint, the primary nigtmare is Compiz -
While admitting I’m neither a Linux nor Xojo expert, I’m dubious the problem is the desktop environment because performance in everything except very specific parts of the Xojo IDE is very snappy. Even in the IDE, dragging or resizing an item is no issue, nor is copy/paste using keyboard. But right click in the Xojo IDE to get a contextual menu (for copy/paste in code or in the list of controls/handlers, or whatever) and things hang up for about five seconds until the contextual menu appears.
If I go to some other application and right click the menu is there before the sound of the click is gone. Seems odd that a bloated Desktop environment would hit only Xojo and only that particular part of the IDE. I’m not denying that a bloated Desktop Environment is a factor (and I suspect you have strong reasons for claiming correlation) but this seems to indicate a weakness with the Xojo IDE more than the environment.
(Running on a four-core 3.7 Ghz Xeon, 12GB ram, system and scratch on SSD.)
@Gary Carroll - I actually am a Linux expert as demonstrated by 21 years of kernel development (starting at 0.99pl10 before there actually was a Linux distribution of any sort) and over 29 distributions kept updated with tape and pSCSI/SAS driver information. I also have code in Open Look, Afterstep, Enlightenment, lesstif, X11R5, and Xorg’s previous releases (don’t have time for X11 any more, though).
Did you watch the video that I linked to? Any app that uses heavy graphics updating will be impacted by the compiz issues present in Ubuntu and other systems. Opening a popup menu is definitely controlled by compiz and different applications do this using different APIs. It is quite possible that the API used by Xojo is not the most efficient for that version of compiz.
Mint doesn’t use compiz by default, so it will be far less prone to the performance issues seen on a Ubuntu system.
Sorry for taking so long to get back, Ive been traveling. Let me explain a little better: I accept that you are an expert in Linux, and that the problem trigger is a bloated desktop environment, and that Compiz is the worst offender.
The point I was making is that since everything on Ubuntu seems to work acceptably (1/2-second response, or better) EXCEPT the XOJO IDE contextual menu (five second response or longer), this indicates a problem with the IDE in that particular area more than it shows a problem with the environment.
You point out that changing the environment to a minimalist one fixes the problem with the menu, showing that the problem is with the environment. I look at it a different way: if only that portion of only one app breaks under non-minimalist desktops, then the problem is how that part of that app works.
I did watch the video, and it was very informative, and offers convincing evidence that performance generally suffers due to Compiz in particular. But Im not talking about a general soggy feel, Im talking about only one bit breaking to the point of unusable while everything else works OK.
Anyhow, I think I understand the problem (largely due to your explanation) and just have a different view of assigning fault. I elected to work around the problem by using a different distro rather than the PPA fix.
Thanks for your help!
I had read in several threads that Xojo was sluggish with Linux, so I was not surprised that it was slow under Ubuntu. Now that I know why, it makes even more sense.
I am glad I switched for Mint
@Gary Carroll - I’m not disputing that there is something in Xojo that is different from the other, generic Desktop apps - in fact, I would hope there was - rather that there is a proven workaround and that compiz has issues with many apps, not just Xojo.
BTW - to all following this, you can also turn compiz off and still have all of the other GNOME desktop functionality.