I should preface what I'm about to say with this: I have done some small pull requests on a couple plugins, but my knowledge is limited to how it ties into the core system. Perhaps the answer to my question is simply "RTFM", but perhaps this is a good discussion instead.
Background:
I have many enhancements I would like to make to the Terminal tab. All of which I think would benefit the application as a whole for all users.
Question:
When does it make sense to publish a new plugin vs. develop against a branch of the main octoprint code and submit a pull request?
Also, do the internally developed UI screens utilize the same plugin architecture as 3rd party ones? In other words, if a plugin was developed, could it possibly see a future as a pull request in the main code base?
Again, if the answer is RTFM, I'll shut up and do just that
I think this depends on how deep these enhancements need to have access to the server kernel.
If these enhancements can be satisfied by the information the server hands over to the plugin API, a plugin solution may be the better way. Also as a plugin corrections and future enhancements could be done more easily.
Thank you for your response. In my case it's mostly UI enhancements (syntax highlighting, resizable terminal output, maximizable, etc). There would be a few features that would require persistence (persisting input history across browser refreshes, configurable styling of the terminal, etc), but mostly pure UI. Sounds like a plugin is probably the way to go (which is kinda what I assumed, but just figured I would ask )
Robo 3D created a fairly extensive plugin for doing an overhaul to the standard OctoPrint interface. If you're familiar with jQuery DOM manipulation, imagine that with a vengeance. It was spaghetti code, though, and nobody there could modify even small parts of it without breaking the house of cards.
That said, you could start from scratch and write a plugin to make adjustments to the interface in ways which you think make sense to you. You wouldn't have to convince foosel that any of these are the right way to do things.
But don't discount Themeify which I use all the time. It actively prevents me from the "fun" of creating new plugins like you've described because it's too good at this. Go read the Pimp my web interface thread before starting off to write one.
Honestly, I should fork Themeify and add another section in the settings for jQuery DOM manipulation (other than jQuery-based CSS manipulation). Or the author of that could.
This upgrade would then allow you to, say, clone the Temperature panel's hotend controls over to the Control tab, which would be pretty handy.
If the majority of your improvements are UI enhancements to the core system you may want to consider developing a plugin utilizing the UIPlugin mixin. You could start out by cloning the existing viewmodels and then manipulate as desired. I haven't yet really seen a fully flushed out plugin utilizing this mixin yet, but seems to be definitely the best approach for a complete skinning. I'm actually surprised that @BillyBlaze hasn't taken this approach with TouchUI yet. Probably like me though, there's not enough hours in the day with a full time job, etc.
One of the reasons why I created the plugin interface was actually to allow people to add stuff to OctoPrint without me now having to maintain it on top of everything else
My general rule of thumb regarding core feature vs plugin can also be found as the first point in the Contribution Guidelines for PRs:
If you want to add a new feature to OctoPrint, please always first consider if it wouldn't be better suited for a plugin. As a general rule of thumb, any feature that is only of interest to a small sub group should be moved into a plugin. If the current plugin system doesn't allow you to implement your feature as a plugin, create a "Brainstorming" ticket to get the discussion going on how best to solve this in OctoPrint's plugin system - maybe that's the actual PR you have been waiting for to contribute
