Ok Wayne, going with option #2 from your last email... (Sorry, another wall of text is coming!)
Pending bug patches:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=288854 (Note, i recently went to re-apply, and it had some "differences", but the ones that it didn't flag still seem valid. The patch reduces roughly ~80 ish warnings as far as I can tell)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=300017 (Applied another small patch towards this bug)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293888 (Patch good to go, I think)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293093 (Comments mention that 4 other bugs can be closed)
Also, I sent this to Dwight for my weekly update, but I'm going to re-post here too for your guys' opinion:
Here's my weekly update:
Status:
- Been trying to learn how to hide toolbars / menus. I looked at the
links you sent miles (and many other links too), but I've been
unsuccessful in getting the activity extension point to work on
different plugin contributions.
- Thus I've been also investigating if this would be better suited as
part of an RCP app tailored to our purposes. I setup an rcp app for
myself and I think it will be doable going this route as we can
override the menu managers to not accept other plugin contributions.
This is still in theory though...
- Also updated the given bug patch to add line numbers to the editor by
default. And posted another patch to fix a couple more warnings.
Next Steps:
- Continuing to try and remove / block unwanted toolbars and menu
items, most likely from an RCP app instead of inside our already
created plugins.
Roadblocks:
- Eclipse framework - The activity extension point seems to take
additional, unmentioned magic.. Wish they had better tutorials /
examples of how things work with one another.
So, do you guys have any experience with the Activity extension point? I'm unsure if it can be used for our purposes (hiding plugin contributions from other plugins). I think this may be more achievable by going the RCP route and writing some custom application code that a plugin by itself doesn't have access to.
Also, on our Friday team meeting, I had another idea for a (potential) usability improvement. Brenda summed it up pretty good from the meeting minutes, so I'm going to repost that as well:
- Cory put forward the idea of creating our own editor that pulls in
the needed functionality from the Eclipse editor, and tailoring it to
work as a simple debugger simultaneously (that is, it always debugs).
For example, if it throws an error on execution, it goes into debug
mode, much like on an uncaught exception, and of course it would stop
at breakpoints
- The idea is to make debugging useful and intuitive right from the beginning, and to have everything accessible in the editor
Thoughts? I figure if we are unable to prevent contributing plugins from adding stuff we don't want (particularly the java editor adding in the giant refactor menu), we may have a potential opportunity to write our own "simplified" debug / java editor / debug views as needed. And just pull in functionality we would like...
