Community
Participate
Working Groups
As a follow up to bug #326975, Workspace mechanic [1] should be added to EPP. [1] https://code.google.com/a/eclipselabs.org/p/workspacemechanic/
+1 How do you want to do this? Do we treat it as a third-party library and open a CQ? Or do we fork/move it into an EPP subproject? I think that we've discussed creating an "IDE Features" subproject where things like this and the image utilities (for example) from the Examples project can live. Are any package maintainers interested in including this feature?
Wayne, I guess it depends on the Workspace Mechanic project and if it's even interested in becoming an EF project or rather prefers to stay independent at its current location. IMO it's best if WM becomes a project under the EF technology top-level project. Otherwise we end up filing CQs every quarter.
Btw. the reason I selected the rcp-package component is because there does not seem to be an umbrella component. Ideally all packages would include WM.
(In reply to Markus Kuppe from comment #3) > Btw. the reason I selected the rcp-package component is because there does > not seem to be an umbrella component. Ideally all packages would include WM. Package content is _mostly_ a decision made by package maintainers. While I agree that requiring that packages include the MPC is a good idea, I'm not convinced that we should force inclusion of the Mechanic. I do quite like the idea of creating a single "Goodies" project that contains utilities like this.
According to Alex Blewitt [1] WM has been retired. What about reviving the project at EF? [1] https://twitter.com/alblue/statuses/400380336779325440
(In reply to Markus Kuppe from comment #5) > According to Alex Blewitt [1] WM has been retired. What about reviving the > project at EF? +1 But where? I believe that there is interest from the project developers in moving the project to Eclipse, but concern over process overhead. As stated earlier, I'd like to explore creating an "IDE Goodies" project as a subproject of EPP. If nobody else wants to step up, then I can take care of project management duties. My reasoning is that I believe that there is a handful of similar relatively small "goodies" (like the image viewer), that will all be developed and released on the same schedule (and so will benefit from shared builds, update sites, downloads, etc.). Further, I think that these goodies will all fall end up being sorts of "commons" features that will likely not get regular attention or significant contributions (though I do hope to be pleasantly surprised). Creating this sort of project is contingent on there being actual interest in using the components created by the project in EPP packages; and coming up with a reasonable scope for such a project. I'd also likely bake something into the scope that states that features that are not kept up-to-date with the latest versions of Platform will be retired/archived. Thoughts?
(In reply to Wayne Beaton from comment #6) > My reasoning is that I believe that there is a handful of similar relatively > small "goodies" (like the image viewer), Great idea. You mean stuff like: Easy Shell http://marketplace.eclipse.org/content/easyshell jadclipse http://marketplace.eclipse.org/content/jadclipse It could be a good incubation arena for new committers.
Please, lets not turn this bug into an everything but the kitchen sink but create new bugs instead. Otherwise I fear that we will never get WM into EPP. Right now it seems to me that the WM project (Robert Konigsberg) waits for somebody official (Wayne probably qualifies) to approach him WRT inclusion in Eclipse.
(In reply to Wim Jongman from comment #7) > You mean stuff like: > > Easy Shell http://marketplace.eclipse.org/content/easyshell > jadclipse http://marketplace.eclipse.org/content/jadclipse Sure. Stuff like that. Except not that particular stuff. Easy Shell is LGPL and Jadclipse requires Jad which is "Free for non-commercial use"-licensed (not, I believe, compatible with the EPL). It might be cool to try and see if Easy Shell wants to move to this new project (and is able to change the license). > It could be a good incubation arena for new committers. Agreed. Maybe (I'm skeptical that this sort of project will attract significant contribution). (In reply to Markus Kuppe from comment #8) > Please, lets not turn this bug into an everything but the kitchen sink but > create new bugs instead. Agreed. > Otherwise I fear that we will never get WM into EPP. There are still some open questions: * Where does this go? * Do any of the packages really intend to use it? I see no value in pursuing this if none of the packages maintainers intend to make use of it. I'll start a thread in the EPP dev list to see if anybody cares. > Right now it seems to me that the WM project (Robert Konigsberg) waits for > somebody official (Wayne probably qualifies) to approach him WRT inclusion > in Eclipse. Robert is copied on this bug. Robert, do you agree to moving the code into an Eclipse project (to be named later). Will you be able to dedicate any development resources into maintaining the code? Assume for now that somebody else will be responsible for Eclipse project management overhead. If we are in agreement that starting a new project to hold stuff like this is the right way to go, I'll open a separate bug to start that process.
I'm glad there's more interest than there was in the other bug. I'll be happy to have a conversation about this, and even consider various levels of involvement, but could someone be willing to have a conversation not via bug tracking tool? Hmm, let's see ... my basic concerns are: 1. conflict with existing install base, which at the very least is virtually all Eclipse users at Google 2. what work is required by whom, including both me and other folks, 3. what's your plan for WM? Is it just to provide this feature, or expand it some? For instance, we've got something built in for specifying keyboard shortcuts (via JSON format.) Does that remain? 3a. Is there an interest in adding some of the more interesting feature requests, such as supporting using WM for perspectives, and JDT compiler and formatter options? 3b. There's an open bug list, has there been any consideration about some of the rough edges in WM, like tasks that take too long, et cetera.
-1 on "IDE Goodies" project +1 on WM at Eclipse as a separate project and in EPP packages, if there is someone willing to maintain it I am rather tickled to see Wayne proposing a project for a kitchen sink of small pieces that don't belong somewhere else, when not that long ago, he was arguing pretty hard against a very similar idea that I was pushing... Nexus. I would much rather see energy expended on improving our process and infrastructure so that we lessen overhead on micro-projects to be competitive with other OSS hosts, than implementing workarounds such as Nexus or IDE Goodies.
(In reply to Konstantin Komissarchik from comment #11) > I am rather tickled to see Wayne proposing a project for a kitchen sink of > small pieces that don't belong somewhere else, when not that long ago, he > was arguing pretty hard against a very similar idea that I was pushing... > Nexus. I think that there are some differences, between what I'm proposing and Nexus (which we need to be careful to not confuse with the Sonatype Nexus). For one, I'm suggesting a restricted domain. Regardless, you may be further tickled to know that I thought specifically of you as I was first proposing the idea. I've taken a few minutes to clone the repository and better understand the nature of Workspace Mechanic. I also took a closer look at the PDE Tools [1] as a candidate for inclusion. I'm less convinced of the "kitchen sink" project now as both of these code bases are pretty significant. I was originally thinking of them in terms of the "Image Utilities" bits from the Example project which are really very small utilities that require very little care and feeding. > I would much rather see energy expended on improving our process and > infrastructure so that we lessen overhead on micro-projects to be > competitive with other OSS hosts, than implementing workarounds such as > Nexus or IDE Goodies. The Architecture Council has been engaged in a reworking of the EDP over the last few months. There's been plenty of opportunity to weigh in on the sorts of changes that we can make to make smaller scale projects more viable. I recommend that you take that discussion there. [1] http://marketplace.eclipse.org/content/pde-tools
(In reply to Robert Konigsberg from comment #10) > I'm glad there's more interest than there was in the other bug. > > I'll be happy to have a conversation about this, and even consider various > levels of involvement, but could someone be willing to have a conversation > not via bug tracking tool? We can schedule a call if there's interest. > Hmm, let's see ... my basic concerns are: 1. conflict with existing install > base, which at the very least is virtually all Eclipse users at Google As part of the move, we'd have to change the bundle and package namespace. I'm not sure if this helps or hurts (hurts, I suspect). > 2. > what work is required by whom, including both me and other folks, That's the kicker. Somebody needs to own this, and developers need to step up to work on it. It doesn't need to be you, but it does need to be a small group of folks who are keen to sponsor the move into an Eclipse project. You can be involved with this as much or as little as you'd like. But it's not going to happen unless somebody steps up. I can help with the process bits and am interested in contributing. > 3. what's > your plan for WM? Is it just to provide this feature, or expand it some? That's really up to the people involved. I have the same answer for the rest of the questions. The keyboard shortcuts feature doesn't seem related to the central purpose (scope) of WM. Eclipse projects are required to stay within a well-defined scope (which actually makes the "kitchen sink" project idea a bit challenging; but not impossible). > For > instance, we've got something built in for specifying keyboard shortcuts > (via JSON format.) Does that remain? 3a. Is there an interest in adding some > of the more interesting feature requests, such as supporting using WM for > perspectives, and JDT compiler and formatter options? 3b. There's an open > bug list, has there been any consideration about some of the rough edges in > WM, like tasks that take too long, et cetera.
(In reply to Wayne Beaton from comment #13) > > 2. > > what work is required by whom, including both me and other folks, > > That's the kicker. Somebody needs to own this, and developers need to step > up to work on it. It doesn't need to be you, but it does need to be a small > group of folks who are keen to sponsor the move into an Eclipse project. You > can be involved with this as much or as little as you'd like. But it's not > going to happen unless somebody steps up. I can help with the process bits > and am interested in contributing. From my daily use of WM I find it pretty much feature complete. Thus, we would do with a maintainer than a large group of developers who build new features. Initially though work would be required to set up a build, contribute it to the simrel repository... BTW. does anybody think we can do this for Luna already?
+1 for WM as it is to be included by default ASAP. Both all our developers as our customers complain about the missing functionality to share/enforce workspace settings. In the lab we use it since ~2 years, and it is nearly perfect. Regarding inclusion of other "useful"/missing essential plugins - is there an "umbrella" bug somewhere?
(In reply to Andrey Loskutov from comment #15) > Regarding inclusion of other "useful"/missing essential plugins - is there > an "umbrella" bug somewhere? It hasn't been created yet.
(In reply to Wayne Beaton from comment #9) > * Do any of the packages really intend to use it? > > I see no value in pursuing this if none of the packages maintainers intend > to make use of it. I'll start a thread in the EPP dev list to see if anybody > cares. I think that WM would be a great addition to the packages! My only concern right now is that it doesn't have an active developer community any more. My other concern is that I haven't used it myself, but from what I've read and what I've heard from others it seems to solve one of the pain points that users face today.
(In reply to Markus Knauer from comment #17) > I think that WM would be a great addition to the packages! So, in your opinion, is this something that needs to go into all packages, or do we leave it to the individual package maintainers to decide?
(In reply to Wayne Beaton from comment #18) > So, in your opinion, is this something that needs to go into all packages, > or do we leave it to the individual package maintainers to decide? Since this is not something that's specific to some technology you use Eclipse for (Java, C, web, embedded, etc.), but to Eclipse itself, I think it would be very useful if it was included in all packages. This would be a much better foundation for sharing preferences profiles.
(In reply to Wayne Beaton from comment #18) > (In reply to Markus Knauer from comment #17) > > I think that WM would be a great addition to the packages! > > So, in your opinion, is this something that needs to go into all packages, > or do we leave it to the individual package maintainers to decide? Since you are asking for my opinion, yes, I think it would make sense in all our packages, but we should ask the package maintainers if there are any concerns. If the concerns are not too big, it could go in our common EPP feature that provides 'common' dependencies (e.g. the MPC). The size of WM isn't a reason not to include it in all packages. It's currently a single bundle (~2MB) but it could help to 'externalize' the jar files that are included in the bundle right now (guava+gson). Without these libraries the bundle itself could be stripped down to ~50kB. Other than that it doesn't have any exotic dependencies.
I would like to understand which aspects of Workspace Mechanics people are interested in using. If it is mostly application of preferences, then I would think adding WM is a bit overkill. Instead we could either use a trimmed down approach of the plugin or use Ericsson's plugin https://bugs.eclipse.org/bugs/show_bug.cgi?id=334016.
(In reply to Pascal Rapicault from comment #21) > I would like to understand which aspects of Workspace Mechanics people are > interested in using. Some specific points I like about WM: - recording: I don't have to know any internal preference keys, but changes done using the normal preference pages can be recorded into a file. This makes selective export of some preferences very easy. - changes of shared preferences are not forced on me but I can selectively accept/reject any incoming changes. By defining a custom description for any set of settings recorded in step one, the author of shared preferences can help other users to make an informed decision.
(In reply to Stephan Herrmann from comment #22) > (In reply to Pascal Rapicault from comment #21) > > I would like to understand which aspects of Workspace Mechanics people are > > interested in using. > > Some specific points I like about WM: > > - recording: I don't have to know any internal preference keys, but changes > done using the normal preference pages can be recorded into a file. > This makes selective export of some preferences very easy. > > - changes of shared preferences are not forced on me but I can selectively > accept/reject any incoming changes. By defining a custom description for > any set of settings recorded in step one, the author of shared preferences > can help other users to make an informed decision. It's similar for me. I'm an individual developer and not working in a large team and thus manage my preferences myself. Pref recording and selectively applying subsets to workspacse is exactly what I use. IMO this is also what most consumers of EPP want. Larger (inhouse) teams build a customized EPP anyway and then can easily add e.g. Ericsson's plugin to manage preferences centralized.
(In reply to Wayne Beaton from comment #13) > > 2. > > what work is required by whom, including both me and other folks, > > That's the kicker. Somebody needs to own this, and developers need to step > up to work on it. It doesn't need to be you, but it does need to be a small > group of folks who are keen to sponsor the move into an Eclipse project. You > can be involved with this as much or as little as you'd like. But it's not > going to happen unless somebody steps up. I can help with the process bits > and am interested in contributing. Why not make the current bug subscribers be the initial set of committers (+ the existing code.google.com project members)? To me, it seems this would be enough manpower to move the project to EF, change the pkg namespace, setup a build and have it contributed to simrel.
(In reply to Markus Kuppe from comment #24) > Why not make the current bug subscribers be the initial set of committers (+ > the existing code.google.com project members)? Sounds like a good starting point. Who wants to create the project proposal? https://wiki.eclipse.org/Development_Resources/HOWTO/Starting_A_New_Project
(In reply to Wayne Beaton from comment #25) > Sounds like a good starting point. Who wants to create the project proposal? > > https://wiki.eclipse.org/Development_Resources/HOWTO/Starting_A_New_Project Looking at the wiki it appears as if the time frame to start a new project is going to delay us until after Luna. If this assumption is correct, what about pushing the current version of WM into Orbit and include that in Luna. The IP review for the real project will then be based on the Orbit review (no extra work).
(In reply to Markus Kuppe from comment #26) > Looking at the wiki it appears as if the time frame to start a new project > is going to delay us until after Luna. If we started today, the best we could hope for is to have a project up and running in about four weeks (the community review period must last a minimum of two weeks, the trademark review/assignment will take a while, followed by a week-long creation review). You'd have to add the IP review of the code on top of that. We've done more aggressive things (e.g. WindowBuilder) > If this assumption is correct, what > about pushing the current version of WM into Orbit and include that in Luna. > The IP review for the real project will then be based on the Orbit review > (no extra work). That makes sense to me.
(In reply to Wayne Beaton from comment #27) > > If this assumption is correct, what > > about pushing the current version of WM into Orbit and include that in Luna. > > The IP review for the real project will then be based on the Orbit review > > (no extra work). > > That makes sense to me. bug #422182
(In reply to Markus Kuppe from comment #28) > bug #422182 The Orbit project may correct me, but I believe that the process is to first introduce the third party library into an owner project and then move it to Orbit. So, you'll likely be told to move the bug to EPP. I'm concerned that AFAICT, no package maintainers have weighed in on this. Does silence imply approval?
(In reply to Wayne Beaton from comment #29) > (In reply to Markus Kuppe from comment #28) > > bug #422182 > > The Orbit project may correct me, but I believe that the process is to first > introduce the third party library into an owner project and then move it to > Orbit. So, you'll likely be told to move the bug to EPP. Well, this is the corresponding EPP bug, isn't it? > I'm concerned that AFAICT, no package maintainers have weighed in on this. > Does silence imply approval? I kind of assumed Markus' (comment #17) is a package maintainer.
(In reply to Markus Kuppe from comment #30) > Well, this is the corresponding EPP bug, isn't it? Sure. But that's not what I meant :-) http://wiki.eclipse.org/Adding_Bundles_to_Orbit > I kind of assumed Markus' (comment #17) is a package maintainer. Yes and no. Markus owns the process and is gracious enough to take responsibility for the overall build of packages. But the package definitions themselves are owned by individual package maintainers. Maintainers also do things like test and certify the packages once they're built. I have no problem with deciding that WM belongs in all packages, but hesitate to do so without acceptance from the package maintainers. I believe that many of the package maintainers are being copied on this bug. What's holding up the package maintainers from weighing in? Maybe it's time to try connecting on the mailing list again.
Just to throw in a thought on where I see the potential of mechanic at Eclipse: we enable recording by default, and when a user has changed some preferences, we ask if she wants to share her custom settings. We could make these shared setting profiles available on the marketplace, and by starring them, we get something like community charts for settings. At the same time, we get very useful, continuous, up-to-date usage info, which we could use to manage our defaults (as currently discussed on ide-dev). That would require some integration on different levels, but I have the feeling that this could really help us with some fundamental issues. It could basically be a way to take our users' pulse, as Doug Schaefer put it [1]. But merely getting mechanic into the packages, I'm not sure if that makes such a big difference. So adding it to Luna via Orbit seems a little rushed to me, in particular if the plan is to make it an eclipse.org project anyway. [1] https://twitter.com/dougschaefer/status/402483144755929088
(In reply to Wayne Beaton from comment #29) > > I'm concerned that AFAICT, no package maintainers have weighed in on this. > Does silence imply approval? The silence might mean they 1) don't care or 2) don't understand the implications of Workspace Mechanic. Most package maintainers are engaged with EPP to support their specific package requirements. They test each release but I would suggest the testing is very high level so none of them will actually test at the WM level. When we added MPC to all the packages the implication was that this was a feature that would not impact the overall package. It was almost like the Platform adding a new feature. If WM is similar idea, where it is a feature that doesn't impact the overall package then I think the package maintainers won't care. If it impacts an individual package then I think you need to explain how and the impact.
(In reply to Fabian Steeg from comment #32) > But merely getting mechanic into the packages, I'm not sure if that > makes such a big difference. So adding it to Luna via Orbit seems a little > rushed to me, in particular if the plan is to make it an eclipse.org project > anyway. My fear is that if we do not get this into Luna, that IDE users will see this feature with the 2015 release earliest (due to the long release cycle of the IDE).
(In reply to Ian Skerrett from comment #33) > The silence might mean they 1) don't care or 2) don't understand the > implications of Workspace Mechanic. I'll admit that my question was a bit loaded. I'm inclined to think that it's #2. > Most package maintainers are engaged > with EPP to support their specific package requirements. They test each > release but I would suggest the testing is very high level so none of them > will actually test at the WM level. Understood. But they will need to test with WM present; that that may have unintended side effects. I'm not saying that it will. I don't know what to expect (which is at least part of the point of testing). > When we added MPC to all the packages the implication was that this was a > feature that would not impact the overall package. It was almost like the > Platform adding a new feature. I agree. > If WM is similar idea, where it is a feature > that doesn't impact the overall package then I think the package maintainers > won't care. If it impacts an individual package then I think you need to > explain how and the impact. I don't know what the impact is. Somebody needs to take ownership of understanding completely what the impact will be and explaining it to the rest of us. Has anybody actually installed and tested this on any of the Kepler SR1 packages?
(In reply to Wayne Beaton from comment #35) > Has anybody actually installed and tested this on any of the Kepler SR1 > packages? Not on Kepler SR1, but on Voclipse [1] (an inofficially packaged IDE) based on Luna M3. Works fine and I'm using it daily. M. [1] http://download.vogella.com/p2/M-MASTER-voclipse/builds/lastSuccessfulBuild/archive/
(In reply to Wayne Beaton from comment #35) > > > Most package maintainers are engaged > > with EPP to support their specific package requirements. They test each > > release but I would suggest the testing is very high level so none of them > > will actually test at the WM level. > > Understood. But they will need to test with WM present; that that may have > unintended side effects. I'm not saying that it will. I don't know what to > expect (which is at least part of the point of testing). I am not sure if this is reasonable to expect from the package maintainers. They are not WM experts or users and I doubt they have any motivation. If you want to add WM to all EPP packages then I think the WM committers need to ensure it doesn't impact the packages. Just like we did with MPC.
(In reply to Ian Skerrett from comment #37) > I am not sure if this is reasonable to expect from the package maintainers. > They are not WM experts or users and I doubt they have any motivation. If > you want to add WM to all EPP packages then I think the WM committers need > to ensure it doesn't impact the packages. Just like we did with MPC. Well, we can politely ask them to do it, can't we? ;-) After all all packages benefit from extra functionality. Anyway, can you outline what work has been done to test MPC on all packages? Is there a test suite of some sort?
(In reply to Markus Kuppe from comment #38) > (In reply to Ian Skerrett from comment #37) > > I am not sure if this is reasonable to expect from the package maintainers. > > They are not WM experts or users and I doubt they have any motivation. If > > you want to add WM to all EPP packages then I think the WM committers need > > to ensure it doesn't impact the packages. Just like we did with MPC. > > Well, we can politely ask them to do it, can't we? ;-) After all all > packages benefit from extra functionality. > Most certainly you can politely ask them. In fact I think Wayne has been very polite in his requests for help from the package maintainers. I am just pointing out why there has been silence to the request. > Anyway, can you outline what work has been done to test MPC on all packages? > Is there a test suite of some sort? My point is that we did not test in all the packages. They assumption, proven correct, was that it did not impact the packages. The power of a modular design make it possible. :-)
I think the features provided by Workspace Mechanic could be a very good addition to the Modeling package (and probably all the other packages) But I did not commented here yet because I really need to have a deep look at it before, making sure it does not impact things like performances or that its UI profile is low enough. It is on my TODO list now though. I (and maybe others) have been silent so far not because I don't care, but because I need to use Workspace Mechanic for some time to make a decision.
(In reply to Markus Kuppe from comment #30) > > I'm concerned that AFAICT, no package maintainers have weighed in on this. > > Does silence imply approval? > > I kind of assumed Markus' (comment #17) is a package maintainer. Yes, I am one of them, but I can speak only for the RCP/RAP package. And I feel like Cedric here: First, we need to get some experience with it. (In reply to Wayne Beaton from comment #31) > I have no problem with deciding that WM belongs in all packages, but > hesitate to do so without acceptance from the package maintainers. When I wrote that it may be good to have WM in all packages, I don't think we should enforce this like we did with MPC. To me, MPC is different, because it provides access to a central eclipse.org service, i.e. the Marketplace. To decide that WM belongs in all packages sound a bit like adding a special XML editor to all packages to me. (In reply to Wayne Beaton from comment #27) > > If this assumption is correct, what > > about pushing the current version of WM into Orbit and include that in Luna. > > The IP review for the real project will then be based on the Orbit review > > (no extra work). > > That makes sense to me. I have to say that this is a very smart idea, but at the same time I disagree. Orbit should be used for 3rd party libraries that are to be used in multiple Eclipse projects. IMO WM should only be part of any Eclipse download if it has its own org.eclipse... namespace and is provided by a real Eclipse project in some way.
(In reply to Markus Knauer from comment #41) > I have to say that this is a very smart idea, but at the same time I > disagree. Orbit should be used for 3rd party libraries that are to be used > in multiple Eclipse projects. IMO WM should only be part of any Eclipse > download if it has its own org.eclipse... namespace and is provided by a > real Eclipse project in some way. So consensus it that we won't be pushing this for Luna and only pursue a WB integration long term?
FWIW: I'm sharing my personal prefs on github [1] in case somebody finds them useful. Btw. long term I could envision an upload & rating mechanism for prefs hosted at eclipse.org + a spice of gamification. Puts an end to votes about line numbers too. ;-) [1] https://github.com/lemmy/myWorkspaceMechanics
(In reply to Markus Kuppe from comment #43) > FWIW: I'm sharing my personal prefs on github [1] in case somebody finds > them useful. Any chance you could put a license on that repo? Preferably EPL.
(In reply to Mike Milinkovich from comment #44) > Any chance you could put a license on that repo? Preferably EPL. Done, it's now public domain.
Hi everyone, It's great there's so much conversation around this. Let me follow up with some more thoughts on the matter. I'm splitting this response into sections so you can focus on the things you care about. PROCESS Wayne was right in Comment 6 that the process overhead was the thing that kept me from being interested in making this part of the platform. I'd heard stories about moving projects to eclipse.org that made the whole thing seem not worthwhile. My _primary_ goal was to ensure the Workspace Mechanic worked for Google employees first, then the open source community second. I could manage those two things, but more than that was not particularly palatable. OWNERSHIP I'd love to be able to own such a project -- several years ago the idea of getting WME into eclipse.org would have been really exciting. Unfortunately, I've moved on to other things that don't involve IDE work, and it would be unfair to take on such a responsibility. CENTRAL PURPOSE I'm not assuming that you want "The Workspace Mechanic" but don't forget that the Workspace Mechanic does more than preferences, otherwise we might have called it "The Preferences Mechanic." :) Keeping that in mind may help shape what you want to include or exclude from the embedded offering. In comment 13, Wayne said: > The keyboard shortcuts feature doesn't seem related to the central purpose > (scope) of WM. Eclipse projects are required to stay within a well-defined > scope (which actually makes the "kitchen sink" project idea a bit challenging; > but not impossible). The keyboard shortcuts _absolutely_ demonstrate the central purpose of the WM in action. Keyboard shortcuts are ways in which your workspace can be customized. Preferences are the most common need, and also the easiest to implement, but everyone has their own important customizations they would like. The person who wanted keyboard shortcuts to work put in the effort to write it (although we did much of the work together as pair programmers), and since I respected his technical skill, and he wrote tests, it was a natural thing to include. Keyboard shortcuts also exemplifies the work required for non-preference workspace customizations. To write it we had to * Understand the underlying API, finding the weird corner cases (figuring out how keyboard shortcuts worked was _not_ simple [documentation, gah]) * Determining how to represent those as outside the API. (We chose JSON as the modern day way to loosely structure data and defined a specification that made one-off mutations.) HOW THE CENTRAL PURPOSE SHOULD BE EXPANDED This is actually the important thing: there are open feature requests for more workspace customizations that are either not preferences, or, are complex preferences stored in a single XML-string. Two oft-requested features that exemplify these are perspective customization and language-specifications (e.g. compiler rules, formatter rules.) We got email requests for this regularly, and my response is almost always the same: I'd be happy to accept well-written code. These things people would _love_ to preserve from workspace to workspace. At Google we do some of this through centralized features, but customized perspectives would be pretty darn exciting, to be honest. They just need the work to be done. However, they require a level of expertise in the API that working on keyboard shortcuts demonstrated as a little difficult. You're all experts in the platform, so I'm not telling you anything new: the workspace is customized by more than just _preferences_. They were just the easiest and fastest win. At Google not only did we have preferences, we had .class file tasks, and we even had a special task type that let you specify everything with Groovy. Oh, that was pretty nice for some basic scripts, but we eventually dumped it. It was an idea that was based on Eclipse Monkey, but until there's a nice powerful Eclipse scripting solution, that probably should stay out of the Workspace Mechanic. SUMMARY AND OFFER I would rather see more task types added than see this just become preference-mechanic, because Pascal is right (comment 21) this does more than preferences, and I'll be willing to dedicate some time, particularly as we're in December, which is slow enough at work for me to take on some work, but only in conjunction with somebody else. I love coding, but I'm a social beast, I get enough isolated sole contributor work at my day job. So, how can we work together?
(In reply to Robert Konigsberg from comment #46) > Wayne was right in Comment 6 that the process overhead was the thing that > kept me from being interested in making this part of the platform. I'd heard > stories about moving projects to eclipse.org that made the whole thing seem > not worthwhile. I'd like to hear some of those stories if there is some convenient means of relaying them. > The keyboard shortcuts _absolutely_ demonstrate the central purpose of the > WM in action. I should not have made the assumption to the contrary based on my limited knowledge of the WME. > SUMMARY AND OFFER > > I would rather see more task types added than see this just become > preference-mechanic, because Pascal is right (comment 21) this does more > than preferences, and I'll be willing to dedicate some time, particularly as > we're in December, which is slow enough at work for me to take on some work, > but only in conjunction with somebody else. I love coding, but I'm a social > beast, I get enough isolated sole contributor work at my day job. So, how > can we work together? If there is still desire, I can assist with the process of creating WME as an Eclipse project. If we start today (soon), then we can potentially be ready for an initial contribution in early January. Does it make sense to suggest that interested parties can start making contributions to the existing project today? That might be a good way to gauge real interest and establish a sensible list of committers.
(In reply to Robert Konigsberg from comment #46) > I would rather see more task types added than see this just become > preference-mechanic, because Pascal is right (comment 21) this does more > than preferences, and I'll be willing to dedicate some time, particularly as > we're in December, which is slow enough at work for me to take on some work, > but only in conjunction with somebody else. I love coding, but I'm a social > beast, I get enough isolated sole contributor work at my day job. So, how > can we work together? Hi Robert, I would be interested in adding support to load a target platform automatically at startup/periodically. Also customizing perspectives with WM would be awesome as I always change the layout of the current debug perspective manually right after WM has applied its prefs. Given that I have been doing e4 trainings for almost a year now, I'm confident that I understand enough of the e4 API to do this. Problem is, I'm on CET and thus we would have to find a time slot to collaborate. Thanks Markus
FYI - I've opened bug 455645 ('Integrate Oomph into all EPP packages') that addresses the same problems but with Oomph (which is available at Eclipse.org and will be part of the Mars Simultaneous Release).
