I’m considering using Komodo as the basis for a markdown authoring IDE, but I’m wondering how Activestate plans to handle the planned deprecation of XPCOM and XUL in about a year. Is Komodo still a viable platform with that around the bend?
First keep in mind that even with the deprecation of XUL it’s still a viable platform for the next few years, issues will only start to arise when OSes/technologies evolve in a way that would require XUL to be similarly updated.
Rest assured that we have been aware of the XUL issue for a while and are already working to address it. I can’t yet go into detail on what this means exactly but in regards to your concerns; as long as you use the new commonjs type modules and abstract your code properly you should not have too many issues staying compatible with future updates. Also keep in mind that you can use HTML for your UI, you do not “have” to use XUL.
Please feel free to contact me directly if you want to discuss your project and Komodo’s participation in it more directly: nathanr@activestate.com
1 Like
I had a thread on this somewhere, that was right before they did their entire signed extensions and official deprecation of XUL thing.
But like I said in that other thread (I think?) Activestate’s decision to use plain ol’ JS and commonjs modules is a far better long-term strategy than … let’s go with “some other popular tools” extensibility story.
re HTML as UI, Isn’t everything just wrapped in XUL though?
Depends, you can use HTML straight from within XUL, which has some caveats. But you could also use a browser element which then loads a HTML document which shouldn’t have any caveats.
I’m using the latter solution (browser element) for a few upcoming features. You can’t tell the difference from an end-user perspective.
Except I want to provide new views – a specific project view e.g. which allows for file-reordering. For this I’d have to do more than just provide a self-contained view, right? The way I’d typically do this is using an XUL overlay. Is there already plumbing in place to do such things inside Komodo that doesn’t rely on XUL? My time is unfortunately rather limited, so if I’m going to do this I’d rather do it using the new technology straight away.
Could you explain what you mean by a “view”?
The underlying plumbing is being developed still, XUL overlays aren’t a bad idea, we have tons of them ourselves and the new foundation will need to support them in some way, shape or form.
But I would suggest you use ko/dom where possible.
Ah, sorry: with “view” I meant something like the collapsible hierarchies in the left sidebar. Perhaps just a customized project, but one where I could affect the file ordering.
From what is being said about it, XUL (and certainly overlays) as developed by Mozilla would not be supported in any way, shape or form, and this includes xulrunner, which I thought Komodo used as a basis (right?). If Komodo is going to keep xulrunner going, that would be great for me, but whether that’s a sound long-term strategy I don’t know.
Can I do things like adding new sidebar panels using ko/dom? Is this technology already in Komodo (I see the docs are labelled “beta”)?
It’s the current status for the docs, not for the Komodo features/SDK/etc. Komodo developers and me are still working on the docs, that’s why you see beta label for it 
ko/dom works like a popular JS framework called jQuery, so you can easily add new sidebar panes using this module.
Note the docs are open to anyone to contribute, its not just us “and Defman”; it’s anyone willing to contribute.
1 Like
Interesting – any code samples using that SDK? If substantial Komodo extensions can be built using an SDK that isn’t affected by XUL/XPCOM going, that changes things of course (although I did like XUL I must say).
ko/dom is largely compatible with the API of jquery. You’re still basically writing XUL but since you are doing it from your code it will be more future-proof. Note this is not a good solution if you are writing large amounts of UI, it’s only really good for modular approaches.
I am 99% confident we’ll be using HTML5 in the future, and we’ll implement it in such a way that it will support many XUL structures, such as hbox, vbox, menulist, etc. So I would recommend you to just use XUL, but be mindful of what you do with it. eg. advanced XUL stuff like tree’s likely won’t be ported, but you probably don’t want to be using those regardless.