Xojo in 2017: A Review [Part 4: The Community]

This is the fourth part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3

-----

Bob Keeney writes in his latest piece that “software development is fluid” [1]. Always changing, evolving, and not easy to schedule around. It is a nice analogy and I get the underlying message. There has been a current on the forums that maybe Xojo does not do enough to resolve bugs. Perhaps they are too focused on new stuff that important issues do not get addressed. Bob is writing a piece here defending Xojo, their development style, and the complexity of what they are trying to achieve.

I think like most in this niche of software consulting we rely on Xojo being a reliable product. Our success in some ways is tied to theirs. Let me rephrase that a bit: Xojo consultants would prefer to stay Xojo consultants versus primarily using other tools. He wants to promote the tool he likes so much and so do I. Most in the community are like minded in that way.

Many of his arguments I suspect are valid and reasonable. I think for the most part you see this throughout the Xojo community. We all recognize how challenging it is to run a small software company. Some part of us appreciates Xojo on a fundamental level. We also become have become proficient with it and it enables us to get more done.

However, there are times when it holds you back. A new release breaks something or a new feature does not work as expected. The community lights up then and the argument remains:

• Why do you not give us more heads up on what you are doing?
• Why do we not get more time to test?
• Why are there not more testers?
• Why do bug reports take so long to get fixed?

It can get pretty excited at times and it is not unheard of for a thread or two to get locked shortly after a release. I love this part of the community because everyone is so invested in the product.

When you look at issue trackers and forums for open source languages it is rather dull. Many times there are few that are invested in a language because you are only one console command away from installing an entirely new development stack. The questions are highly abstract and technical and the responses are typically slow and methodical.

I comment aggressively on the Xojo forums that I wish the (Xojo) engineers would tell us more, show us more, give us more. Sometimes they fire back and have told me that being on the forums is not in their job description. Nonsense. If the Xojo engineers left the forums the community would be harmed. The Xojo engineers are not just part of Xojo they are also part of the community. They would miss us as well.

We all want to enjoy where we work. We push Xojo pretty hard and that is healthy but we also have to make sure we are not making it intolerable to work at Xojo. Like Bob said we need to do our part with bug testing, writing open source code, and helping others in the forums. However, the community is not to blame when regressions hit and progress slows. Some part of it is due to the enormous nature of what Xojo is trying to accomplish. The other part is the secretive nature in which they do it.

This is why in Part 2 of this series I suggested open sourcing the standard library; The mish mash of libraries and classes in either Xojo, C++, or third-party libraries. When bugs are encountered in the “framework” it can force you to use a different version of the product. The sad truth is regardless of the difficulty of a bug report it may not lead to a timely resolution. Often times you will get a confirmation and then wait several releases. You have no idea if they have even scheduled to start fixing it.

I feel like if Xojo is not going to commit to fixing something in a reasonable timeline then that would be a great opportunity to ask the community to attempt it. Let us earn badges or points or something. Give the top 5 every month a coupon for example. I am thinking bug bounty board meets achievement points. We don’t need any cash or prizes but recognition to the community for being involved. Most importantly let us help you chisel away at the issue list.

If there is a problem with Bob’s piece I would say my only nitpick is I don’t think software development is fluid at all. In fact, I think it is solid. Solid like a giant rock that has remained stationary for millions of years.

Software development is like sculpture as you chisel 0’s and 1’s into a rock face. You spend so much time planning and considering the subject matter and problem at stake. You design and architect the database, storage, and architectural nuances of how messages get from one method to another. You consider deployment strategies and security concepts to protect your users and not leak your database to Reddit. You do all of this in the hopes perhaps you will achieve something great. “Something great” more often than not is a tool or utility to create more software to manipulate even more 0’s and 1’s. 

I say solid as a rock because even with source control, undo, snapshots, checkpoints, auto-saves, and screen recording you can’t save a bad program. It takes too much work and the amount of effort to resolve the plumbing job of a poorly planned program is terrifying. You start dreaming up ways to convince your client or boss that it would be best to start anew. As you mature you realize this is not always a practical strategy and so you are going to have to do surgery more often than not. You are desperately hoping not to chisel the last bit of support that keeps the rock standing up.

I am not convinced software is fluid at all.

I am convinced Xojo makes for a great chisel.

I also believe the Xojo community is part of the value proposition of the product. For example I search the forums before I search the documentation. Thank you forum.xojo.com. 

-----

[1] = http://www.bkeeneybriefs.com/2017/08/software-development-is-fluid/

Xojo in 2017: A Review [Part 3: The IDE]

This is the third part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

-----

When I started this series, I did not anticipate the level of feedback that it would encourage. With over 100+ Xojo forum posts discussing the pros and cons of my suggestions I am thankful they have been mostly well received. There have been some negative sentiments and disappointing comments from those who misconstrue my intentions but let me be clear: I love Xojo.

One of the reasons I love Xojo is because I feel software development should be more accessible to the average person. A computer science degree is deservedly respectable in the industry but should not be required for every task. Computing has become so ubiquitous that programming should not be as difficult as it is. Xojo represents a perspective on software development that with easy to use tools one can be equipped to meet the challenges facing them. We at 1701 Software have used Xojo to control custom hardware devices, build mobile and desktop applications, operate a secure file sharing service, monitor / manage virtual machine infrastructure, and much more. Xojo similarly to Java operates on several platforms in both 32-bit and 64-bit variants and allows you to use a time tested and proven language to achieve your goals.

The principal difference between Xojo and Java is how you reach those goals. With Java and others, you have any number of community and commercially supported IDE’s as well as your favorite text editor to develop software projects. The IDE’s in my experience can either be underpowered or completely overwhelming and lack a certain aesthetic finesse that I have come to expect from my macOS environment. Generally speaking you still have to maintain the appropriate version of the Java JDK or framework you wish to use and you may have to do some build configuration steps in order to actually produce libraries and executables to be used on any environment. Sadly, Java actually has the upper hand here whereas compared to C++ and other cross platform tools the build steps, IDE’s, and development resources available are varied and typically challenging to use. Even if you find these tools easy to use there is no question that setting up your build environment and keeping it synchronized with the rest of your team requires time and diligence to construct and maintain.

Xojo simplifies all of that with an IDE that “out of box” is ready to go. Immediately after installation you can start designing an application, writing code for the built-in event handlers and hit “Run”. No other environment even comes close in regard to the “out-of-box” experience. While there are tools like LiveCode and Flash that sort of mimic this behavior, they do not use native controls and rely heavily on their own runtimes and environment. With Xojo you can produce a fully qualified Win32 or macOS Cocoa app in less time than it takes to install Visual Studio. The IDE is to thank for that and trust me when you have mostly completed your project and ready to start testing the IDE helps you there as well.

Of course, you and I both know you should be testing throughout the development process but sometimes it is just not practical to test the code you are actively working on in every environment. You will thank Xojo for their quick installation times and “everything bundled in” approach to software development when it comes time to install the IDE on test devices and virtual machines for debugging purposes. If that was not easy enough you can even use their excellent remote debugger tool to test your code on the other platforms without even leaving your primary development machine. These kinds of ease of use scenarios that take into account the typical development workflow of a cross platform developer gives you a warm and fuzzy feeling that Xojo knows what it takes to deliver.

With easy access to constructing new windows, classes, modules, etc. in your project the IDE hand holds you through the process of organizing your project. The IDE maintains your codebase internally and through visual cues, a tree view navigator, and tabs you can zoom in and out of your project depth as needed. The IDE also allows you to easily share code with others either in an open source approach or a commercial approach using a single file format for your entire project. Nothing is simpler than reporting a bug or sharing a development construct with others than sharing a single file. Naturally this is not optimal for larger teams or those who care about their source code history and so it conveniently supports a source control text based format as well so you can track your changes. Commercial operators will be pleased to know that classes and modules can be encrypted so you can sell them in the open market. A new Xojo plugin methodology that has been announced should further enable third-party development and amplify the number of plugins available in the marketplace.

The Xojo IDE is responsive, attractive, and easy to use even for the software newcomer. For the professional developer, you will find subtle but important features such as object attributes, build steps, and IDE automation enabling you to perform even the most challenging tasks. Where other programming languages require specific tools to handle continuous integration the Xojo IDE can perform these functions “out of box”. (Note to self in the age of Internet downloads is there a more modern saying than “out of box”?) Lower level plugins powered by C++ can be added and removed very easily through the use of a “plugins” folder. The Xojo IDE contains an off-line version of the framework and language documentation for those times when Internet is not available.

My overall point here is that while I suggested that the standard library of Xojo framework be open sourced I only did so because to me the power of Xojo is in the IDE and compilers. I would not pay for the framework with a third-party IDE and I would be happy to swap out the framework if a better one came along. What attracts me to Xojo and what keeps me there is the “instant-on” (there it is!) capabilities of the IDE without having to write a dozen configuration files and map JDK’s and library paths for every machine I use. I use a lot of machines on a daily basis and just thinking about using other tools gives me a headache. I also know that when I present Xojo to newcomers to software development or even the old timers that they are surprised how much can be done with it. Is it right for every job? Of course not. We specialize in .NET for many of our enterprise customers and the occasional Java when some library simply cannot be replaced. When I have a choice and when circumstances allow I always choose Xojo first.

Of course, this would not be a proper part of my review series if I did not point out some areas where the Xojo IDE fails and what I suggest for improving it.

First and foremost, as I outlined in my first part of this series I would like to see multiple project support in the IDE. Even if it never truly supports multiple projects concurrently I would love to see the ability to create console helper apps side by side with the primary app and let the IDE do the work of constructing those executables, passing simple arguments back/forth, and managing the directory layout of the ultimate deliverable. It is simply too much work right now to build a console helper application and connect it to your main executable.

Second it has been noted several times that each platform has subtle but unique differences in the appearance of native controls. Buttons and labels for instance use different heights and text sizes by default. This means that despite spending a great deal of time designing your application it might look rather bad on Linux when you ultimately test it out. You are then stuck spending hours doing “#If TargetLinux” and tweaking each individual control manually on their respective “Open” events and it is tedious. On the right-hand inspector, I would like to see the property window remain as it is with all the control properties. However, I would also like to see 3 tabs for each platform with property “overrides”. From here you could visually say “On Linux make button height 30” without having to write any code to achieve it. If the respective property override is blank or unfilled then it uses the global property.

Third once you do start working on larger projects you very quickly want to share modules with other projects. It becomes quite tedious to do so currently because the IDE does not support external modules with sub-classes. We really need this fixed and I don’t know what kind of effort it will be but I also don’t care. This is a small and subtle bug that you don’t encounter until you have made all kinds of architecture choices around external items only to discover it does not work as you would expect. It is very annoying opening a project on another machine and then having to re-map dozens of external classes when one module would have been appropriate. It would also allow for the correct name spacing of our libraries which is just good architecture in my opinion.

Fourth speaking of plugins and the ability to encrypt code and share it; We need a proper package manager for Xojo. I should be able to shop a “store” or “marketplace” for code and pull down all kinds of classes and utilities directly from the IDE. It should support trials, demos, and allow for purchasing of the commercial variants directly from the IDE. It should also emphasize and support open source work and allow you to right click on a folder and say “Import from GitHub” where it would pull down the latest code from a specific repository inside that project folder. Keeping it synchronized and alerting you when third-party code has changed would be awesome as well. I would love to know when MBS has updated their plugin automatically in my IDE. This is more useful though for open source components where you do not receive a regular newsletter announcing the change. “Oh Kaju has been updated?! Awesome yes please download the updated bits.” I suspect a great deal of this will be possible with the new Xojo plugin format coming down the road and I hope they have something like this in the works.

My fifth and final suggestion for the Xojo IDE is about the upcoming navigator changes they alluded at XDC 2016. Make sure that Alpha/Beta is very long winded and open to almost everyone who wants to try it. Let’s not shoe horn this in at the last minute and screw up our workflow. The navigator may not be ideal but I have gotten used to it and very productive with it and we need to make sure whatever changes are coming are in fact you know… better. This is not about resisting change but making sure the community really backs the direction otherwise they are better off with what they have today. The Xojo navigator changes were quite dramatic and at that time not enough customer feedback was solicited in my opinion.

I still have many parts of this series to complete so fill out the box below to subscribe to updates and news about our Xojo development, components, and resources!

Open source upload control for Xojo Web

Plupload HTML web upload dialog control for Xojo Web.

Special thanks to Alexander Marthin @ Lumafilm.dk for sponsoring this project and generously donating it to the Xojo community.

Plupload is a widely used HTML/javascript web upload control facilitating the upload of large files via the web browser. The Xojo Web upload control is not well equipped for large files or when being used in a CGI environment.

Our objective here was to implement a web dialog control that presents a fully featured upload control powered by Plupload. Plupload can upload to any web server but by default provides a PHP script to facilitate file uploads. This repository contains a "www" folder which are the scripts and assets that need to be uploaded to your web server in order to facilitate the uploads. The "www/uploads" folder is where files are saved upon upload (configurable - see below).

To use in your Xojo Web project you want to copy the "Plupload" dialog control to your project. See the "btnShowUploader.Action" event in the example project for details on how to instantiate, configure, and show the control.

MIT licensed. Find it on Github at: https://github.com/1701software/Plupload_Xojo