What Developer Components/Utilities Do We Need?

BKeeney Software has been doing Xojo development for a long time.  Our clients span continents and industries and when we’ve needed something that doesn’t already exist we’ve created it.  This is how ActiveRecord/ARGen and Shorts came into existence.  In both of those cases we used them internally for quite a while before making them available for others.  Some products, like Formatted Text Control, were purchased when the developer left the community and since we depended on the product we decided to keep up development on it.

The question of the day is this:  What components does the Xojo developer community really need/want that we don’t have yet?

To me, the clear winner is a nice grid component.  At one point I recommended the Einhugur StyleGrid and DataGrid controls but it was never updated for HiDPI and there are no plans to do so.  As far as I know there aren’t really any good replacements for them.  Add any suggestions to the comments below.

We use a ton of plugins but it makes no sense to have every plugin installed for every project.  We also don’t update plugins unless we have a need so a minor update to a three year old application probably doesn’t need the latest plugin.  Managing plugins across vendors is a real pain.  Likewise managing Xojo versions for client projects is a chore because one project might be on Xojo 2015 R4.1 for some technical reason while another is at a newer version (but not the latest) and some projects are on the 2017 R2.1. While it’s not hard to manage all this it’s harder managing that across multiple developers. I’d love to have a utility to manage Xojo and its plugins by project.  As far as I know there’s nothing out there that does all of this.  Do I need to write this myself?  And really, how many developers need this level of Xojo/plugin management?

What else do you need/want to make your Xojo development life easier?

11 thoughts on “What Developer Components/Utilities Do We Need?

  1. I have actually started a fairly lightweight Xojo project/package manager myself. It incorporates an optional source control (that is super to easy), project selection, and per-project plugins that get moved in/out of the projects folder as needed.

    There are some caveats to it that I am working through. For instance if you have three projects using 2017r2 and 1 uses 4 plugins and 2 use 6 plugins then all three projects need to have the 6 plugins available because switching while open is not good. However you can have different numbers of plugins per Xojo installation.

    I have also lately been keeping two copies of each Xojo release installed. One has only the essential plugins I almost always use. The other one has every plugin I can throw at it for purposes of opening code from others and quick testing without playing “where is the missing plugin”.

  2. One possible thought is an updated graphics object, such as an OpenGL, or a Canvas that works with the GPU. It seems that OpenGL is being replaced with Vulkan, Windows has DirectX, Mac has Metal, and I am not sure of the Linux option. It doesn’t need to be OpenGL, and is could be something OpenGL ‘ish’ that works cross platform.

    Its just a thought 🙂

  3. The piDog classes showed promise during testing but were too slow in the app.

    The MBS plugin has a fairly complete implementation of the Cocoa listbox and hierarchical listbox. Mac only of course but really fast and easy to implement.

  4. An advanced grid is desperately needed from years, if not decades. I mean with grouping, pivot, multicolumn sort and more.
    Seems like no one is interested to develop one.

    I have tried all sort of native canvas sublclasses and also tried to write one myself. The truth is a canvas subclass is too slow when it’s time to handle more than 1000 rows and a fair amount of columns.
    The web is full of JS components working fairly good and some of them are also shipped as C# components but clearly no Xojo.

    In the end, the best approach I found is to embed a JS grid into a HTMLViewer and with some hafcks communicate with it.
    It’s far from being a perfect or easy to handle solution, but works, at some degree.

    Still looking forward for a native grid plugin. This would sell very well in my opinion.

    • Agreed, a customizable grid component is vastly overdue. I don’t think a canvas subclass is going to be fast enough or good enough to handle it. I *think* it’s going to need a plugin solution and that limits who can do it.

  5. The QuickLook plugin from me is useful to see in Finder which version a project needs. So I can open client projects always in the right Xojo version:


    For the plugins I use always my latest ones.

    Except for a bigger project with other developers where we have a dedicated Xojo version and plugins folder which is same for all of us.

    So Bob, I think you just need a Xojo copy with plugins folder per client project.

    • Having a copy of Xojo per project seems…overkill? I mean it’s certainly possible I just hate having multiple copies of the *same* version of Xojo.

  6. For starters I would like a simple list of which Xojo version should not be used for what. Like “Xojo 20xx Rx is not suitable for database work due to a data corruption bug”.

  7. I developed a Canvas subclass as a replacement for the standard ListBox control. It can easily handle millions of rows and columns (data is always on demand). I’d love to have it open sourced on GitHub but the control needs some refinement and I would need some help due to my very limited time. Let me know if someone is interested in helping me releasing my InfiniteListBox as am open source project.

Comments are closed.