Future of Xojo Plugins

So I was just reading through the latest xDev publication; very nicely done and an interesting read.

I was mostly interested in reading about future direction and developments in Xojo, and one thing hit me as soon as I set eyes on it:

The ability to write Xojo plugins from within Xojo itself.

This sounds like an absolutely brilliant idea. I have many parts of code that would be ideally suited to being part of a plugin, but almost cringed when I first looked into what is needed to write a plugin currently. This will make it so much easier to manage my own code libraries, keep them available as plugins and always available at design time for multiple projects.

Developments like this are the kind that will keep me using Xojo long term. It has gotten me quite excited.

:slight_smile:

[quote=188136:@Stephen Thomas]The ability to write Xojo plugins from within Xojo itself.

This sounds like an absolutely brilliant idea. I have many parts of code that would be ideally suited to being part of a plugin, but almost cringed when I first looked into what is needed to write a plugin currently. This will make it so much easier to manage my own code libraries, keep them available as plugins and always available at design time for multiple projects.[/quote]

This will no doubt be fantastic. Plugins allow more than encrypted classes, and this will compensate for the impossibility to create DLLs.

I would also like the ability to write editors for classes in the IDE directly.
you couls make a class and then use your own editor instead of the crappy property window with only text field and checkbox
(not even a popup menu with variable values inside)
I used this feature a long time ago with the prograph programming ide, this feature was fantastic.

[quote=188165:@jean-yves pochez]I would also like the ability to write editors for classes in the IDE directly.
you couls make a class and then use your own editor instead of the crappy property window with only text field and checkbox
(not even a popup menu with variable values inside)
I used this feature a long time ago with the prograph programming ide, this feature was fantastic.[/quote]

That I would love as well. in my latest class I have to use the regular variables editor, when it would be a lot better if I could use a custom one. I looked into using a script, but there is simply no way.

This new feature sounds more like a way to wrap some classes, windows, modules in a single file, so you can drop that in another project.

For people who code mainly in Xojo like me, and pending more details about the Xojo coded plugins, I am looking forward to be able to have custom icons in the Library, or a better representation of custom controls in the layout editor. Also, it is nice to see Xojo eat its own cooking, as it where, instead of requiring the alien C language.

When it is just wrapping up code, it will just be another way to do it by having code spread over separate files loaded in memory at once. Result is the same. Think the plugins as we have now will perform better. Some technical things should not be written in a R.A.D. tool, but just in XCODE./C++, is my opinion.

In VB, I can chose to create DLLs in C, VB or anything else depending on the performances needed. It will be nice to have the choice in Xojo. And if indeed the power of C is needed, as far as I understand, it will still be possible. The best of both worlds :slight_smile:

Using this feature for reusable code libraries for internal use actually hadn’t occurred to me. I’d like to set your expectations in advance and note that you won’t be able to step into the plugin code while using it in a project, since the original source code isn’t present (the plugin contains precompiled code).

Except that the code is precompiled and the plugin can include all of the resources that it needs. This includes shared libraries if the plugin has portions written in C that it needs to declare into.

Yep, I know what you are saying. Stepping into the raw code of a plugin is not what I am that interested in; I can kinda do that anyway using correctly setup modules and the like.

I was mainly referring to building my own plugins, which will contain methods I use in multiple projects, without having to have all the code in the IDE during coding. I’m thinking more along the .dll approach. My own custom code is available to me to call, but is already tested, compiled and tucked away neatly in a library/plugin.

To give an example, I have a couple of geo modules that I use here; they do relatively simple things like converting between different types of co-ordinate systems, calculate straight lines distances between 2 sets of co-ordinates, and will soon provide a complete routing solution.

Whilst the routing database itself will need a refresh from time to time, the underlying code to all of these functions will rarely if ever change. The calculations are all well known and proven to work. It would be great to arrange them all in a plugin, compiled and tested, and then just make the necessary calls to use those methods. Once I know everything in the plugins work 100%, I prefer NOT to have the code available in the IDE unless I specifically load it. Theres just no need and it lets me concentrate more on the actual coding Im working on at the time.

When you consider how the plugins work today; you drop them into the plugins folder then simply make your calls to use them, its a super idea that works very well. Being able to make my own will make it even better.

I have to say also, that I have a new found respect for the folks who produce and manage plugins today. It looks to me like you pretty much need to know/learn almost an entirely new language just to do that, which is not something I relish. In fact, its part of the reason I started using Xojo to begin with. An easy to use and understand high level language that compiles to a native app.

I like that plugins will be bale to be written in Xojo itself, but in the new format will plugins be created that don’t use Xojo code?

While I would not create such plugins I agree with Joost Rongen that:

Each language has it’s strengths and weaknesses and plugins are a way to deal with Xojo’s weaknesses.

  • Karen

[quote=188259:@Karen Atkocius]I like that plugins will be bale to be written in Xojo itself, but in the new format will plugins be created that don’t use Xojo code?
While I would not create such plugins I agree with Joost Rongen that:
Some technical things should not be written in a R.A.D. tool, but just in XCODE./C++, is my opinion.
Each language has it’s strengths and weaknesses and plugins are a way to deal with Xojo’s weaknesses.[/quote]

Indeed plugins are a way to deal with Xojo weaknesses by providing a prepackaged alternative to declares. But they could also provide a better way to distribute custom classes, by providing a much better package. At this moment, non subclassed custom controls in the IDE layout editor usually look like dull rectangles, not really like nice controls. If I understand right, plugins can have their own design for the layout editor, just like native controls. They can also have their own icon in the Library. That is a case where the advantage is not necessarily execution time, but aesthetics.

Also, it seems Xojo made plugins will like C ones today be self-contained, encompassing the libraries they need. That should be better than the encrypted classes.

Most importantly, that is just one more choice.

Last but not least, they will be available for iOS !

Hi Joe.

One of the r3 features that was blogged about during the keynote was the ability to write C code directly within Xojo.

Is that correct or was it a misunderstanding of another feature?

Kev.

Certainly there is no C compiler included for Xojo roadmap.

Just looking at a quote from Joe in the XDC2015 Open Conversation Day 1 thread:
“You’ll be able to write code in Obj-C/C/C++ and include it in the plugin, which is something you can’t do now.”

This gave me the impression that it would be possible to add C code directly, even if it was just when creating plug-ins.

[quote=188165:@jean-yves pochez]I would also like the ability to write editors for classes in the IDE directly.
you couls make a class and then use your own editor instead of the crappy property window with only text field and checkbox
(not even a popup menu with variable values inside)
I used this feature a long time ago with the prograph programming ide, this feature was fantastic.[/quote]
Just FYI, you can create popup menus in the inspector. Right-click on a class in the navigator and select Inspector Behavior. On the right of the dialog is an editor for popup menus.

I think what they told is that we can include a dynamic (maybe even static?) library in the library we create in Xojo.

[quote=188165:@jean-yves pochez]I would also like the ability to write editors for classes in the IDE directly.
you couls make a class and then use your own editor instead of the crappy property window with only text field and checkbox
(not even a popup menu with variable values inside)
I used this feature a long time ago with the prograph programming ide, this feature was fantastic.[/quote]
Just to be clear this announcement doesn’t make it possible to write plugins FOR the IDE

Apologies for not replying to each of you individually, but I think a more general explanation will be more useful. Also, the details may change before release.

A plugin will be a container, likely a zip file, that contains several things:

  • a manifest file that describes the files in the plugin
  • a file that tells the IDE what functions and classes exist in the plugin
  • the precompiled code from the project
  • any resources the plugin may need
  • any shared libraries the plugin declares into, which allows portions of the plugin to be written in C/C++/Objective-C

The initial version may or may not provide support for Canvas-based controls to draw themselves into the form editor. It’s an obvious extension of the feature and will likely happen at some point. There are no plans to allow plugins to extend the IDE.

The portability of plugins between Xojo versions is currently up in the air. It’s a technical problem that can probably be solved, but the only promise right now is that you’ll be able to deploy a plugin to the same major version of Xojo it was compiled with.