Community
Participate
Working Groups
crop selection in the capture screenshot should be resizeable, so it will be easier to adjust it to the right size/position instead of recreating it every time
I can take a look at this one after bug#206688 is resolved.
I will provide a patch for this.
Sounds great! Assigning to you Willian.
Thanks for your contributions to this wizard Willian! Fyi, I just created bug 209897.
Created attachment 83016 [details] Proposed patch First attempt to add this feature to screenshot editor: - Now you can resize the selection by dragging the grab points. - You can move the selection area by dragging inside the selection. - Fixed a little old repaint bug regarding resizing the window with "fit image" off. - While resizing/moving, the shadow is turned off, so you can see clearly where you are going to.
Created attachment 83017 [details] mylyn/context/zip
Patc happlied. Wow Willian, you're really turning this facility into a first-rate screen capture tool. This resizing is definitely a big usability improvement. In case you're interested in contributing more in this area, we also have bug 195691.
(In reply to comment #7) > Wow Willian, you're really turning this facility into a first-rate screen > capture tool. This resizing is definitely a big usability improvement. In Yes, I think it is very important to have a good screenshot support in a bug reporting tool. I hope I won't have to open GIMP anymore soon just to post screenshots. > case you're interested in contributing more in this area, we also have bug > 195691. > Sure. I'll take a look.
(In reply to comment #8) > Yes, I think it is very important to have a good screenshot support in a bug > reporting tool. > > I hope I won't have to open GIMP anymore soon just to post screenshots. Current dialog-based UI is still quite limited and would be really handy to implement bug 203994, now that bug 78856 (image transfer support in SWT) is resolved in Eclipse 3.4
(In reply to comment #9) > Current dialog-based UI is still quite limited and would be really handy to > implement bug 203994, now that bug 78856 (image transfer support in SWT) is > resolved in Eclipse 3.4 > Sure. It would be quite simple, but I guess it is better to wait until we finish implementing mark/text tool to avoid the merge nightmare, as it would be a 3.4 only feature. Another thing I'm thinking about, but haven't opened a bug for yet, is to rework the attachment workflow, because you can attach a screenshot from a file/clipboard/workspace by using the "traditional" attach wizard, and it would be interesting to offer the screenshot editor capabilities (without the screen capturing tools) if the attachment is an image (actually, it only offers a preview of full image).
(In reply to comment #10) > Sure. It would be quite simple, but I guess it is better to wait until we finish > implementing mark/text tool to avoid the merge nightmare, as it would be a 3.4 > only feature. Heh. That would be sad, because "marking" feature seem complicated enough. Also I am not sure if it is a good idea to turn wizard dialog into the image editor. BTW, speaking of image editors, there is bug 155323 > Another thing I'm thinking about, but haven't opened a bug for yet, is to rework > the attachment workflow, because you can attach a screenshot from a > file/clipboard/workspace by using the "traditional" attach wizard, and it would > be interesting to offer the screenshot editor capabilities Sounds like a good idea, but same concern about image editing in the dialog. To make it usable it should support real undo buffer and allow to edit image iteratively, i.e. workflow like add some markup, type in the attachment description, update markup, etc. UI that does not provide way to make corrections/updates look incomplete and too restricting (so your crop improvements are really big deal).
(In reply to comment #11) > Also I am not sure if it is a good idea to turn wizard dialog into the image > editor. BTW, speaking of image editors, there is bug 155323 Interesting. I'll take a look at it. And yes, I think the idea is NOT to provide a full image editor, but just simple editing capabilities. I think it would not have more than crop/mark and, perhaps, text. So, if you want to apply a gaussian blur before submiting the screenshot, you will still have to use GIMP or Photoshop ;) > Sounds like a good idea, but same concern about image editing in the dialog. To > make it usable it should support real undo buffer and allow to edit image > iteratively, i.e. workflow like add some markup, type in the attachment > description, update markup, etc. UI that does not provide way to make > corrections/updates look incomplete and too restricting (so your crop > improvements are really big deal). > I think this would be better hosted in a true image editor (a real Eclipse editor).
(In reply to comment #12) > I think this would be better hosted in a true image editor (a real Eclipse editor). Exactly my concern. UI should provide enough features, so user won't get into the situation "ups, I made a mistake again, what next, how do I fix it?"
Willian: your current approach of making our screenshot tool editor "good enough" sounds very good to me. We've got it working well for some of the most common use cases. We should not turn this thing into an image editor (e.g. supporting undo or other fancy functionality, and you're right that this should come from a proper editor. If one materializes it can just provide an input to our attachments).
(In reply to comment #14) > supporting undo or other fancy functionality Mik, "undo" is NOT a fancy functionality. It is the most important usability feature.
(In reply to comment #15) > Mik, "undo" is NOT a fancy functionality. It is the most important usability > feature. > FYI, the patch I'll submit in the mark bug will include a "reset" button to restore the image to the initial capture.
(In reply to comment #16) > FYI, the patch I'll submit in the mark bug will include a "reset" button to > restore the image to the initial capture. That sounds like a good compromise Willian. I don't think it's strictly necessary since in the typical work flow (capture -> edit) the user can capture again. But it would be nice to have.
