SnipIt Options

[CSM]

Some predictions/statements:

• Before anyone says it, yes, this Widget is a blatant rip-off.
• This has nothing to do with the box.
• My first response to someone will probably take the form of "everyone's a critic"

And now, I present the Widget I call SnipIt. It'll make taking screenshots and doing quick edits much easier*!
* I very much recommend setting the hotkey first.

Some project notes:

• The edit window is not supposed to be a full-blown Paint program.
• The close button hides the Widget and closes the edit window (when in normal mode, it closes the Widget entirely).
• Due to Y!WE bugs, I disable the minimize button in the Konspose.
• Opening the Konspose will cancel any active snipping in progress.

Download SnipIt

(Java is required to run parts of this Widget)

[g6auc]

Crashes immediately on startup on the Macintosh. The crash log is not useful. The crash appears to be caused by the code at line 379 following window.getBestDisplay().
If I change to this code:

CODE

var display = window.getBestDisplay();
var sizes = {
    help: new Point(234,100),
    small: new Point(234,60),
    large: new Point(234,60)
//    large: new Point(display.workRect.height - 100 + 12 - 140,display.workRect.height - 100 - 70 + 6)
};

the Widget loads. I hope that helps - I don't really understand what is going on.

In your code, you use [a, b] = [b, a] to swap the values of two strings - that is not a legal assignment.

I tried to do a snip. Screen dims, I can drag a red rectangle, I see two runCommandInBg calls in the debug window, then the Widget crashes. Again, nothing useful in the crash log.



This post has been edited by g6auc: Jan 16 2009, 01:59 PM

[CSM]

Crashes immediately on startup on the Macintosh. The crash log is not useful. The crash appears to be caused by the code at line 379 following window.getBestDisplay().
If I change to this code:

CODE

var display = window.getBestDisplay();
var sizes = {
    help: new Point(234,100),
    small: new Point(234,60),
    large: new Point(234,60)
//    large: new Point(display.workRect.height - 100 + 12 - 140,display.workRect.height - 100 - 70 + 6)
};

the Widget loads. I hope that helps - I don't really understand what is going on.

I never saw any crashes during testing except when I reloaded the Widget while an alert() dialog was open, and I don't use any alert's in the final Widget. The piece of code there determines the best size for the edit window based on the screen the Widget is on. It might be crashing when accessing the Display object's properties (but I can't tell you why), and that'd be a Y!WE fault, not something I can directly fix.* However, my intention was that for larger screens, a larger edit window (with more space) would be available for those taking large, full-screen, or mult-screen shots. I could fix it to the size that I see on my PC, which avoids using Display there, but that ruins the idea.

* However, I use the Display object further down in the code to set the size of the overlay ... so it could just be a fault of a bad Display returned only for getBestDisplay.

In your code, you use [a, b] = [b, a] to swap the values of two strings - that is not a legal assignment.

? It's valid JavaScript, and I've used it before with Y!WE (meaning it works).

I tried to do a snip. Screen dims, I can drag a red rectangle, I see two runCommandInBg calls in the debug window, then the Widget crashes. Again, nothing useful in the crash log.

The first run-command call attempts to start up a JAR to take the screenshot, after which it is loaded into the Widget and cropped. The second JAR optionally loads the screenshot into the system clipboard (see preferences for turning that off). If either of those crashed, the Widget wouldn't know, except it would never be notified when they finished. So my guess is that some processing done after the shot is taken is causing the issue.

[g6auc]

... I use the Display object further down in the code to set the size of the overlay ... so it could just be a fault of a bad Display returned only for getBestDisplay.

If you care to make some test code, I'll run it for you on the Macintosh.

? It's valid JavaScript, and I've used it before with Y!WE (meaning it works).

JSLint does not like it, and it is obscure.

The first run-command call attempts to start up a JAR to take the screenshot, after which it is loaded into the Widget and cropped. The second JAR optionally loads the screenshot into the system clipboard (see preferences for turning that off). If either of those crashed, the Widget wouldn't know, except it would never be notified when they finished. So my guess is that some processing done after the shot is taken is causing the issue.

If I turn off the saving to the clipboard, the Widget does not crash, and this is what I have in the debug window

CODE

runCommandInBg: java -jar "/Users/xxx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/AutoScreenCaptureUtility.jar" 0 0 1680 1050 png "/Users/xx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/output" tag: screen

The Widget does not re-appear. There is an output.png file in the data folder with a 1680 x 1050 image, much bigger than the red dragged rectangle. There are also two .jar files and an edit.png file in the data folder.

[CSM]

If you care to make some test code, I'll run it for you on the Macintosh.

Alright:

CODE

var display = window.getBestDisplay();
print(display.workRect.height - 228,display.workRect.height - 164);

Let's run this and see if it's as simple as "use it and die".

If I turn off the saving to the clipboard, the Widget does not crash, and this is what I have in the debug window

CODE

runCommandInBg: java -jar "/Users/xxx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/AutoScreenCaptureUtility.jar" 0 0 1680 1050 png "/Users/xx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/output" tag: screen

The Widget does not re-appear. There is an output.png file in the data folder with a 1680 x 1050 image, much bigger than the red dragged rectangle. There are also two .jar files and an edit.png file in the data folder.

Well ... that's really odd. It should reappear with the edit window. It does, however, wait for the Widget engine to signal that the process ended ... if it doesn't ever do that, the Widget won't reshow the window. As to the crash, you could try running the JAR file via command line (using the same code I do) and see if it reports any errors (but the Java code I use should be universal). In light of the fact that it does crash, would it be better (even though it would be different from the real Snipping Tool) to make that option off by default?

Also, the reason I capture the whole screen, is because that seemed easiest. However, I do load it back into the Widget and crop it later, based on the rectangle or free-hand drawing done.

On a side note: Both Java JARs should be 1.5 compatible, and I tried to compile the clipboard JAR for 1.5 compatibility. I hope that's not the issue.

[g6auc]

CODE

var display = window.getBestDisplay();
print(display.workRect.height - 228,display.workRect.height - 164);

Let's run this and see if it's as simple as "use it and die".

If I add the print(..) into your widget after line 379, it crashes. However, if I run;

CODE

var display = main_window.getBestDisplay();
print(display.workRect.height - 228,display.workRect.height - 164);

in Widget Tester, I get 770 834 as the answer, so there must be something wrong with window, not with getBestDisplay().

On a side note: Both Java JARs should be 1.5 compatible, and I tried to compile the clipboard JAR for 1.5 compatibility. I hope that's not the issue.

Well, the Macintosh has Java J2SE 5.0.

[g6auc]

Apart from the issue with window, I can get a bit further if I set the "Do not open edit window after snipping flag. I see:

CODE

runCommandInBg: java -jar "/Users/xxx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/AutoScreenCaptureUtility.jar" 0 0 1680 1050 png "/Users/xxx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/output" tag: screen
runCommandInBg: java -jar "/Users/xxx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/clipboard.jar" "/Users/xxx/Library/Application Support/Yahoo! Widget Engine/Widgets/SnipIt.widget/output.png" tag: copy

The Widget does not crash, but does not re-appear. There is a 1650 x 1050 image in the clipboard, although the Macintosh says "Clipboard contents: Unknown".
I see the completion of the screen and copy runCommands.

If I let it open the edit window, it makes the edit.png, then crashes.

[CSM]

If I add the print(..) into your widget after line 379, it crashes. However, if I run;

CODE

var display = main_window.getBestDisplay();
print(display.workRect.height - 228,display.workRect.height - 164);

in Widget Tester, I get 770 834 as the answer, so there must be something wrong with window, not with getBestDisplay().Well, the Macintosh has Java J2SE 5.0.

I really don't understand what could be wrong with the window variable ... it's just a window. The only way I've ever crashed a Widget related to a window is if I tried to interact with one waiting to be garbage collected, or if I appended (via DOM) a non-Y!WE object (why they never fixed that crash is beyond me, it's so easy).

The Widget does not crash, but does not re-appear.

Correct. In that case (skipping the edit window), it is assumed you also turned on the option "copy to clipboard".

There is a 1650 x 1050 image in the clipboard, although the Macintosh says "Clipboard contents: Unknown".

Ahhh, but Photoshop, GIMP, MS Word ... all of those programs should know what to do with it. The system and simple programs like TextPad, etc. may not know, though, as Windows doesn't let me paste the contents to the filesystem. There is a bug there, however. I shouldn't upload the whole screenshot to the clipboard. I should be cropping it first, then uploading the cropped image. I do things in the wrong order.

I see the completion of the screen and copy runCommands. If I let it open the edit window, it makes the edit.png, then crashes.

Well, if it crashes after making the edit image, then it has to be something related to code called after that point or stuff only shown in the edit frame.

Since I'm not seeing any errors here (or crashes for that matter), the best I can do at the moment is fix the edit ordering issue, and try your print statement thing and see what happens over here. If you can think of any bugs you may have recall being reported on the forums that relate, it would be much appreciated (so I can attempt to work around them). I am also glad the Java programs work (they should).

[CSM]

Version 1.0.4 is up.*

Changelog:
- Images are now properly cropped before being put into the clipboard.


--------------------------------

I was not able to reproduce the print(display. ...) after line#379 crash.
I really wish that Y!WE had been built upon a more platform independent base, so that less time would be spent running around squashing platform specific bugs (though until recently, not even Java had platform independent transparency support for top-level GUI components). I also wish that Y!WE had set up a public bug repo. Even a simple bugzilla would do! (though I can wish for a lot of things, but that doesn't make them happen!)


---------

Bugs fixed but not updated:

- Undo button + Pencil Tool

[g6auc]

Version 1.0.4 is up.*
- Images are now properly cropped before being put into the clipboard.

I've had to re-do the fix at line 379.
I'm now getting the cropped image in the clipboard. It still crashes if i let it try to open the edit window.

EDIT:If I change to this:

CODE

// Define main SnipIt window.
var window = new Window();
window.shadow = true;
if(loc.length === 2) {
    window.hOffset = Number(loc[0]);
    window.vOffset = Number(loc[1]);
    window.width  = 234;
    window.height = 100;
}

i.e. I set the window width and height, I don't need the fix in sizes to avoid the initial crash.

The screen and copy jars are working, as are the Save and Copy buttons. Nothing useful appears to happen with the pencil tool.






This post has been edited by g6auc: Jan 16 2009, 07:28 PM

[Hunter890]

There is a preference to turn off putting the border into the produced image.

[g6auc]

There is a preference to turn off putting the border into the produced image.

I found that.

See the post above, re setting window width and height.

It now seems a lot better. It takes about 4 seconds to capture and copy a snip.
Some sort of audible indication that it has finished would be good (as an option).
The use of escape and cancel is also working. I'm not seeing prompts to save snips before exiting.

When it first starts, I see the text etc., before the background appears. You could delay making the window visible until it is complete.



This post has been edited by g6auc: Jan 16 2009, 08:28 PM

[CSM]

I'm now getting the cropped image in the clipboard.

Good. I checked this, but it's always nice if someone else says it works too.

I've had to re-do the fix at line 379. It still crashes if i let it try to open the edit window.

EDIT:If I change to this:

CODE

// Define main SnipIt window.
var window = new Window();
window.shadow = true;
if(loc.length === 2) {
    window.hOffset = Number(loc[0]);
    window.vOffset = Number(loc[1]);
    window.width  = 234;
    window.height = 100;
}

i.e. I set the window width and height, I don't need the fix in sizes to avoid the initial crash.

Yeah, well, nothing you've done has proven to me this is my fault. I *never* *anywhere* in the code set the size of that window. I always set the *Canvas* size. So by setting the size of that window there like that, you effectively limit the size of the Widget, which would explain why you don't see anything in the edit window!

Nothing useful appears to happen with the pencil tool.

It now seems a lot better. It takes about 4 seconds to capture and copy a snip. Some sort of audible indication that it has finished would be good (as an option).

For screenshot capture, clipboard copying, or both? If I do both, I can have Java (optionally) do Toolkit.getDefaultTookit().beep(), after the screenshot is done (if not copying to clipboard, and skipping the edit window), and after it is copied to clipboard otherwise.

I'm not seeing prompts to save snips before exiting.

They should appear in the middle of the main window, looking like a miniature window, with two buttons. They might be hard to see if you aren't specifically looking for it to appear there (sorry). I tried to make it an independent window with a shadow, but couldn't get it above the main window (and if I used a real alert dialog, I had the same issue).

[CSM]

Version 1.0.5 is up.

Change Log:
- Changed start up behavior, window isn't set visible until after it is painted.
- Fixed undo, so that it redraws *all* of the previously drawn lines, not just their last bits.

Version 1.0.6 is up

Change Log:
- Taking a screenshot is now synchronous to fix issues on slower systems, I hope.

Version 1.0.7 is up.

Change Log:
- The Widget waits until the croping/editing is done before it tries to load the image and the edit window.

Version 1.0.8 is up

Change Log:
- Tried again to fix the image loading, different tactic.
- Added Widget version number to a disabled Widget context menu item.

[g6auc]

Yeah, well, nothing you've done has proven to me this is my fault. I *never* *anywhere* in the code set the size of that window.

This is not a matter of whose fault it is, but what you have to do to get it to work on both platforms. It appears that unless I set the window size, the Widget crashes. If I set it very large, for example 1680 x 1050 (screen size), I can see the edit window and the edit controls, but the help information is miles below the background. You could set the window size dynamically to match the image to be edited. I know that is a pain, but it may be the only way to get it to work.

For screenshot capture, clipboard copying, or both?

Total time for both is about four seconds.

They should appear in the middle of the main window, looking like a miniature window, with two buttons.

I now see them with the window size set much larger. Not a problem.

[CSM]

This is not a matter of whose fault it is, but what you have to do to get it to work on both platforms. It appears that unless I set the window size, the Widget crashes. If I set it very large, for example 1680 x 1050 (screen size), I can see the edit window and the edit controls, but the help information is miles below the background. You could set the window size dynamically to match the image to be edited. I know that is a pain, but it may be the only way to get it to work.

Alright, I'll put watch statements on the Canvas to update the Window size, should work, as I only relied on the window being dynamic (the feature I love comes and bites me in the ass).

Total time for both is about four seconds.

Well, I can offer a setting to have the beep when it finishes the copy-to-clipboard if doing both copying and screenshoting, and beep after the screenshot if not copying to clipboard, then beep after copying to clipboard if using the copy button. All via one setting: "Beep when screenshot or copying is finished" ... I figured with the copying, though, that it would be done by the time anyone had an app open that accepted it ... maybe I was a bit wrong on that assessment.

I now see them with the window size set much larger. Not a problem.

Great.

[CSM]

Version 1.0.10 is up

Change Log:
- Canvas width/height now updates Window width/height to aid in Mac compatibility.
- Preference to beep after copying to clipboard or finishing a screenshot.
(this may cause it to beep after the edit window appears)

[g6auc]

- Canvas width/height now updates Window width/height to aid in Mac compatibility.

It still crashes on startup. You need:

CODE

// Define main SnipIt window.
var window = new Window();
window.width = 234;
window.height = 100;

so that it does not crash before you change the canvas settings.

[CSM]

No offense meant to you, but Mac-version Y!WE must be really messed up if I have to set the size of a window before I can use it. That was one of the great features of Y!WE, that I didn't have to set the size of a frame or window ...


Version 1.0.11 up.
- Mac update again, hopefully final one?

[g6auc]

... Mac-version Y!WE must be really messed up if I have to set the size of a window before I can use it. That was one of the great features of Y!WE, that I didn't have to set the size of a frame or window ...

The problem does not arise in most circumstances, and I have no idea why you were getting it.

Version 1.0.11 up. - Mac update again, hopefully final one?

1.0.11 is fine.