I have a Sikuli script written in java to click the windows start button and then click "All Programs" as appear. The script works absolutely fine on my computer but when I transfer the same script to another computer, it doesn't work.
Code:
Screen screen = new Screen();
screen.type(Key.WIN);
screen.click(IMAGE_DIR + "program.PNG");
I used concepts like Wait, Pattern and similar but not able to solve this issue. Not sure if this is a limitation of sikuli.
Like was already mentioned in the comments, differences in screens resolutions will definitely ruin your existing scripts as Sikuli is super sensitive to them. In such case, the only solution is to recapture the patterns and use a different set of them on each machine.
However, if you have such issue but screens resolutions seem to be identical, there are few more things that should be checked.
Clear Type, which is Microsoft's implementation of subpixel rendering that is supposed to improve the fonts visual appearance. If you have this feature switch on on one machine and switched off on another, that might be an issue.
Smooth Edges of screen fonts setting that can be found in the "Visual Effects" settings window in "Performance Options". It does exactly what it says, smooths windows fonts to improve the looks. As in the case of ClearType, this feature should be switched off or on on both machines you run your scripts on. The general recommendation to have the always off to avoid this kind of issues.
For those still using Sikuli and experiencing inconsistency when running across different machines, it's helpful to debug on the boxes that are showing the issue.
Some things like issues around various AppData temp files not being managed correctly can show up in some PCs but not others. It's a pain to install your IDE into different places but it sometimes is the only way to really see what's going wrong - and be able to fix it.
Related
I have a Java/JavaFX application deployed as a native install for Windows and Mac. The bundled runtime is currently 8.121. You can find the installers and the Java code here: George download
I have been using this application in the classroom weekly (with 20 children) for the last 15 months, and right from the start I have seen the following problem:
From time to time, buttons disappear. That is to say, they are simply rendered as a white rectangle, making them effectively almost invisible. Both the background and label/text disappear.
This mainly happens on mouse-over, but then does not correct itself.
The buttons are still there, and clickable.
It only happens sporadically, but it seems to recur on certain machines more than others. Windows 10 now, but used to the same happened on tiny Windows 7 machines previously.
I am not able to reproduce it myself and have never seen it on a Mac, I think.
It now also happens sometimes with other widgets/controls, and even before any user interaction.
Is there some known issue around this?
Has anyone else described something similar?
Might it have something to do with certain minor operating system adjustments?
Any thoughts or ideas would be much appreciated.
Update (2018-11-06)
Just started testing my application in Java 8 in VirtualBox with Windows 10, and I now get the rendering error myself. Hurra!
Looking into the -Dprism.xxx options, I found this article:
http://werner.yellowcouch.org/log/javafx-8-command-line-options/
Testing with -Dprism.threadcheck=true, I get a lot of
"ERROR: PrismPen / FX threads co-running: DIRTY: false" with stack traces.
Setting -Dprism.dirtopts=falsedoes not solve it for me, though.
But running with -Dprism.order=sw does. But this is not a good solution for an application that may do some demanding rendering (Turtle Geometry).
Will keep digging.
I've been having the same issue, I tried updating to Java 10 but the issue remained. I then edited the properties on java.exe and on the 'Compatibility' tab I set 'Override high DPI scaling behavior' to 'System (enhanced)' and the problem seems to have gone away (or at least it hasn't happened again yet).
I observed the same thing: Visually disappearing (but still functional) buttons and other controls (except labels) especially in areas outside the original size of the window after I have resized it manually)
In my case -Dprism.dirtopts=false reduced the problem but also didn't solve it (and was not really a satisfying solution anyway).
Additionally I observed that some TextField controls also showed rendering glitches (looked like the same text was rendered twice with a little offset). That finally put me on the right track:
It turned out to be just a missing Platform.runLater(...) around some calls to TextField.setText(...) (from another thread) for exactly these TextField controls, which was causing this (even for e.g. a Button which is at a totally different place - also in the widget hierarchy).
I know, this is probably not the answer in all cases, but hopefully it helps at least some others facing the same problem (took me a full day to find out).
High resolution screens are old news, but for some reason we (and the Eclipse guys) ignored them until now. Well, we can't any longer.
What we want to do is create Eclipse applications that work for "normal" displays, but for high resolution ones, too. Right now the icons are way to small to see or click.
This bug links to this (rather sparse) documentation states we only need to use a new constructor for Image. Okay, so we need to create our own implementation of ImageDataProvider.
While that might work for the images we created ourselves, it does not work for the main tool bar icons.
So let's say we'll start a completely new application from scratch: how would we set up everything to make the toolbar work with the new API and so with all kinds of screens?
(There is a similar question, but it's from the perspective of an Eclipse user, while this question is from the perspective of a developer of an Eclipse application.)
When HiDPI mode scaling is in use anything using ImageDescriptor.createFromURL to load images will look for a image with #2x or #1.5x appended to the name depending on the current scaling (so, for example, remove.png and remove#2x.png). This is used to create an ImageDataProvider.
Eclipse will use this for the tool bar images and many other things.
I have made a Screen Recorder using Java Swing and Xuggler 5.4. I have developed it in Windows 8 64 bit. It's working excellent for Windows. But at client side on Linux's environment , nothing is working. I have searched thoroughly but not getting any solutions. I have checked this thread , but it didn't work for me.
Then I tried to create simple Transparent window in Linux but it's also not working. I was not able to click through the Resizeable Panel. I have used the same JRE version (1.7) for both. Have I miss understood Java's Cross Platform Support as far as Swing is concerned?
Please Give Me Some Advice...
I have always found logging to be the best debugging tool at your disposal! Many a times, java debuggers take you into APIs where you need not go every time. Logging values of your variables, and generic 'I have reached till this point' statements make life a lot easier.
So, I suppose you have ample logging done in your code. That could give you clues on what's happening on your client's system.
Are the right environment variables set? Are they pointing to the correct Java versions you need.
If there are some specific Screen capturing requirements(plugins / modules / API) your code has, are they available on the Linux m/c?
Like #MadProgrammer said, in the end, Java has to talk with the native graphics APIs to render your screen.
I would try to debug it in this way -
Check whether my main screen loads or no(by disabling the screen capture functions for a while).
if not, dig deeper.
Check whether all necessary components for capturing screen(audio and video) are available.
Check whether the code is being run with appropriate permissions to control the h/w devices you may need.
Short Story: My house was broken into MacBook Pro among stolen items. Bought a new MacBook restored from TimeMachine drive including Eclipse folder. System files could not be restored because hardware was slightly different. I did a system update and updated to 10.6.5 and Java 1.6.0_22, all the latest. I run Eclipse Helios for Java development for college assignments.
The problem I am having is that when I run Eclipse and start coding when I get to a method of any type when eclipse usually throws up an auto-complete type box underneath the current line the program hangs for a few seconds while it loads / moves through the list depending on how fast I am typing. Example:
JTextField txt = new JTextField();
txt.get....
I could type the second line out pretty quickly as I know what I am looking for but the program will hang (multicolor swirly mac icon will replace pointer). Eclipse process will spike to 100% and I will not be able to do anything until the auto-complete box finishes whatever it could possibly be doing and the suggestion moves down to "getText()" or whatever the list beginning with "get" contains.
Things I have done to correct include, re-downloading and installing eclipse into another location, creating a new workplace in that eclipse install, re-creating the projects and code files by hand (i.e. not importing anything). The problem still persist.
I am not seasoned enough in Java to abandon the helpful suggestion box, especially when I am learning new things.
Anyone else experience this problem or know a possible solution I have not tried?
This happens with me with Android development, and I have a clue as to why - documentation! If I uninstalled the documentation, meaning the completion list wouldn't show me any API documentation, the completion list was back up to normal speed. Installed it back, the completion list is slow again. This wasn't a problem in Galileo, just Helio.
I'm trying to find the best JVM settings to use with eclipse to see if I can improve things.
Some swing code I write in my computer behave different on my colleague's computer, and in my PC, and in my notebook.
I wonder, is there something I can do to my Swing applications behave the same in every computer?
I want to have sure a algorithm I've tested in my computer will work the same way in my clients computers.
E.g.
Problem to focus JTextField works fine in my notebook with Windows XP, but not in my collague's computer with Windows XP, nither in my work computer with Ubuntu.
obs. the specific JTextField problem is not the subject of this question.
Problems with Swing apps on different platforms are common and they are caused by the simple fact that no matter what level of abstraction Java offers it has to play ball at some point with the native components of the underlying operating system. Event though Swing only uses the windows(frame) and draw everything by itself - discrepancies are very very common.
I develop a mutliplatform Swing application - and users on Windows are reporting all sorts of issues that Linux users don't have and vice versa. Sadly there is no silver bullet for such problems - extensive testing and nasty fixes are the only game in town.
And everything come exceptionally buggy and dirty in the area of pluggable look and feels. For example - resizing a JSplitPane with metal or nimbus is super fast(as expected), but if you use GTK+ plaf, everything goes to hell. This is a more serious(performance) problem - visual problems(missing borders, components not fitting properly containers, etc) have no end... Despite all of this Swing continues to be one of the best bet for multiplatform desktop applications.
I wonder, is there something I can do
to my Swing applications behave the
same in every computer?
I'm working on a complex Java Swing app that is shipped on OS X / Windows / Linux so just like Bozhidar answered, the issues are all far too real.
For some components, if you happen to have some UI design/programming skills, you can simply write your own component: I realize it's probably not a helpful answer, but it works.
For example, we wanted a drop-down "find-as-you-type" popup list (like the one that appears when you start a search on Google's main search page) that would look and work the same on Linux/Windows/OS X. After trying countless of "solutions" full of Swing idiosynchrasies that would not work everywhere (like, guess what, focus issues ; ) we decided to simply write our own component "from scractch".
We can intercept mouse and keyboard events on both OS X / Windows / Linux: we can write a component that not only looks but also behaves identically on all three platforms.
In addition to the "find-as-you-type", we also wrote our own tooltip-popup component, a dual progress bar (to progress bar in one to show producer/consumer style progress in a single bar) and a complex component involving several "text fields" which was absurdly complex and broken when we tried to do it using Swing (and broken in different ways on different platforms, like weird focus issues or caret not showing, etc.). So we "went dirty" and rewrote the entire component ourselves.
Result? Working identically on all platforms where Java can give you notifications about mouse and keyboard events...
I realize this may not be what you want to hear: I happen to have worked on both games UI and mobile apps UI back in the days and I have some graphic skills so it's not "hard" for me to write good looking UI components.
Sadly if you want some Java UI component to look and behave identically on all platforms, it's sometimes your only alternative...
I want to have sure a algorithm I've
tested in my computer will work the
same way in my clients computers
An "algorithm" should work fine.
You get problems when you rely on the ordering of events, which may be different on various platforms. One of the most common I know about is holding down a key so that is repeats:
a) on Windows you get keyPressed, keyPressed, keyPressed, .... keyReleased.
b) on Unix you get keyPressed, keyReleased, keyPressed, keyReleased ...
By the way a comment would be nice as to whether my suggestion in your "textfield" posting works or not. As I mentioned, I don't have a Ubuntu platform to test it on, so I'm curious as to the result.