CroakSplat
Occasional Contributor
Joined 9 years ago
User Profile
User Widgets
Contributions
Improve mousewheel scrolling (currently very slow) when viewing Project or Test Suite component
When viewing the Test Suites list in the Project component view or the Test Cases in a Test Suite view, one is able to use the mousewheel to scroll up and down in the list. This is great. Except! Except that the scrolling is superbly slow. It takes like...5x longer to get where you want to go than it should. In my humbleman's opinion. It would be supremely #sweet if the mousewheel scrolling was more in line with standard scroll speeds for navigating lists of objects.786Views2likes0CommentsRe: Groovy script font - no longer monospace? - pls make it monospace again
Thanks for the response. I played around with the referenced font settings abit between v1.8.5 and v2.4.0, and they seem to be inconsistent, not just between versions (Editor Font applies to Groovy scripts in v1.8.5), but even within versions --- the application of the settings seems sporadic. Within the preferences window itself, the Text Field attribute sometimes applies and sometimes does not.My testing computer is on a non-internet-connected computer so I can't screenshot an example, but I expect it's easy for people to check out on their own. (Note for historians and other readers: I editted the Subject of the original post to be less obnoxious.)7 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.1KViews0likes0CommentsGroovy script font - no longer monospace? - pls make it monospace again
I recently upgraded from an old version (ReadyAPI! v1.8.5) to ReadyAPI v2.4.0, and while there is much to celebrate, I am finding that Groovy scripts are no longer monospace, and I can't find a way to adjust the font setting for these. Neither of > Preferences > Editor > Editor Font > Preferences > Editor >Text Field Font affect font in my groovy scripts. I hereby request that the font for Groovy scripts either returns to monospace or that groovy script fonts become a configurable thing.7 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.1KViews0likes2CommentsRe: I get "Failed to save project(file name):java.io.IOException: No such file or directory"
I recently experienced this issue and it broke down to the fact that I had selected the preference to "create backups of projects before saving" and left the "backup location" field empty. Turns out that ReadyAPI/SoapUI, instead of saving project backup in the same location of the original project file (which would make the most sense, imho...) defaults to saving the backup somewhere in the ReadyAPI/SoapUI install location (or some other unexpected location). Turns outsometimes that location is not writable by the current user (in my case, because only root user had write access). And ReadyAPI/SoapUI doesn't bother to check whether write permissions exist, it just tries to save, and if that fails it send back the error message without parsing it into an intelligent form. Suggestion to the ReadyAPI/SoapUI devs:add a try-catch statement around the code trying to create the backup, and if it fails due to java.io.IOException, let the user know it's an issue with the backup, not with the original; also do an active check on whether write permissions exist there; also, in the preferences window, add some detail that lets the user know where the default backup location is. Also, maybe change that default backup location to the project-dependent ${projectDirectory} location (or whatever that internal property is, I forget); or maybe add that as an alternative---it can default to eitherthe project-dependent ${projectDirectory}, or some fixed location.8 years agoPlace ReadyAPI QuestionsReadyAPI Questions5.7KViews0likes0CommentsRe: Useful API Documentation
Package descriptions are empty excessively often. Class descriptions are empty excessively often. Method descriptions are empty excessively often. Field descriptions are empty excessively often. Basically, where there should be human-written words conveying the intended meaning/use/functionality/etc. behind an item (package, class, method, field, etc?), there is almost always no such words. Compare the level of detail provided by SmartBear for one of SoapUI's core classes: https://www.soapui.org/apidocs/com/eviware/soapui/impl/wsdl/testcase/WsdlTestCase.html with the detail provided for this core class from MongoDB API: https://api.mongodb.com/java/current/com/mongodb/DBCursor.html The difference is incredible. On top of being super helpful, the detailed, thoughtful commentary in the MongoDB API documentation generates the feeling that the developers and maintainers of MongoDB care about their users. I get quite the opposite feeling when it comes to SoapUI. That is what I want to convey. More or less.1.9KViews1like1CommentRe: Useful API Documentation
Not perfect, but they make an honest effort (better than the current SoapUI and SoapUI Pro documentation, in my opinion): http://www.slf4j.org/apidocs/index.html http://junit.org/junit4/javadoc/latest http://javadoc.jenkins.io Decent or downright good (probably something to aspire to): https://commons.apache.org/proper/commons-io/javadocs/api-2.4 http://docs.spring.io/spring/docs/current/javadoc-api https://google.github.io/guava/releases/18.0/api/docs https://api.mongodb.com/java/current http://download.eclipse.org/jetty/stable-9/apidocs https://developer.android.com/reference/android/app/package-summary.html And the Java API itself (very helpful): ... https://docs.oracle.com/javase/6/docs/api https://docs.oracle.com/javase/7/docs/api https://docs.oracle.com/javase/8/docs/api ...1.9KViews0likes3CommentsRe: Useful API Documentation
There should be human-written, descriptive words written for every item in the API docs (or at least all the important items...which is probably all of them). For example, on the base page I linked to before, in the Description column there should be a...umm, what's it called. Oh yes, a description. For every package listed. And when you navigate to a particular class or package, there should be words there, too. Words that help the user understand what all the objects, classes, and methods are for and what they do. Important classes should be well-documented, in particular. For example, https://www.soapui.org/apidocs/com/eviware/soapui/impl/wsdl/testcase/WsdlTestCase.html has only "TestCase implementation for WSDL projects" for documentation. Which I think is no longer even true (I think it's also used for WADL projects, yes?). And the only method that is documented is the moveTestStep method (and even that documentation could be better; what does a positive offset mean? what does a negative offset mean? what happens if you try moving a TestStep by an invalid offset (too large or too small)?). Basically I just think that it would be nice if the API documentation consistently had content beyond the nearly useless Javadoc auto-generated content.1.9KViews0likes5CommentsUseful API Documentation
SmartBear is presumably working diligently at adding comments to their nearly-comment-free, Javadoc-generated API documentation (https://www.soapui.org/apidocs/overview-summary.html). I'm wondering how many [more] years we have to wait for this to be finished?The current version is /nearly/ useless.You...umm, you are working on this, right? and fwiw, happy holidays Edited: link now to point to the free-version API rather than the Pro version2KViews0likes7Comments