-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Works on Mac :-) --- a few peanuts #21
Comments
Hi RaiMan. Thanks for testing and for the kind words ! It's great that it works - sort of ;-) . The glitches were more than expected as I guess you are the first one to have started Ginj on MacOS :-) Regarding the changes, you are more than welcome to fork the project and propose PRs of course. Your second point is clearly something I overlooked since I've not been in a "first use" case for weeks :-) Regarding your first point, I'm not sure I understand how you get to the dialog being hidden. If you click the "more" button (gear icon), the More dialog should be centerd on screen, and then clinking on 'Exit Ginj' ('Quit Ginj' on Mac) should make the confirmation pop up centered on its parent Window (the More dialog). Isn't that what you are seeing ? : As for the last point regarding position, I think it's important to remember where the user last positioned the star widget (on which screen, on which border and at what distance from the left or top edge of that display). For example, I'm regularly running Remote Desktop to access my computers, and the center of the top border is used by the Remote Desktop "handle", like this: https://www.mandsconsulting.com/wp-content/uploads/RemoteDesktop_FullScreen.png Please don't hesitate to comment, and maybe include a few screenshots. I'm really curious to know how Ginj looks on Mac :-). PS: I'm going to have a look at SikuliX right now :-) |
Thanks for your answer.
confirmed - no problem
yes, this leads to that depending on the star position the dialog is partly behind the star, so that at least at BOTTOM, the dialog has first to be moved, to get the buttons clickable.
I understand your point about modality. In SikuliX for the popups, I create a fake-frame (1x1) at a suitable place and use it as parent to keep the dialog popup modal.
agreed - Of course it is ok and helpful to remember the screen edge, but I think the exact position does not really matter and might make problems in some cases. IMHO using the middle of the remembered edge is ok. Some images about how it looks on my Mac: All the best (will surely come back ;-) BTW: the confirm dialog has |
Thanks for the pics. I get the issue more clearly now.
As I have no access to a Mac, I'd gladly exchange your proposal of writing Pull Requests for the results of those tests :-). If the issue is with the transparent PNGs, the simple solution is to replace the PNG by code-drawn circles, which would be quite easy (it's already in my TODO list in any case). Regarding the position on the border, I think the exact position does really matter because when the computer you remote-control has the yellow icon at the center, it cannot be accessed in full screen mode. Moving it to the left or to the right ensures it remains reachable even with the remote desktop bar on top. But I admit I don't understand the issue with remembering that position... Oh, and did I type Jing - again ? Sometimes I'm getting a bit too close I guess :-P. That's fixed in the code now. Thanks for all ! |
ok, I will now fork the repo and make some tests.
Ok, understood and agreed. But then you should not store the absolute pixel location, but a relative value like |
Mmmh remembering a percentage makes sense indeed. Will do that. Thanks ! |
… changes (e.g. resolution, unplugged monitor) see issue #21
Relative position is implemented. Will be in the next release. |
Excellent, RaiMan. Thanks. |
feel free to come back for tests and/or evaluations |
ok, did it - no change :-( mouse outsidemouse insideBTW: For people like me, having Java available anyways, a
.... and using |
... and about multi-desktop - first impressions:
|
Damn :-(
Err, if I'm not mistaken, that's the Ginj.jar I usually provide, right ? I didn't do it for the 0.3.10-pre because it was not meant to be a release, but for all others, it's available. Or do you mean something else ?
Thanks for the detailed report. That's mostly what I had understood. Anyway, it doesn't look like an easy task, except maybe having a loop forcing "setVisible(true)" every second or so, but that's not something I can test remotely... I'll try to see if someone else has come up with a solution... OK, back to the transparency issue for now. |
Hello. I just released a second "Mac-only" release (dmg or jar) with changes in 2 areas:
So if Ginj runs but you are on a desktop without the widget, could you please open any tray menu entry (e.g "Exit" (then Cancel)) and check that the widget is now on the current desktop.
My hope would be that I understand this looks like I'm asking you to be my guinea pig, so please tell me if I'm bothering you, and already big thanks for your help so far. KR. Vicne (*) To change a setting:
|
No problem - I will do what you want. ... be sure, that I am not feeling like your guinea pig. With SikuliX I am also always happy, if someone else helps me with tests and evaluations (especially on Linux systems ;-) |
(fyi I made one more pre-release that should fix preference file and folder creation upon first use - with no stacktrace if not existing upon load) |
Behaviour after switching desktopwhen clicking a menu entry from tray icon, the star is moved to the current desktop, but the resulting window/dialog is not brought to front, but might be fully/partly hidden behind the frontmost app window, depending on its size and position.
IMHO the best solution would be a hotkey, that moves the star to the current desktop/monitor and makes it the frontmost app. So the app has a consistent start point. |
Thanks for your observations. I'm leaning towards some kind of race condition, due to the async nature of Swing. |
Hi, |
Could you give me the source code of your |
That's just how the unmodified Stackexchange code you tested above in that post behaves on Windows... |
Uups, apparently too hot here these days ;-) Thanks. |
ok, confirmed on Mac: |
:-(. Other topic: do you have any idea how a Process launched from a Java app on Mac can be authorized to capture screen contents ? |
I am sure this can be supported by the macOS Api, but that means fiddling around with JNA/JNI. |
macOS 10.15 - OpenJDK 14.0.2
Via the notifications on https://github.com/tulskiy/jkeymaster I got to your work here.
Congratulations - good stuff and very handy.
I am RaiMan from SikuliX (https://github.com/RaiMan/SikuliX1) and evaluating Ginj, about wether I can use it as screenshot tool (standalone/in parallel/as API).
I downloaded the sources and made my own project (IDEA, Git) for evaluation.
I noticed the following and made respective changes:
the quit confirmation dialog buttons with star LEFT and BUTTOM are hidden by the star window
solution: always display the dialog in the middle of the screen
at first use I got noisy error messages about the settings.pref file missing (load and save)
solution: the error at load should be a warning without stack trace, at first save of the defaults the missing folders should be created
on start-up the star position should always be the middle of the stored edge (star.window.distance.from.corner not needed), for cases of screen changes or manual changes in the pref file
For the first two cases I can give you patch files if you want.
If I decide to continue with the evaluation and usage the next days, I will fork your repo and will then be able to create pull requests.
The text was updated successfully, but these errors were encountered: