Xojo IDE add-ins Feature Request

I created a feature request <https://xojo.com/issue/29136> asking for support of IDE add-ins. IDE add-ins would provide the opportunity for developers to add features to the IDE that Xojo Inc. itself may not want to develop or have the resources to develop. IDE add-ins could also provide a revenue stream for 3rd parties. The obvious burden for Xojo is in developing and maintaining an API to support this but I believe that the benefits would outweigh the small burden and could not only provide some solutions to the short term deficiencies and dislikes but could also get Xojo into some new areas of development use.

Please take a look and if you think it is a good idea then please add your support by putting it somewhere in your Top Cases.

I included some links below to material about add-ins for Visual Studio because that is what I know best, but other IDE’s support similar schemes. If you want to see the VS gallery and information you can click on the links below to get an idea of what I am trying to describe in the feature request.

VS Add-ins Gallery
Links to the SDKs and tutorials
Some essential VS developer add-ins

Sounds like a great idea… added my support.

How is this different than the feedback request here?

<https://xojo.com/issue/14635>

It stands to reason that if you can have IDE add-ins, the product (Xojo) should allow for a plug-in model.
One of the biggest weaknesses around Xojo is that its not allowing for the delivery of modular components.

And look, this doesn’t mean, on Windows you need to build a DLL and on Mac you need to build a Mac Library…

Just being able to generate an RBX from the compiler would be more than useful.

Gary

I think Carl is referring to extending the IDE with new features (IDE plugins), while <https://xojo.com/issue/14635> refers to building your own re-usable libraries for your applications (Application plugins)?

…I suppose if done right, application plugins could potentially also be used as IDE plugins…

Thanks Alwyn, you have answered correctly :slight_smile:

[quote=29641:@Gary MacDougall]How is this different than the feedback request here?
Just being able to generate an RBX from the compiler would be more than useful.
[/quote]
I agree that being able to generate a RBX from Xojo would be great and I did mention in the feature request that ideally add-ins should be written in Xojo, although there are cases where it may not be so desirable when say there is an potential add-in available from a vendor that exists as source code in maybe C/C++.

To be clear - what is suggested is a way to extend the IDE, a Xojo API that provides information about the current project (like a DOM and events and state from the IDE UI. I will give a few examples just in case the feature request is not clear to everyone. Again I mostly reference Visual Studio as a good example of where this feature already exists.

(1) An add-in called GhostDoc, when installed this add-in provides a hotkey Ctrl-Shift-D so that when your cursor is in a method’s code the add-in examines the code and generates comments that document it. (It works by examining the grammar in your method name)

public Data.Company GetCompanyById(string userId, long companyId)
{
...
}

Pressing Ctrl-Shift-D and GhostDoc inserts the comments as below:

/// <summary>
/// Gets the company by id.
/// </summary>
/// <param name="userId">The user id.</param>
/// <param name="companyId">The company id.</param>
/// <returns>Data.Company</returns>
public Data.Company GetCompanyById(string userId, long companyId)
{
...
}

You can see that /// is a valid form of // but differentiates the GhostDoc comments and that when you find all of the /// comments in your code and strip them away you have XML ready for a documentation or help system.

(2) Invoking external code, PInvoke.net, you want to know the signature for the declaration of an external function, PInvoke.net gives you a new menu item that shows a dialog allowing you to search and scroll through database and insert the code at the current cursor location. MacOSLib and Windows Functionality Suite already have much of the material to construct a database for Xojo.

Conceptually a snippet manager is very similar to the Invoking external code example above, just a database of code snippets instead of external function declarations.

(3) Code visualisation (UML Diagrams). Here the example is from the NetBeans IDE, Visual Studio has similar features but I thought I should show another IDE with add-ins. You can skip through the first half of the video below where NetBeans is being setup for the new add-in

http://www.youtube.com/watch?v=A4Y8vxtxev8

Exactly my point. I also think that having application plugins is far more important than having IDE plugins / add-ons.

I’d say that plugins you can deliver to your customers is far more of a priority than an IDE plugin that the Xojo developer will use.
With that said, the two aren’t mutually exclusive. I would gather that if you build the technology to generate an RBX out of Xojo, that would be the output that would be used for solely for the IDE.

I cannot see there being “hooks” into the IDE from another language like Java or C++ that would allow for Add-ons as Xojo is built from Xojo itself, and right now, I know of no way of calling into Xojo at runtime from another language. I could be wrong about that – but thats my impression.

The two requests are not competing, Xojo sets the priority, probably somewhat based on user feedback and probably also based on where they want to take the product, it is up to them, it is just an idea from me and I can live without it the same way that I can live without being able to make application plug-ins using Xojo. However it is an idea that would allow 3rd parties to extend the UI in ways that Xojo cannot or do not want to resource.

[quote=29678:Gary MacDougall]
I’d say that plugins you can deliver to your customers is far more of a priority than an IDE plugin that the Xojo developer will use.[/quote]
I think that you are missing the point, the IDE is what you, the developer, use to develop your product for your customers. A code generator add-in could deliver the same functionality as a component compiled and written in Xojo, and delivering standalone binary components piecemeal has been historically troublesome. Joe @ Xojo had stated in an old conversation that loading and invoking a Xojo binary was not straightforward, I guess if it was then #14635 would have been delivered a long time ago.

[quote=29678:Gary MacDougall]
I cannot see there being “hooks” into the IDE from another language like Java or C++ that would allow for Add-ons as Xojo is built from Xojo itself, and right now, I know of no way of calling into Xojo at runtime from another language. I could be wrong about that – but thats my impression.[/quote]
There are no ‘hooks’ from the outside inwards (that is an automation scenario), with a add-in/plug-in API the add-in/plug-in components get activated from the inside outwards, Xojo IDE would communicate with the add-ins in a similar way to the application plug-ins that we already have. IDE add-ins could be in C/C++ just like the existing application plug-ins - it would be better than nothing and so I would not try and tie the feature request for IDE add-ins to the feature request for being able to produce components in the Xojo language.

Carl,

I see your points and understand things. I guess what I’m saying is that in the grand scheme of things, given the limited resources. IDE Add-ons falls way behind having plugins being created from Xojo - in my opinion.

I know the two are not mutually exclusive and you could do one without the other – I’m with you on that. I just would rather them focus on things that are more important to the Xojo ecosystem than something that is going to effect the development side (only). I’d love right now to modularize my application and deliver components so that I’m not having to deliver a full EXE or binary all the time.

There’s things about Xojo that are wonderful. But one thing that I think holds the product back in the development world is its inability to deliver modular components. For example, in Java you have the ability to deliver libraries, DLL’s on Windows and dynlib’s on Mac. Choosing C++, Java, C# is an easier choice if you need to work with a team that needs to deliver a large scale application with lots of pieces that need to be spread out – with Xojo this becomes a major issue.

In other languages, each of those can encapsulate all or some functionality of your application that can allow you to deliver a modularized payload. It also allows teams to work on libraries not the whole application outside the scope. For example, I might have my GUI people work on the GUI part of the application, but have my database team work on the data abstraction layer, and both would be separated in code base and functionality, but are part of the same application and framework. Its missing from Xojo, and I think this hurts its adoption.

I think that Xojo will never be taken seriously in the development IT world unless you have that core functionality. Most, if not all “compiled” languages allow for this, and even some byte code interpreted ones do as well. Its one of the major things that I think holds back the Xojo product from becoming widely accepted. When I look at the set of features and the ranking, obviously (to me) this ranks up there high on the list – is it before mobile iOS delivery? Probably not, but its right behind it – and yet, I see people promoting other functional things (which are great) to the top of the feedback pile, but somehow plug-in creation never seems to be brought up.

To me, its THE single most important feature that you can’t get in Xojo right now that I think stops someone from using Xojo.

Gary

Hi Gary

I understand what you are looking for from Xojo, although I think you should approach the idea of being able to deliver parts of your application with much caution. In the past it has been very difficult to maintain binary compatibility, one reason is that you as the developer may want to change something such as a method signature but at least you can control those changes. Another reason is that the libraries and frameworks that you use to build your binary can change without your control. The third reason that we used to encounter in the old days of binary DLLs is just that things get broke and you never find out why - I remember many times when just recompiling a clean build would fix things for no obvious reason.

.NET tries to get around some of the problems by allowing the specification of not just the name of the component (I won’t call .NET components ‘binary’ in the true executable sense) but also the specific version and revision of the component. It can make things better but it is still hellish.

I believe that being able to make components using the Xojo language and the Xojo compiler is a good thing because it would provide better cross platform support and it would also allow people with ideas to produce them without getting to grips with C/C++ on three different platforms. As you state, it also allows you to break your application into pieces for cleaner development. However I would not chase that idea of being able to deploy your application in pieces. It is still very likely in the best case scenario that you would need to recompile and redeploy everything at least every time a new version/revision of Xojo arrives.

That’d be dogfooding done right. Create a framework for adding extensibility to your applications and use it to extend the IDE itself.

While I agree on this being an important feature, I don’t really think it’s even close to be a showstopper for adopting Xojo. For that the majority of developers or development would have to be focused around creating libraries instead of apps (or even instead of using said libraries).

Of course, among developers of libraries this is obviously a top showstopper, as they wouldn’t be able to even get started :slight_smile:

Again, most modern development languages allow for modular design.
Not being able to create libraries from Xojo limits your ability to encapsulate code and deliver your products, let alone allow
for folks to build components… Look, survey all the tools that Xojo competes with, they all allow for this.

I know of two cases where I recommended Xojo to someone and they decided not to go with it because they felt that
not having the ability to create a “library” was too (and I’ll quote one of them), “amateurish, like VB…”

Where I pointed out that even VB allowed for you to create a DLL!

As to Carl’s point about binary compatibility. I think thats more of a technical thing that would need to be addressed, but that
should not hold back from doing this feature… Heck, our product ships with the MBS PHP library, but it also MUST ship with
the exact PHP version that it was built with… so its not a show stopper.

Hi Gary

I agree, but the modularity does not have to be a binary one. Xojo can achieve modular design through the use of ‘Modules’ and through the use of external items. You can also arrange your project(s) with folders to achieve a ‘look’ of modularity.

  • Eduardo has mentioned library developers - I am assuming in the 3rd party sense.
  • I think it would be a great (speculative) feature for any developer to be able to create a plug-in (or IDE add-in) using Xojo and that is a kind of generalisation of Eduardo’s comment and as Eduardo implies - it can’t be a showstopper because we are not doing it at the moment.
  • Eduardo makes a very good point about dogfooding, if many of Xojo’s plug-ins were written in Xojo it would exercise any proposed Xojo Language Plug-in API and also probably introduce new features and functions that are currently now C/C++ code in plug-ins.
  • I have mentioned that delivering binary pieces of your application could be and has been troublesome technically for companies much bigger than Xojo Inc.

Maybe I don’t understand enough, could you explain exactly what additional benefits you expect to achieve from being able to make binary libraries with Xojo?

Sure, a major benefit of having RBX libraries being created out of Xojo would the ability to separate parts of the application and make it much more modular. I’ll give you an example of my product… We have a product that we sell which all the logic (engine) has to be built into the executable, and unfortunately when someone buys our product, we don’t give them access to certain functionality that they have not purchased. What would be better is to break that code out into an RBX library and simply deliver that rather than have it all built into the app. Another thing thats nice, if we fix a bug in that RBX, we only ship that RBX… not a whole installation of the app again.

Full Stop.
The IDE is NOT the language - nor is it in other languages (like C#, VB.Net, C++, Delphi etc)
Its the thing you USE to interact with the language, compile, etc.
But its entirely separate from the language.

[quote=29893:@Gary MacDougall]Not being able to create libraries from Xojo limits your ability to encapsulate code and deliver your products, let alone allow for folks to build components… Look, survey all the tools that Xojo competes with, they all allow for this.
[/quote]
There are LOTS of tools in the cross platform market.
Several do not permit you to build “libraries” - at least not DLL’s/dylibs etc that can be used by other languages.

[quote=29893:@Gary MacDougall]I know of two cases where I recommended Xojo to someone and they decided not to go with it because they felt that not having the ability to create a “library” was too (and I’ll quote one of them), “amateurish, like VB…”

Where I pointed out that even VB allowed for you to create a DLL!
[/quote]
After version 5 or so it did

[quote=29893:@Gary MacDougall]
As to Carl’s point about binary compatibility. I think thats more of a technical thing that would need to be addressed, but that
should not hold back from doing this feature… Heck, our product ships with the MBS PHP library, but it also MUST ship with
the exact PHP version that it was built with… so its not a show stopper.[/quote]
The thing making it so we’ve NOT done this (yet) really amounts to a number of technical details.
The compiler is one.
We’re rewriting that based on LLVM so there’s no point in doing it with our current compiler as that would mostly be throw away.
Its on our list of things we’d like to do but other priorities have to be tackled first.

VB specifically had issues
I recall those years saying “what version of VB did you write this in? Yeah we cant use that now as we’re on 6 and you wrote it in 4”
That was fun

[quote=29941:Norman Palardy]VB specifically had issues
I recall those years saying “what version of VB did you write this in? Yeah we cant use that now as we’re on 6 and you wrote it in 4”
That was fun[/quote]

I wanted to press ‘Like’ your post but couldn’t bring myself to ‘Liking’ those days. Back then I used to write VBXs for my clients and so I had it relatively easy, but it was horrible for them, they lost days and days with silly things like DLLRegister and all that COM and registry nastiness. I know it has got better and Microsoft preach the drag and drop installation thing nowadays with .NET but we still get some GAC weirdness, mostly when people muck about with it.

Anyways Norman, I hope you like the IDE extensions feature request which was really what this conversation was about. I can’t say it is my original idea, I have just borrowed it from other IDEs but it could bring good things to Xojo like it has for Visual Studio, Eclipse et al. I suspect you are snowed under without more feature requests but it did rank as high as 50 yesterday.

PS. A few more people putting in in ‘My Top Cases’ could get it into the top 20 if anyone thinks it is worthwhile. Scroll to the top past all of the noise if you want to see the details.

Seems a lot like <https://xojo.com/issue/11544>
In fact it sounds “the same”

This has been on the "something we’d like to do " list for a loooong time - long before I joined

RIght now the issue is you could conceivably extend the IDE with a plugin (well in theory but there’s no exposed API’s in the IDE for a plugin author to use) but they have to be done in C++
It’d be nicer to have a way to generate them in Xojo itself - but that requires implementing <https://xojo.com/issue/15140> first
And that requires, at minimum, the new compiler
Lots of dependencies :stuck_out_tongue:

I did do a search first - I promise :slight_smile: Thanks for merging I hope that merges the points too.