Screenshot shows in the deskbar, add option to hide it

[scottmc]

When taking screenshot, sometimes it's useful to have the Screenshot app hidden from showing up in the deskbar. Also this option would be nice to have available from the command line for scripting as well.

[leavengood]

I definitely agree with this, but there is a problem because AFAIK, the B_BACKGROUND_APP flag (which keeps the app from showing in the Deskbar) is set as a resource and cannot be changed at runtime. Since sometimes we want to run the Screenshot app like a normal application (to set options in the GUI), it doesn't make sense to have B_BACKGROUND_APP set permanently.

Of course I could be wrong, and even if I am right, this could be a new feature in Haiku to change the app_info at runtime (at least this property.)

[axeld]

Indeed, the application flags cannot be changed at runtime. This is something that could be changed, of course, but I'm not sure it's really needed.

At least in this case, the Screenshot application doesn't really work like I would like it to work; it pretty much works like Ubuntu's screenshot app, though. I would find useful if the UI pops up only *after* the screenshot has been made. It could remember where to put the mouse cursor, it could remember the active window when it made the screenshot, and make all those options changeable for the current screenshot. That would simplify that thing, and would make it much better to use IMO.

For that, the tool that makes the screenshot could be a simple command line utility, that optionally runs the Screenshot application, and gives that one all the info it needs. Only if you run the Screenshot application manually, the application could work similar to what it does now (but could also still quit itself, and run the screenshot command line utility for the shot itself in order to be hidden from the Deskbar menu).

[leavengood]

Replying to axeld:

At least in this case, the Screenshot application doesn't really work like I would like it to work; it pretty much works like Ubuntu's screenshot app, though. I would find useful if the UI pops up only *after* the screenshot has been made.

But that is what it does now...*scratches head*

It could remember where to put the mouse cursor, it could remember the active window when it made the screenshot, and make all those options changeable for the current screenshot. That would simplify that thing, and would make it much better to use IMO.

You would have to elaborate on this, because I'm not sure what you mean. Do you mean the options would include a list of windows on the screen and you choose which one to make active before the screenshot is taken? Also do you really need to restore the mouse position?

For that, the tool that makes the screenshot could be a simple command line utility, that optionally runs the Screenshot application, and gives that one all the info it needs. Only if you run the Screenshot application manually, the application could work similar to what it does now (but could also still quit itself, and run the screenshot command line utility for the shot itself in order to be hidden from the Deskbar menu).

That sounds sort of complicated and circular (the command-line utility calls the app and the app calls the command-line utility), but overall it sounds like it would be better. I'd have to think about it though.

Unless Julun is around and wants to tackle all this himself.

[julun]

Replying to leavengood:

Replying to axeld:

At least in this case, the Screenshot application doesn't really work like I would like it to work; it pretty much works like Ubuntu's screenshot app, though. I would find useful if the UI pops up only *after* the screenshot has been made.

But that is what it does now...*scratches head*

It could remember where to put the mouse cursor, it could remember the active window when it made the screenshot, and make all those options changeable for the current screenshot. That would simplify that thing, and would make it much better to use IMO.

You would have to elaborate on this, because I'm not sure what you mean. Do you mean the options would include a list of windows on the screen and you choose which one to make active before the screenshot is taken? Also do you really need to restore the mouse position?

For that, the tool that makes the screenshot could be a simple command line utility, that optionally runs the Screenshot application, and gives that one all the info it needs. Only if you run the Screenshot application manually, the application could work similar to what it does now (but could also still quit itself, and run the screenshot command line utility for the shot itself in order to be hidden from the Deskbar menu).

That sounds sort of complicated and circular (the command-line utility calls the app and the app calls the command-line utility), but overall it sounds like it would be better. I'd have to think about it though.

Unless Julun is around and wants to tackle all this himself.

I won't find the time to rewrite the tool in the next few month, so if there is some space left beside the browser project, just go ahead.

--Karsten

[axeld]

Replying to leavengood:

But that is what it does now...*scratches head*

I guess I could have made that clearer :-)

You would have to elaborate on this, because I'm not sure what you mean. Do you mean the options would include a list of windows on the screen and you choose which one to make active before the screenshot is taken? Also do you really need to restore the mouse position?

Right now, there is a strange "Options" page (that isn't really about options, mostly), and one that actually has something to do with the screenshot made. I would merge the two panels into one, with two different modes depending on whether the Screenshot application was launched, or the Print-Screen key was pressed.

When you press the key, the window should come up (after the shot has been taken), and you should then still be able to select if the whole shot should be saved, or only the (then) active window. Same thing for the inclusion of the mouse cursor at that time. There is no reason to not be able to change these settings afterwards, and it's a lot more convenient to do so after the fact. The screenshot preview should actually show what's saved then (ie. the window only, etc.).

Also, I would make it an option to suppress the window completely, and generally show it to the user.

If you just launch the Screenshot application, it should not show a screenshot preview, because there is none yet. Instead, the delayed screenshot option should be displayed (but not with a simple BTextControl, a slider (or +/- buttons) would be way more convenient here), along with the "Take shot" button.

There should not be this strange duality of the panels; they don't go along with each other well, and don't have much to do with each other, either, ATM.

That sounds sort of complicated and circular (the command-line utility calls the app and the app calls the command-line utility), but overall it sounds like it would be better. I'd have to think about it though.

It's definitely circular, but it's not *that* complicated and would get the job done, at least :-)

[Wim]

I have started work on an enhanced Screenshot application taking the discussion here and the one in ticket #3813 into account. I am facing some difficulties though, and would like some advice:

Remember the active window
In the current application the active window is determined using get_window_order and get_window_info function calls, which in turn use a AppServerLink, and as far as I can tell this requires a ServerApp object, which means that a BApplication object needs to be created. So I guess that the command line utility that takes the screenshot needs to be a BApplication for this to work, is that right?

Remembering where to put the mouse cursor
As far as I can tell, there is currently no way to get cursor information (size and position). The ServerApp class has a CurrentCursor funtion, but I can see no way to call that function from an application. I guess the best way would be to define a AS_GET_CURSOR message to be handled by ServerApp that sends the cursor position and size information back in a reply. Is it ok to patch the ServerApp this way, or is there a better way?

I am also not sure if this is the best place to discuss this, maybe I should post a message on the haiku-development list?

[stippi]

Yes, a BApplication is needed in the command line version.

I would not mind an addition to the global interface kit methods which returns the current mouse position along with the currently pressed buttons.

[axeld]

Nice to see you working on this!

/src/add-ons/tracker/mark_as/MarkAs.cpp contains a hack to retrieve the current mouse position. However, as Stippi mentioned, adding that functionality as part of the app_server communication makes more sense, and I also would argue that it would make sense to have this function available from InterfaceDefs.cpp|h.

It should be two different commands, though: one to get the current shape of the cursor, and another one that returns the information that BView::GetMouse() would, only without a BView, and with global coords.

[Wim]

Replying to axeld:

Nice to see you working on this!

Thanks.

/src/add-ons/tracker/mark_as/MarkAs.cpp contains a hack to retrieve the current mouse position. However, as Stippi mentioned, adding that functionality as part of the app_server communication makes more sense, and I also would argue that it would make sense to have this function available from InterfaceDefs.cpp|h.

It should be two different commands, though: one to get the current shape of the cursor, and another one that returns the information that BView::GetMouse() would, only without a BView, and with global coords.

Thanks for the suggestions. I agree that it makes sense two have two functions. About the function that returns the cursor shape, I suppose that it should return the mouse shape as a bitmap, and also the cursor hotspot coordinates, right?

[Wim]

I have created a new ticket (#5978) to deal with the work on the app_server.

[Wim]

Fixed in hrev37017.