Community
Participate
Working Groups
Platform should provide an image viewer that would allow to open images supported by SWT in simple Editor that should have basic zooming an panning features. QuickImage plugin is pretty much what this could look like. Though it should work trough IStore and not IFile, so it can open images from remote locations, such as Bugzilla attachments or CVS history.
(In reply to comment #0) > Platform should provide an image viewer that would allow to open images > supported by SWT in simple Editor that should have basic zooming an panning > features. > > QuickImage plugin is pretty much what this could look like. Though it should > work trough IStore and not IFile, so it can open images from remote locations, > such as Bugzilla attachments or CVS history. > Feel free to use the QuickImage plugin if it suite the needs. I can change/donate the plugin to fit EPL. The plugin is available here http://psnet.nu/web/node/eclipse /Per
We won't be adding any new editors right now
(In reply to comment #2) > We won't be adding any new editors right now Why not? It is very common feature (very handy for browsing/comparing screenshots and UI icons). There is already a contribution of such image browser, which I can clean up and make it ready for inclusion.
We are trying to keep the SDK plug-ins to a reasonable size as RCP applications want us to break things up more. If you have an editor to contribute feel free to make a plug-in available to the community.
Tod, there is already some plugins for image browsing available, however those aren't well maintained (i.e. update/download site isn't always available) and it also a hassle to install those 3rd party tools on every new Eclipse install. Since it is a common and very useful feature (i.e. to browse images from CVS or from Mylyn attachments) and it won't add lots of code, it would be really great if you'd reconsider. I'll contribute the code then.
If you are also signing up for the maintenance of this editor I would be happy to look at what you come up with.
(In reply to comment #6) > If you are also signing up for the maintenance of this editor I would be happy > to look at what you come up with. I don't see why not. So, what platform plugin should I add new editor to?
workbench if dependencies will allow, if not ide
Created attachment 79923 [details] initial image viewer implementation Tod, here is the first cut of the image viewer editor. It seems like workbench plugin don't have any editors and there is no icons, so I put new editor into the ide plugin. There is still few minor things to cleanup and perhaps contribute some actions to resize image to fit the editor, etc., but I'd like to check with you that I am going to the right direction. Thanks.
Created attachment 79924 [details] mylyn/context/zip
A few things to mention 1) There is no javadoc at all. We should javadoc everything even in internal methods for the sake of maintenance 2) The since tag is 3.4 3) The Job in ImageViewerEditor may show up in the progress view so it's name needs to be internationalized 4) I am not sure we can make this the default editor for compatibility reasons - we might break RCP apps that have thier own. 5) We might want to make the background of the editor white as the widget colour is hard to read. Using SWT_LIST_BACKGROUND is a good choice 6) Do we want to centre the image or have it in the top left? I had to search around a bit to see it. 7) The icon for the editor is the generic icon not the one used in the package explorer. This makes navigation much harder 8) There are a lot of methods I am not sure how to test (when does rotate or zoom get called)? When there is some javadoc we can check it out. All in all a decent idea though and not too big - thanks for the contribution. Just to be clear though it is not ready for committing until the issues above are dealt with.
Created attachment 80280 [details] possible editor icon Thanks Tod. I'll followup on those issues in a day or two. > 7) The icon for the editor is the generic icon not the one used in the package > explorer. This makes navigation much harder The idea was that editor would have its own icon, which I haven't included with the patch. Here is possible icon candidate that I took it from Mylyn project, but we may need to find a better one. I think that package explorer is using editor's icon, unless there is a system editor set for the given resource type. Also note that my editor implementation work nicely with resources in CVS/SVN Respositories and History views, as well as with images from the Attachments section in Mylyn's task editor. Those don't really have any resources underneath.
Created attachment 80599 [details] updated patch Here is the updated patch that should address issues with previous version.
Created attachment 80602 [details] icons
Tod, I suppose there is no chance this would go into 3.4M3?
Today is the last day for M3 development so I am afraid not.
Created attachment 83548 [details] icons Here is an improved icons for the viewer toolbar. Tod, please let me know if I can do anything to help to get this into 3.4m4. Thanks.
Great use of commands and menus - nice to see everyone else moving ahead too. I notices that there are a lot of commands for zooming and there is a zoom cursor but it doesn't seem to do anything. We need more meaningful class javadoc Why are you sub-classing Canvas? I would rather we could still roll with any SWT changes in the future and subclassing Canvas seems less flexible to me. ImageViewerEditor line 62 has System.out.println("focusGained(FocusEvent e)"); //$NON-NLS-1$ I think you are generating a lot of unneccessary jobs in ImageViewerEditor. If you cached the job in the focus adapter and then scheduled it you would not get unnecessary executions of it. You should not cache the image in the viewer. Use the image registry from the IDE plug-in (#getImageRegistry)
Created attachment 83683 [details] updated patch (In reply to comment #18) > I notices that there are a lot of commands for zooming and there is a zoom > cursor but it doesn't seem to do anything. There only 4. "zoom in and out" should react immediately. Two other - "zoom to original size" allow to restore image after zooming in ad out. The last one is "zoom to fit" - it is actually more like a check button (I've updated patch to reflect that), so it will zoom out image if it doesn't fit into the canvas area (you can see that by resizing the editor), but it won't resize image bigger then its original size > We need more meaningful class javadoc I've tried to expand javadocs a bit. Can add more if you can give me more specific examples or pointers. > Why are you sub-classing Canvas? I would rather we could still roll with any SWT > changes in the future and subclassing Canvas seems less flexible to me. That seemed logical to me. But since you don't think it was a good idea, I've changed code to use delegation > ImageViewerEditor line 62 has > System.out.println("focusGained(FocusEvent e)"); //$NON-NLS-1$ Cleaned > I think you are generating a lot of unneccessary jobs in ImageViewerEditor. If > you cached the job in the focus adapter and then scheduled it you would not get > unnecessary executions of it. Hmm. Job is created and then executed when editor instance is created and there are no additional additional executions on focus. Can you please elaborate? > You should not cache the image in the viewer. Use the image registry from the > IDE plug-in (#getImageRegistry) Not sure why. I thought image registry is used for icons and images that may generally reused many times. But in this case image is a resource, so no need to reuse it. Anyways, I've updated patch against trunk and incorporated your suggestions.
I have a question about the IDE providing an image editor of this sort. I see two main use cases for opening images: 1) Have a quick look at the image 2) Perform operations on the image, such as editing or adjustments For internet image types and use case (1) I currently use the embedded browser because I find to be the best simple image viewer for those image types. In this use case all I care about is the Actual Size button (it's there on the embedded MSIE, don't need any zooming, panning is free). If I need to go into use case (2), I open with the system editor. The only change I've made is to map the internet image file types to the Internal Browser (just fyi, the Tasktop RCP application does this by default because we find it commonly useful). My question is whether a simple editor like the one proposed here can do a better job than the embedded browser for use case (1)? I personally find the internal browser the simplest solution and the one I would continue to use by default, unless a very slick image viewer, compatible with all the images my browser can display, were provided. Or perhaps there are scenarios where the browser fails to do this (on Mac or Linux?) or when the user specifies an external browser as default?
(In reply to comment #20) > For internet image types and use case (1) I currently use the embedded browser > because I find to be the best simple image viewer for those image types. Mik, I am not sure what exactly you suggesting here, but completely disagree that embedder browser is the best viewer. First of all it does NOT work for images from SVN or CVS repository and History views and as I already reported to you, for images opened from Task Editor attachments in my browser it shows "save image" dialog and I have to cancel it and hit refresh on the browser in order to see image. So, proposed solution provides smother integration and work with image formats supported by SWT (gif, png, jpg, and probably bmp).
Regarding History/CVS/SVN, I've been finding the image compare viewer sufficient. Not sure why you have to hit Save on images from the task editor, but it sounds like a misconfiguration or a bug with Mylyn that I can't reproduce (for me they open very nicely with the embedded browser). But I don't want to get into an argument about utility here, I just wanted to state my use cases and current solution as another data point. Also note that I never said that the embedded browser is the "best viewer", I actually think that very slick Eclipse-based image viewers that could be built with some effort, but what I was asking is whether it was the best option as for a simple image viewer.
(In reply to comment #22) > Regarding History/CVS/SVN, I've been finding the image compare viewer > sufficient. Not sure what you mean by compare viewer. It is only used for comparison and the editor I contributed is actually a complimentary feature to comparison editor, which suddenly does show images, but does not help with opening/viewing images from regular eclipse views. > I actually think that very slick Eclipse-based image viewers that could > be built with some effort Wouldn't mind to elaborate on what you call "slick" image viewer? Also, can you please try the proposed editor implementation?
(In reply to comment #20) > I have a question about the IDE providing an image editor of this sort. I see > two main use cases for opening images: > 1) Have a quick look at the image > 2) Perform operations on the image, such as editing or adjustments Having one that works against IStore provides better integration especially wrt. external images via CVS compare etc. But OTOH Eclipse is about integration and we shouldn't feel the need to write our own just because we can especially if better external exist, as Mik points out. Thus for me this contribution has to address the following: 1) Work against IStore (which I believe it does presently, right?) so it can view remote images 2) Ultra small footprint (for reasons Tod mentioned in comment #4) 3) Just viewing and not editing (leave that to better platform apps)
+1, I agree with all of Kevin's points except the editing piece. I would want just basic cropping functionality, that's it for the built-in viewer.
I wouldn'r mind to look a the cropping functionality later. At the moment it is unclear if Tod is willing to take this forward.
If the image viewer is extensible enough to support SVG, I could see this being useful for testing purposes in xml/web development as well. I personally don't like the web browser as an image viewer, just seems clunky in my opinion. If I'm in a web browser fine, but I don't want to launch the browser widget just to view images.
Dave, the implementation I've contributed is quite slim and it is using org.eclipse.swt.graphics.Image, which have native support for several image formats, such as gif, jpg, png and bmp, but it doesn't support svg. You may want to submit an enhancement request for the SWT in regards to support the svg image format (that actually may come handy for rendering high-quality icons popular on some platforms). There is also an open source svg viewer available on http://sourceforge.net/projects/svgplugin (it is using Apache Batik for rendering). Though I don't know if it still works on Eclipse 3.3 and 3.4.
I am willing to take this forward but I was waiting for consensus to be reached before I went any further.
+1 for me. The basic functionality is there from my testing this morning. There can be other bugs open for the ability to crop and even a "screen shot" tool :) Thanks Eugene!
+1 from the Markham Rd/16th Ave slums for a basic image viewer to start.
I have had a look at the new implementation and I have a couple of observations. Generally it looks fine but I have a couple of concerns. ImageCanvas sounds like a subclass of Canvas. I think I would rename it to indicate that it is a helper class. The Job in the ImageViewerEditor catches CoreExceptions and does nothing. It has a comment that says show the error but it doesn't. You cache your image in the ImageCanvas and the ImageViewerEditor both of which can dispose it. The code looks safe enough but I would only manage the instance from one place. You re-create the image in the ImageCanvas and dispose the old one all of the time so the instance in the ImageCanvas and the ImageViewerEditor will likely be different.
We had a discussion about image editing this morning and we think the SDK is really not the right place for adding a lot of new image support. Image editing and viewing is not a task that all IDEs would need (it is not a significant task for most Java developers for instance) so having it as part of the IDE does not seem like the right place. We think a more image intensive component like WTP would likely be a better place. David Williams what do you think? This was first requested by Ed Burnette in Bug 85360 3 years ago and so it is clearly of interest to the other Eclipse projects.
I can imagine this being much more basic that a web tools thing. For example, EMF generates item providers for tree views, including placeholder icons, and users will typically want to edit the images with ones they tailor themselves so having a nice integrated icon editor would be very helpful for EMF itself...
*** Bug 85360 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > > We think a more image intensive component like WTP would likely be a better > place. David Williams what do you think? > I agree, WTP (common component) would be a good home for this. We've had similar requests since web developers use lots of images (and often hard to tell the difference from just their names). Not sure we have a bug open, so this one could be moved. I have not looked at the attached patch, but would be glad to consider them. We might need some "extensible" ability, if it's not in current patch, such as to handle SVG as Dave pointed out in comment #22. (Plus, there are others, like rendering a JSP in a thumbnail, if anyone ever wanted to get fancy). This wouldn't be quite as handy for the community (those that don't use WTP, that is ... but, really, how many is that ... hehe :) But, we also hope to make our "common" component a separate download, so that's very small compared to WTP. Feel free to move it over, if you agree this would be suitable.
The rumor on the street is that plug-in developers spend a lot of time cropping images and would like to see something somewhere in the Platform that's basic.
I agree with Chris. There is a need for a simple viewer for images and screenshots in pretty much any IDE. Personally I am missing such image viewer a lot when working with PDE and bug reports that have screenshots. So image editor may be well suited for WTP, but this issue was about the simple image viewer available in the Platform. Then, if decided, nothing really prewent WTP to extend it and provide editing capabilities and stuff.
I also agree with Chris too. Given that folks can use Eclipse to develop Eclipse UI applications, there is clearly a need for icon editing even just for that usage of Eclipse. I really don't see how image editing is specific to web tools though I can well imagine it would be useful there...
I'll chime in my two cents worth here as well. It would be EXTREMELY handy to have an icon editor built into either PDE or the base platform. I don't know how many times I've had to hunt to find a decent editor just to create icons for use with plugins. Also, doesn't the Nebula project have a image viewer widget in which this contribution could go against? Might be best there, since Nebula widgets are supposed to eventually make it into swt. Just a thought.
I would have to disagree that WTP is the right place for this functionality. Sure web development is one major usecases for viewing and potentially editing images, but it is by far not the only usecase. Since we (WTP) are right now actively trying to figure out a way to make pieces already in WTP that have broader potential appeal more easily accessible, I view putting an image viewer into WTP as a step in opposite direction. This discussion actually illustrates one critical problem we have in Eclipse right now. The problem is that it is extremely difficult to find home for some of these micro-components that have potential for broad appeal. Six months ago I tried to shop around the idea of having a project at Eclipse whose charter is to provide home for micro-components that could have potential for broad appeal but can otherwise find no suitable home in other projects. At the time, I didn't get much support for the idea, but I am willing to give this another try. Basically, BEA is willing to co-propose and lead such a project if there are companies or individuals who are willing to co-propose this project with us.
+1 for image editor in platform UI. ECF would like to use such an editor to send/edit/present screen shots...for the IDE of course, but potentially also for RCP/other applications.
Konstantin hit the nail on the head. It's perfectly reasonable for this to exist as a component, but it doesn't belong in the platform. If there isn't a good place for it at eclipse.org, then that sounds like the problem that should be fixed.
(In reply to comment #43) > Konstantin hit the nail on the head. It's perfectly reasonable for this to > exist as a component, but it doesn't belong in the platform. If there isn't a > good place for it at eclipse.org, then that sounds like the problem that should > be fixed. Mike, one of the major point of this enhancement request is to create an image viewer that would be available in the IDE, support editor source API and to complement image viewing capabilities of the comparison framework UI. If everyone agree that it would be a better idea to put such component into a separate plugin, but then Platform and packaging projects would have to include it with the currently supported packages (Java IDE, PDE, etc). It also seems like several commenters wanted to get various editing features into proposed image viewer, but I would like to ask not to draw attention from the simple image viewing features listed in the original description and create separate bug reports for those.
If we had a project where micro-components of many stripes can be created, developed and released, then other projects could take dependencies on these micro-components and the various packages that are produced for end-user distribution could be modified to include them as necessary and desired. This would achieve the stated goal to have "Eclipse IDE" come with an image viewer while letting the core platform remain compact. The reason that I am advocating this approach over the proposal to put this into WTP is that while it is technically possible to devise a way to build and distribute pieces of WTP for consumption by people who don't otherwise have dependency on web tooling, it feels to me like a rather unnatural solution.
Basically you need a general components or utilities type project. Something that may not necessarily be used in the platform, but something that more than one project might want to use. Sorta like an Orbit but for specific to Eclipse instead of third party projects. There are several one off projects or features that could be migrated to the common project I suspect.
We might call such a project the "Tools" project. Oh wait... :-P We already have that! GEF lives there and lots of projects use it, and likely even more so with the very cool Zest support...
Nice try, Ed, but Tools project does not fit the bill. It is oriented around containing sub-projects of significant scope with many people working on them, their own pmcs, etc. What we need is a container for "micro-components", some of which might be just a plugin or two with a single committer. The container project would be responsible for administrative and infrastructure aspects (project build and website), leaving the individual components to biz of coding. Such a container project could be a sub-project of the Tools project, in the same way that Orbit is a sub-project of Tools.
Should we open a new bug to discuss the idea of a container for "micro-components"? Personally, I am in support of the idea. I know PDE owns the Log View which many in the community want to include in RCP apps but without including PDE. I believe this would be another good candidate for such a container.
I am currently looking into putting together a formal project proposal. Once the proposal is announced, there will be a mailing list where interested parties can have the formative discussions without taking over this bug. In the meantime, anyone interested in being involved with this project should get in touch with me directly.
(In reply to comment #50) What are the chances that such project and its components will be ready for the time of Ganymede release and would be considered for inclusion with Eclipse packaging project? Also it is unclear how such component would be consumed by the users. Would it have to be installed from the separate update site or one would be able to grab it along with downloading Platform milestone build?
> What are the chances that such project and its components will be ready > for the time of Ganymede release and would be considered for inclusion > with Eclipse packaging project? I would say the chance of this happening for Ganymede is pretty close to zero at this point. > Also it is unclear how such component would be consumed by the users. > Would it have to be installed from the separate update site or one > would be able to grab it along with downloading Platform milestone build? It would be a separate project, with it's own download page and update sites. It would not be part of the Platform builds. I suspect that most users would get the various components either via one of the distributions created by the packaging project or by following dependency links when downloading plugins for another project (for instance, if WTP was going to take a dependency on this, it would be listed on the WTP download page).
(In reply to comment #52) > > What are the chances that such project and its components will be ready > > for the time of Ganymede release and would be considered for inclusion > > with Eclipse packaging project? > > I would say the chance of this happening for Ganymede is pretty close to zero > at this point. Then I would like to propose to include proposed patch into the ide plugin as suggested before, so functionality would be available in 3.4 release. Then in the future, when infrastructure will be in place, we can consider to move it into a separate project/component.
Unfortunately I think the platform has to agree to include this and I believe they've said no. I understand why they would say this but at the same time, I don't think I fully agree. A project for small components is a good idea. Projects like EMFT consisting of a large number of small components is working extremely well to stimulate the community to contribute and participate so emulating that and perhaps even reusing our reusable infrastructure for builds and publishing seems like goodness. I would support that for sure, as well as help out and contribute as must as possible...
(In reply to comment #54) > Unfortunately I think the platform has to agree to include this and I believe > they've said no... Now I feel like I am out of the loop. When did they say no?
Todd's comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=155323#c33 and his manager's (and PMC member) comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=155323#c43 along with this having been moved to WTP sounds like a decision to say no has been reached already. I could be reading too much between the lines...
Ok, Tod's comment is referring to the editing features, which isn't really what this feature is all about. Jeff McAffer's comment on bug 85360 that Tod referred to gives a good point that editing features need to be really good in order to compete with existing editors. I am not suggesting that it can't be done in a separate component, however this enhancement request which is suggesting to add 2 reasonably simple classes to the Platform in order to solve several specific issues with image viewing within IDE that can't be solved with external editors not integrated with Eclipse. Isn't that a reasonable request, especially considering already existing image viewing features in the comparison UI?
In the interest of making some progress on this, I will propose another alternative... Create a new component in WTP incubator around image viewer and potentially basic editing support. Seed that component with this code contribution. There are several advantages to this approach: 1. Code in the incubator has no backwards-compatibility obligations. If it needs to move later, it can do so easily. You also don't have to rush to finalize API's by the upcoming Ganymede API freeze. 2. You can have a milestone build to coincide with Ganymede release and make a distro available for people to download and play with. 3. It gives you a chance to prove that you will maintain this code on ongoing basis as well as a chance to attract other people who might be interested in contributing to this area. It's low risk for the projects involved for the same reason. I know it's not really the ideal solution from your perspective, but this may be the best option available right now. If you are interested, David or I can give you details on what you need to do to propose a component for WTP incubator.
(In reply to comment #58) > In the interest of making some progress on this, I will propose another > alternative... > > Create a new component in WTP incubator around image viewer and potentially > basic editing support. Seed that component with this code contribution. Konstantin, it is already been mentioned by several commenters on this report that WTP is not the good place to put image viewer to. I completely disagree with Tod's remark: "Image editing and viewing is not a task that all IDEs would need (it is not a significant task for most Java developers for instance) so having it as part of the IDE does not seem like the right place." Well, it is not as significant as, say Java refactoring, but if you need to take a pick at the icon, screenshot from the documentation sources or some other images, it is invaluable to have it next to your fingers in any IDE, more over, there is no substitution if picture is sitting in CVS server or other place not represented with a local resource. Please also note that proposed image viewer is completely internal, so there should be no backward compatibility or API issues with it and I can't think of any risk related to that. All your other points would pretty much apply if this feature included into Platform with the additional advantage that it will require none of WTP dependencies and will be available in the core IDE.
(In reply to comment #59) > Konstantin, it is already been mentioned by several commenters on this report > that WTP is not the good place to put image viewer to. I completely disagree > with Tod's remark: "Image editing and viewing is not a task that all IDEs would > need (it is not a significant task for most Java developers for instance) so > having it as part of the IDE does not seem like the right place." Well, it is > not as significant as, say Java refactoring, but if you need to take a pick at > the icon, screenshot from the documentation sources or some other images, it is > invaluable to have it next to your fingers in any IDE, more over, there is no > substitution if picture is sitting in CVS server or other place not represented > with a local resource. Euguen I have to agree with you here on the JDT aspect. Just becasue it may not be seen as significant for some portions of the JDT, it might be significant for not only the base platform, but also for RCP applications as well. In general, having an image viewer built into the base platform is a good idea. It provides basic viewing support. We keep saying that eclipse is more than the JDT, but at times we keep focusing on the JDT aspect. This reason is why I'm in favor of moving JDT and PDE out of the base eclipse project and over to the Tooling project, but that's another discussion I may have to open a bug about in the community. > > Please also note that proposed image viewer is completely internal, so there > should be no backward compatibility or API issues with it and I can't think of > any risk related to that. All your other points would pretty much apply if this > feature included into Platform with the additional advantage that it will > require none of WTP dependencies and will be available in the core IDE. I'm still for it being as view in the platform, it makes the most sense to me there. Especially since most other IDE tools already have some sort of image viewing tool built in. just my two cents.
I agree with Dave's comments. I have all kinds of icons that I need to work with all the time and not being able to view them easily is a major inconvenience. I also agree that PDE and JDT are just tools and their special status as part of the platform is an artifact of how Eclipse started. I liked Kosta's original idea better. A Tools subproject for small components to encourage more participation with a much lower barrier to entry...
(In reply to comment #61) > A Tools subproject for small components to > encourage more participation with a much lower barrier to entry... +1 from me for that, I am all for more participation. What about a project that is to the IDE as Nebula is to SWT?
(In reply to comment #61) > I agree with Dave's comments. I have all kinds of icons that I need to work > with all the time and not being able to view them easily is a major > inconvenience. I also agree that PDE and JDT are just tools and their special > status as part of the platform is an artifact of how Eclipse started. On that note, I started bug 215567 for the discussion of moving JDT and PDE to tooling so I don't hijack this bug.
> I liked Kosta's original idea better. A Tools subproject for small > components to encourage more participation with a much lower barrier to > entry... Definitely. I think longer term that would be a better home. I suggested a WTP incubator component as a short-term solution that would get this contribution into CVS in a fairly short order and in a way that it can be re-located when a better location becomes available. I continue to believe that WTP is a poor long-term location for this feature.
So, I take it that proposed image viewer is not getting into the core IDE in the 3.4/Ganymede time frame?
The Eclipse Project PMC discussed this at some length in our last call. We do not want to see this included in the SDK. Given the interest in it, it seems like it would be an excellent candidate to drive the question of how to make "micro-components" available to other projects at Eclipse.org.
(In reply to comment #66) > The Eclipse Project PMC discussed this at some length in our last call. We do > not want to see this included in the SDK. Given the interest in it, it seems > like it would be an excellent candidate to drive the question of how to make > "micro-components" available to other projects at Eclipse.org. Mike, can you please expand some details on your motivation to not include image viewing feature with SDK? I am completely puzzled why image comparison editor can be included with the SDK, but image viewer - can't. Also, can anyone please comment on the odds that "micro-components" ideas can be consumable at the time of Ganymede release? Thanks
Let's call the new project Asteroid. Meteor would be bad because no one wants to fall from the sky and burn up in the atmosphere! We have quite a bit of experience with small components with EMFT and with setting up builds and the publishing infastructure for them (all of which are significant barriers to entry for small components and for new committers). We could maybe help some...
(In reply to comment #68) > Let's call the new project Asteroid. Meteor would be bad because no one wants > to fall from the sky and burn up in the atmosphere! We have quite a bit of > experience with small components with EMFT and with setting up builds and the > publishing infastructure for them (all of which are significant barriers to > entry for small components and for new committers). We could maybe help > some... > Yeah but with Asteroid we can wipe out whole worlds and civilations. We won't have Bruce Willis to save us in his Super Shuttles either.
(In reply to comment #67) > Mike, can you please expand some details on your motivation to not include > image viewing feature with SDK? I am completely puzzled why image comparison > editor can be included with the SDK, but image viewer - can't. > Honestly, I can't tell you why the Image Compare editor is there -- someone else on the UI team may know, but I do not. I do understand that it seems bogus to be able to look at an image by picking two and saying "compare with each other", but not by clicking on just one of them. Personally, if I could figure out how to move that compare editor to "Asteroid" without breaking backwards compatibility, I'd do it, since that's where I believe that functionality belongs. In any case, it's one thing to say that we can show you something reasonable if you look at a couple of images, and another thing to say that we are providing the default editor for those content types. I don't know if there are existing components that provide this anywhere, but I could believe that we would break them (or tools that consumed them) if we were to add an image viewer at the platform level. This isn't a random guess; we actually *have* had this happen when we added an editor for a new content type in the past. If there aren't any conflicting tools out there, we still aren't any better off because because as soon as the image viewer went in, pressure will start building to make it into a basic editor (maybe even just the metadata at the start), then a more powerful editor, then something that can convert between image formats, then... all good things to do, but not required at the SDK level. I really do believe that the image viewer belongs in its own micro-component, where it can grow as required by the projects that want to consume it. I don't know whether we can make that happen for Ganymede, but with the amount of energy I'm seeing in this bug, it seems like it should be possible.
As mentioned previously, I've been working on a draft proposal for a project to serve as home to micro-components. I have called it Nexus in reference to one of its key requirements of enabling better integration among projects. http://wiki.eclipse.org/Nexus_Project So take a look at it and give feedback. You can post comments directly to the wiki. Keep in mind that this is still an early draft and I would expect the proposal to get more detailed as the result of discussion. Once we had a few rounds of revisions and have built a critical mass, we will turn this into a formal project proposal.
(In reply to comment #70) > Honestly, I can't tell you why the Image Compare editor is there -- someone else > on the UI team may know, but I do not. I do understand that it seems bogus to be > able to look at an image by picking two and saying "compare with each other", > but not by clicking on just one of them. Personally, if I could figure out how > to move that compare editor to "Asteroid" without breaking backwards > compatibility, I'd do it, since that's where I believe that functionality > belongs. In this case, can you please explain your vision how such comparison component or image viewer would be made available to users of Java or plugin development IDE. > In any case, it's one thing to say that we can show you something reasonable if > you look at a couple of images, and another thing to say that we are providing > the default editor for those content types. The whole point is to provide a viewer for these content types. It don't have to be default, so integrators can overwrite it, but I think it would be beneficial for many users to have such viewer in there. > I don't know if there are existing > components that provide this anywhere, but I could believe that we would break > them (or tools that consumed them) if we were to add an image viewer at the > platform level. This isn't a random guess; we actually *have* had this happen > when we added an editor for a new content type in the past. There are two things I would like to understand about this. First of all, integrators would be picking up new platform, so they could ajust their integrations to benefit or work with new viewer. The second thing is that if they had their own "default" viewer for the same content types, it would stay default. > If there aren't any conflicting tools out there, we still aren't any better off > because because as soon as the image viewer went in, pressure will start > building to make it into a basic editor (maybe even just the metadata at the > start), then a more powerful editor, then something that can convert between > image formats, then... all good things to do, but not required at the SDK level. I think that is a speculation. Everyone already agreed that "advanced" editor is better off to be in a separate component (though still unclear to me how Java IDE user would consume it). Such editor doesn't have to be the same as proposed lightweight image viewer. There is already number of examples in platform when there are more then one editor for same content type (i.e. JDT/AJDT/VE for .java types, as well as countless editors for html and xml, where some of those are in the Platform). > I really do believe that the image viewer belongs in its own micro-component, > where it can grow as required by the projects that want to consume it. So how such image viewer will be made available for JDT and PDT users? I think most of those users go to the download page at http://download.eclipse.org/eclipse/downloads/ and grab one of bundles available form there. I believe that is one of the most critical points of this enhancement request. > I don't know whether we can make that happen for Ganymede, but with the > amount of energy I'm seeing in this bug, it seems like it should be possible. That is really good to hear. Let's keep our hope for that.
(In reply to comment #72) > In this case, can you please explain your vision how such comparison component > or image viewer would be made available to users of Java or plugin development > IDE. > If a developer wanted it, wouldn't they just go to Nexus and pick up the component?
(In reply to comment #73) > If a developer wanted it, wouldn't they just go to Nexus and pick up the > component? Number of comments in this request shows that many developers do want it. Period. So why don't just include it with the core IDE and save the hassle? I also doubt that many less experienced Eclipse users actually "go" anywhere for picking up components. They don't want to deal with so-called "plugin hell". So for them it would be a good reason to switch to the tool that have same features out of the box.
(In reply to comment #74) > (In reply to comment #73) > Number of comments in this request shows that many developers do want it. > Period. So why don't just include it with the core IDE and save the hassle? I > also doubt that many less experienced Eclipse users actually "go" anywhere for > picking up components. They don't want to deal with so-called "plugin hell". So > for them it would be a good reason to switch to the tool that have same > features out of the box. Now we are talking packaging. If it was very popular I could see it being included in Eclipse for JEE developers, Eclipse for Web Developers, Eclipse for PDT...etc. It's all about packaging and piecing stuff together.
(In reply to comment #75) > Now we are talking packaging. If it was very popular I could see it being > included in Eclipse for JEE developers, Eclipse for Web Developers, Eclipse for > PDT...etc. It's all about packaging and piecing stuff together. I agree, but then, shouldn't download page [1] be replaced with something that would provide these packages for immediate consumption? It is been brought up in the previous comments that the way JDT and PDT are currently delivered within SDK is making it pretty much impossible to have other components included. This enhancement request is a practical illustration of that issue, which won't be really resolved only by creating micro-components project. So something need to be done with the SDK and related infrastructure. [1] http://download.eclipse.org/eclipse/downloads/
Eugene, I've complained (https://bugs.eclipse.org/bugs/show_bug.cgi?id=208381) before that the page you show is hard to find. From the main page, the easy page to find is http://www.eclipse.org/downloads/ but from that page you can't easily find the page you indicate. The latest comment in that bug says the hard-to-find page should point at the easy-to-find page, which to me is the opposite problem but perhaps the one you've highlighted. There is a lot of work being done on defining new packages with http://www.eclipse.org/proposals/amalgamation/ being one example. Ian is proposing guidelines for how to put those together and who will be responsible for testing them. If Kosta's Nexus proposal can get off the ground quickly, it could provide components for inclusion by other packages. Given all the icons we use in EMF.Edit, I'd really like to have a viewer and preferably one that edits. With all the various needs for icons when creating Eclipse applications in general, I would argue that an SDK whose purpose is to be minimal for developing Eclipse applications needs this too, but hey, package owners should have final say over what's in their package.. Kosta, With respect to Nexus, which is rather a pretty name I must admit, but I still like Asteroid better because you can imagine all the components circulating cohesively around a larger central mass. You could have a logo contest! :-) Sorry Ian! One comment I would have about the silo effect is that to a large extent, that's the fault of the projects themselves due to the fact that they create the big silos by virtue of their monolithic feature or plugin structure. Even with this new project, which I think is needed and I agree with, the silo affect still needs attention, e.g., the XML editor ought to suck in a few dependencies as possible for greater reuse. Based on our experience with EMFT, a key to making this project successful will be uniform infrastructure that's easy to set up and maintain by a small number of people or by individuals. We'd be happy to share our experiences and infrastructure to help. The component rules are good and are similar to what we outlined in http://wiki.eclipse.org/Modeling_Project_Organization to describe how the modeling projects are structured as components. You probably want to state clearly that all project committers get to vote on new components and the associated committers and from then on (as you've said) only the component committers can vote new committers and those committers only have access to the CVS for their own component as well as perhaps the shared web pages of of the main project site. So I suggest you include component creation guidelines. The process we tend to follow is, write a proposal just like a project proposal, the project lead makes sure it's good to go, post it on the newsgroup for a week for comments, call for a vote via the mailling list for which all committers on the project's components can vote (though I hope we can have a portal process for it), wait for a week for the votes to come in, if there are no -1 (treat it like a vote for committers in terms of voting rules) then your done and you need to fill out the NCRF and the foundation will want to send an announcement. All this is documented by the ever fastidious Nick-meister in http://wiki.eclipse.org/Modeling_Project_Releng/Component_Creation. Please include me as in interested party. Perhaps Nick will want to be added as well (even as a committer) because he's getting really bored from lack of work now that the build infrastructure is writing itself out of thin air with only RSS feeds and bugzillas to fuel it. Sorry Nick, I know you're always swamped. The foundation will want to see a bit of a bio for any of the folks actually proposed as committers or participants on the project. If we can get all this going quickly we can perhaps make almost everyone a little happier. Ah, so naive you say. Soul crusher! :-P
(In reply to comment #77) > I've complained (https://bugs.eclipse.org/bugs/show_bug.cgi?id=208381) before > that the page you show is hard to find. From the main page, the easy page to > find is http://www.eclipse.org/downloads/ but from that page you can't easily > find the page you indicate. The latest comment in that bug says the > hard-to-find page should point at the easy-to-find page, which to me is the > opposite problem but perhaps the one you've highlighted. Ed, my point was that these packages are only created for releases, but not for the Platform milestones. So you get package updates for new Platform version only once a year, which is well behind Platform's own builds. Anyways, it seems like it is time to close this issue as WONTFIX for the second time because it doesn't seem like Platform going to include this contribution.
Eugene, That's not true. Ian posted this to the Foundation newsgroup just this week: If you are interested in testing the latest and greatest in the Ganymede M4 release, the EPP project has made available packages containing the M4 releases from the relevant projects. To download go to http://www.eclipse.org/epp/ganymede.php. Aren't you on the distribution list for http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00468.html where he also announced this? I trust that you realize there are folks trying to support your point of view and that whether the platform includes it or not is independent of whether an image viewer will be provided by some project at Eclipse.
(In reply to comment #79) > That's not true. Ian posted this to the Foundation newsgroup just this week: > Aren't you on the distribution list for > http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00468.html where > he also announced this? Thanks for the link. I am subscribed to that list and subject of Ian's email wasn't really suggesting that there is a new hidden download site for epp builds based on Platform released a month ago. > I trust that you realize there are folks trying to support your point of view > and that whether the platform includes it or not is independent of whether an > image viewer will be provided by some project at Eclipse. There is already image viewer by some project as it said in the description. As an original reporter I still believe that proposed image viewer should be provided with the platform, but if Platform don't want to include it, that should be reflected with WONTFIX status. This enhancement request include working version of the image viewer build for inclusion into the Platform. At this point there is nothing else I can do and recent comments have faded away from the technical issues related to viewer, but to some administrative stuff that probably should be discussed elsewhere.
Eugene, I couldn't quite parse your reaction to the fact that Ganymede packages are made available via the EPP project http://www.eclipse.org/epp/ The intent is to produce a package for each and every milestone and release candidate so that users will be in a better position to test the packages and thereby help ensure that the packages have higher quality. If the platform decides not to include things that many users deem important then the platform SDK package itself will become less popular than the more feature rich packages. On the other hand, if many people are obsessed with minimalism and consider an imagine viewer as beyond the bounds of minimalism, then the platform SDK will remain popular by making those users happy. There are many related issues around your request so the fact that the discussion touches upon those related issues isn't surprising. I take it you'd rather see your bug focused on your issue and it would seem that when the discussion doesn't go your way, or isn't focused the way you'd like, you'd have the perpetrators go elsewhere. I also take it that having the community work towards supporting an image editor/viewer in some project and letting packages decide whether to include such components isn't a suitable compromise and ought not to discussed in a bugzilla that you've opened. Personally, I interpret the comments from the platform lead as already having said no/WONTFIX, and while I may not agree with all his reasons, I respect his right to do what he believes is best for his package and its users. I'm not sure what's accomplished by moving this bugzilla back to the platform and requiring him to change the state of this bugzilla to WONTFIX. It's seems a bit of a temperamental reaction. Others in the community are hoping to use this bugzilla as a constructive vehicle for enabling micro components and thereby enabling package builds a greater and more flexible set of choices for what to include. I.e., there are a lot of people here trying to be constructive and helpful. So you might consider that,as the old song goes, you can't always get what you want but if you try sometimes you might find, you get what you need.
(In reply to comment #81) > I couldn't quite parse your reaction... What reaction? I merely thanked you for the link that I missed from the Ian's email. > If the platform decides not to include things that many users deem important > then the platform SDK package itself will become less popular than the more > feature rich packages. On the other hand, if many people are obsessed with > minimalism and consider an imagine viewer as beyond the bounds of minimalism, > then the platform SDK will remain popular by making those users happy. Sorry, I don't see your point. You would hardly notice the size change with proposed editor (compare with the XML editor size), but when you can't easily view images from CVS, History or Tasks it is really frustrating. > There are many related issues around your request so the fact that the > discussion touches upon those related issues isn't surprising. I take it you'd > rather see your bug focused on your issue and it would seem that when the > discussion doesn't go your way, or isn't focused the way you'd like, you'd have > the perpetrators go elsewhere. Who am I do think that? I invested my time to work on the image viewer because I've been told that it could be included with Platform. Now we all told otherwise, so we done with this issue. > I also take it that having the community work > towards supporting an image editor/viewer in some project and letting packages > decide whether to include such components isn't a suitable compromise and ought > not to discussed in a bugzilla that you've opened. Again, the request was to include image viewer with the Platform. It would be only fair to open new enhancement request to include image editor to project XYZ. > Personally, I interpret the comments from the platform lead as already having > said no/WONTFIX, and while I may not agree with all his reasons, I respect his > right to do what he believes is best for his package and its users. I'm not > sure what's accomplished by moving this bugzilla back to the platform and > requiring him to change the state of this bugzilla to WONTFIX. It's seems a > bit of a temperamental reaction. It is not temperamental, but simply systematic. Like you said, the Platform team said no for inclusion of the simple image viewer. Then the component lead where issue been moved to said that he don't think it belong to his project either (and everyone agreed with that) and from his comment #50 it didn't seem like he want to use code contributed here for newly proposed micro component. > Others in the community are hoping to use this > bugzilla as a constructive vehicle for enabling micro components and thereby > enabling package builds a greater and more flexible set of choices for what to > include. I.e., there are a lot of people here trying to be constructive and > helpful. It sounds like a task for a separate bug report that would outline infrastructure and other stuff required to enable support of such micro components. So I don't think it belong to this report either. > So you might consider that,as the old song goes, you can't always get what you > want but if you try sometimes you might find, you get what you need. Ed, I already have what I need (simply using 3rd party plugin with my own enhancements). By submitting this request I wanted to help all Platform users to reduce hassle with image viewing. I am surely can live without getting that, even it is so unfortunate. So closing tis request as suggested and opening several other requests to fit suggested strategy seem only logical at this point.
> ... and from his comment #50 it didn't seem > like he want to use code contributed here for newly proposed micro component. I think you've misunderstood my comment. I did not want to turn this bug into a discussion forum for Nexus (too late now), but I was not passing judgement on this code contribution. In fact, the discussion in this bug is what motivated me to get in gear again finding a solution to this common problem. So, if you are interested in creating a micro-component in Nexus for an image viewer, I would recommend that you add yourself to the Nexus wiki under Interested Parties and add a small paragraph for the image viewer component under the Initial Components section. http://wiki.eclipse.org/Nexus_Project The quicker we build a community of interested parties, the quicker this can move to the proposal stage, etc.
Eugene, this bug has been an excellent source of discussion on: - what is the continued role of the platform - what is the role of the SDK - how do we manage smaller contributions of potentially wide utility - how do we grow such components I know it wasn't the purpose of your contribution <g> but actually I think the value of the discussion has been greater than that of the actual utility of an image viewer. If that makes you feel any better. Nonetheless because of its role as a concrete example of these issues I'm sure its frustrating for you since all you wanted to do was contribute this simple little image viewer. Nobody is saying an image viewer isn't of value, we just don't know where to put the darn thing. Some thoughts: 1) The role of the platform The platform seeks to provide the fundamental architecture over which "Eclipse" based components and products can be built. That's it. The fact that a particular component may have utility to several Eclipse based projects isn't sufficient IMHO to warrant inclusion in the platform. It needs to be fundamental, in the way that SWT, JFace, and IResource are fundamental. The fact that we've in the past included things that do more than that is not an argument to add even more. 2) What is the role of the SDK I'm going to pretend to be in charge of product "EclipseCo's SDK". In that role, I chose what I believe is of value to my "customers" and what isn't. I'm always mindful of the cost of development and maintenance, and keep an eye on footprint, so I chose carefully, perhaps conservatively. It turns out that other companies build on "EclipseCo's SDK". Great! But that doesn't mean I need to include things that they'll find useful. As Ed argued nicely in comment #81 (wow), either that's the right decision, or the wrong one and "EclipseCo's SDK" won't fair well against some competitor with a more popular component lineup. In any case, its up to "EclipseCo's SDK" to make those decisions, which is a great discussion, but shouldn't be the focus of this bug. 3) How do we manage small components I'll chime in on agreeing with Konstantine's approach (comment #41) that what we lack is a place to grow and share these smaller pieces of technology for selective consumption by the downstream "products". Then if "EclipseCo's SDK" wants to consume it, it can, or not, depending on its product choice. Sorry but it seems that the image viewer is now the poster child for pushing on this problem and my guess is that for that reason people are drawing the lines in the sand. 4) How to grow the small components "Products" (Eclipse packagings) will invariably chose or not chose technology pieces based on both feature set and level of maturity. Some will be inclined to take greener pieces so they can grow them in the direction they want, others will be inclined to wait for the dust to settle. Again, this image viewer is acting as an example of the current catch-22, where ownership via a "product" (or platform) is the only way to grow the technologies, yet the packagings are more inclined to wait for the maturation of ancillary technology. So my 2c: - The viewer may not make it into 3.4 but lets use this as concrete example of solving it "the right way". Then we pave the way for other technologies. - Konstantine's proposal seems the right direction. It has issues which I've seen discussed elsewhere but the current policy of being deadlocked does also. Hang in there Eugene!
This long sad story is yet another example of what has gone so wrong with Eclipse. Rather than say truthfully, "Eugene, we're not going to accept you patch no matter how good, because you're just a peon without the backing of <InsertBigCorporationHere>", we play a mean game of "lets pretend". For 5 years. Lets humour the users and pretend we're actually interested in their contributions. Lets pretend its merely technical issues that are blocking the patch. Until in the end, when the excuses have been swept aside by an atypically patient contributor, we just have to reveal the truth: "Just give up. We don't want your stinking patches. We make all the decisions around here."
Thanks for the support, Ben. This is sad, but you nailed it down quite well. It is enough to look at number of still not accepted patches I contributed to get the picture.
Gentlemen, Nothing productive is accomplished by casting stones. It is up to a project's team (in this case the Platform) to determine what is and isn't in scope for the project. In this case, the team has made evaluation of this contribution and has determined it to not be in scope. You may not agree with that decision, but it is the project team's decision to make. At the time of last comment, Eugene was pointed in the direction of what it would take to get this contribution under eclipse.org umbrella and ultimately into main packages... Propose an image viewer/editor project and contribute this patch to that project... Eugene did not choose to follow the offered route. Now, since the time of last comment, the idea for Nexus container for micro-projects has be discarded. These days, the Technology project is very welcoming to micro projects and infrastructure has been sufficiently improved to make getting a new project off the ground much easier. Eugene, the described route is still open if you wish to follow it.
Konstantin, as you rightly pointed out, I disagree with platform decision and don't think micro-project make any sense in this particular case and as you again pointed out it didn't work for your own Nexus project... Besides, in the last comment I've been offered to "hang in there", which it didn't look to me that I had to take any actions. So, now thanks, but I will pass on your generous offer.
Eugene, It is unfortunate that you feel that way. Nexus didn't happen because its purpose was merged with the Technology project. We've had a number of micro-projects started under the Technology and various other projects in recent years. Finer granularity of projects whose contents are merged into packages is the way forward. The days of everything trying to merge into the platform are over. There is no point fighting this. Certainly not if your goal is to see an image viewer in eclipse.org packages, which is ultimately the only thing that matters to users. The users don't care what project particular bit of functionality came from.
You are right again. No point fighting this, there is more interesting things in life.
I like the approach suggested by Mik of having Web Images linked to Internal Browser by default. Any chance this can become the default behaviour for those file-types in 4.4.M3 ?
*** Bug 495118 has been marked as a duplicate of this bug. ***
I have not yet read all the comments but I think a small image viewer in Platform UI would be very useful. I try to review the patch for 4.7 M2.
New Gerrit change created: https://git.eclipse.org/r/75261
Gerrit change https://git.eclipse.org/r/75261 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4b732fdd892828793875fc1d8ab555f225fd9801
Images types are now registered as content-types in org.eclipse.ui.browser bundle and are associated with the internal Web Browser editor.
Reopened for a few questions to Platform committers: * Which segment version should be bumped in org.eclipse.ui.browser? minor or micro? * Could this change be backported to 4.6.1 ?
(In reply to Mickael Istria from comment #98) > Reopened for a few questions to Platform committers: > * Which segment version should be bumped in org.eclipse.ui.browser? minor or > micro? Dani, might correct me but I would say micro, as this is no API change. Otherwise you API tools would tell you. > * Could this change be backported to 4.6.1 ? I typically do not backport functionality but if you feel this should please send a request to the PMC mailing list. Please provide a N&N entry for this.
I personally would like to thank Eugene for bringing this issue up and keeping the discussion going. To me the solution from Mickael feels very efficient and simple and sufficient to solve this issue, hence we did not use Eugenes solution. But Eugene get my personal kudos for keeping this issue alive and working on it despite the frustrating experience he had here in this issue. Sorry Eugene for this bad experience.
(In reply to Lars Vogel from comment #100) > I personally would like to thank Eugene for bringing this issue up and > keeping the discussion going. > To me the solution from Mickael feels very efficient and simple and > sufficient to solve this issue, hence we did not use Eugenes solution. > But Eugene get my personal kudos for keeping this issue alive and working on > it despite the frustrating experience he had here in this issue. Sorry > Eugene for this bad experience. +1, Eugene's work brought a lot of interesting ideas and the discussion drove to concrete results. I do not think that the patch I submitted is better than Eugene's work, using the Web Browser was the simplest and fastest solution, not necessarily the best one. At least, it can be a starting point and if someone is willing to introduce a smarter image viewer/editor in Eclipse Platform and use it rather than the browser, I guess it would still be welcome.
Gerrit change https://git.eclipse.org/r/75396 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b61a74493d9b1f2773e288ed0699cb1a83fb49b9
Add a small entry to the N&N https://www.eclipse.org/eclipse/news/4.7/M1/
I requested a backport to 4.6.1 https://dev.eclipse.org/mhonarc/lists/eclipse-pmc/msg02638.html
+1 for downport
New Gerrit change created: https://git.eclipse.org/r/77091
Gerrit change https://git.eclipse.org/r/77091 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=14b6dafe79637d4161658cb849dc02bc014a5ec6
New Gerrit change created: https://git.eclipse.org/r/77100
Gerrit change https://git.eclipse.org/r/77100 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=71b23d69066b121b4845ad6c69c34c144fffa0d2
Downported. Thanks everyone.
Verified with M20160817-0420
