For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!
Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.
Is there a way to disable this?
Kind regards
No, but the immediate feedback is that it's too big/jarring/not good.
So we'll tweak this for the next EA drop and you can let us know if we're getting closer to perfect.
Even if you make it small, it's so painfully distracting to have this thing show up whenever you open another tab in the table browser! I'd understand if I were running a long query, but most of the times every tab is displayed in a tiny fraction of a second (only DDL generation may take a few seconds...). A screen fade+rotating animation is really unnecessary for such sub-second waits.
At least please disable this thing for sub-second queries. We just don't need it!
Yeah, maybe leave it on and make it smaller, but add a preference so it can just be turned off.
Hmmm, it already has a delay. Will double-check that it is indeed working.
You shouldn't see any visual effect or task dialog at all for short running tasks. I'll check tomorrow.
o Bug 20198279 - 4.1 EA1 - LOADING ANIMATION VERY LARGE
- Fix error to really delay presentation of any task dialog or loading animation for background tasks (was instant in some cases)
- Delay is 1sec based on Response Time Limits: Article by Jakob Nielsen
I second the notion for an option to disable it. I already know my IDE does something if I started the action myself; I don't really need a pointless full-screen indicator obstructing other things I might take a look at instead.
Wait for the 2nd EA drop and reconsider.
There's nothing to obstruct, the animation only appears while the UI is unavailable for clicking/typing.
Sorry to be so blunt, but this animation is absolutely horrible. When I saw it the first time I thought that it was some flash animation popup appearing from somewhere else...
Please just replace it with a plain vanilla busy mouse cursor like in every other application or at least give us the option to disable that turn wheel.
I appreciate your efforts in making SQL Developer more fancy, but when I see this busy indicator I feel like I am operating a flash animation and not a high sophisticated development tool.
cheers
This will be what you see in v4.1, EA2
so, it will have 3 indications, instead of one ?
1. Background screens will be unclickable and color change
2. spinning wheel
3. Running bar
Raj
Looks much better, thanks for the info
Although I guess it's a bit overloaded to have a spinning wheel plus the load bar indicator. Maybe just the grayed out background + the load bar would suffice?
We have multi-threading in the app, but only a single thread for the GUI tasks.
So the task progress is speaking to the work being done by the bg thread.
The screen going dark with the active widget up top, tell you that the GUI is busy and unavailable for interaction.
You'll only see the latter when the GUI is unavailable for more than a second.
OK, so EA2 is here, and the indicator is smaller and overall much better. However, you stated it should have a delay before appearing, and that doesn't seem to work properly, unfortunately. When opening the table, I get to see the table contents and single "bar" of the turning wheel, not moving, appearing immediately. It holds UI unresponsive for about a second, then screen flickers to dark and back, and I can work with the UI again. Much better than it was, yes, but that flickering is pretty annoying. I don't think it should even start unless UI is busy for at least a second, yet it clearly starts immediately.
See the attached GIF. Is it supposed to be like that, or something is going wrong?
Either way, the UI isn't avail. Showing the 'spinning wheel' doesn't make the UI 'not available' in and of itself.
If we increased the delay, that's not going to speed up the UI.
Ok, UI wasn't very responsive before so it's fine (though I don't understand what is it so busy with once it has fetched all the necessary data), but why does it have to flicker, or, for that matter, appear at all if the UI is not busy for certain time? It's distracting, and distractions are the last thing any programmer would want in their IDE, whatever the language, trust me on that.
FWIW, I've asked the dev to look at your video and another pass at this. I agree that the UI shouldn't be distracting, but this is borderline subjective. I guess it's more of a problem if you see it ALL THE TIME - do you have a slower/wider network? We won't have another EA mostly likely, so we'll try to have this polished for the official release and you can take another look then.
Thanks! At least it won't go unnoticed, that's really good to know.
Yes, the real problem is that I see it every time I do anything to the table, not just when IDE starts to "think deeply" about something. It actually sometimes looks like the wheel fires after SQLDev is done with whatever it's doing. Another assumption, with flickering in mind, is that the wheel doesn't stop until it reaches the delay and the display starts turning black. That's probably an illusion, but take another look at the video, please: column data is fetched instantly, it appears virtually at the same time as the wheel starts to turn, and then nothing happens for a second; same for table data. I'll make some time tomorrow and experiment a bit; I'm pretty sure UI in 4.0.3 was ready faster than that, but I'll have to check more thoroughly before claiming anything, I guess.
Network speed... well, I have our database server physically located a few dozen meters away from me, with full 100Mb local network connection. There is some routing in-between, sure, but I can't call it slow, not at all. Only thing faster than that would be a copy of database directly on localhost, I guess, but I don't have the time/resources to try it out, sorry.
Also, actually, I'm fine with the wheel, tiny indicator at the top is not at all that distracting; what I'm NOT fine with is screen turning dark for a split second and then back. It's not as bad in the gif as it is in the real life, but still visible - it's the flicker that happens as the wheel vanishes - and that IS as distracting as it can get. If nothing comes out of the developer investigating the issue, can I at least ask for an option to turn that dimming off, please? I'm fine with the wheel itself and with blocked UI.
As a side note, that would be funny, but could it be that gradual screen dimming is somehow graphics-intense? The only thing that's not fast enough on my working PC is the video card, it's an old GF6600 I bought for the sake of having a decent DVI output. Should still be better than an integrated video, but who knows. That's just a thought, of course.
P.S. I know you're probably not in the position to decide anything, but I really, really wish SQLDev could adopt the practice of periodic "nightly builds" with zero warranty, just to have enthusiasts test out bugfixes and new features all over. Fix a bug, test it, then push a build and give the bug reporter a chance to try and reproduce it again. It's a bit more hassle to maintain, but is actually a win-win approach for both devs and users.
We have indeed talked about pushing builds more frequently. And with the introduction of our new SQLcl resource, we'll definitely have more frequent updates to that to accommodate our rapid bug fixing schedule.
Ok, I got some time and tested things somewhat. Sorry, but I have to get annoying: whatever was done to 4.1.0 table UI made it less responsive.
What I did first.
Test sequence: Scott.emp, "table data" sheet. Repeatedly pressing ctrl+R, then rapidly clicking on the cell until it becomes highlighted. Not the best test out there, sure, but the differences are visible to naked eye, all inaccuracies aside: 4.0.3 is more responsive. Some automated UI tester would be better, sure.
Check the gifs. Ctrl+R results in screen blinking
4.0.3 (moved to java 1.8.0.40, to exclude java version as the factor)
4.0.1, on the same java version and same machine:
Both delays are short enough as absolute values, yes, but consider that said delay occurs at every single operation on the table UI, including commit, rollback, filter, requery and even on fetching the next N rows, and that applies to reports as well - in other words, it happens pretty often, so even half-a-second delay difference can stack up to a dozen minutes per day wasted, which isn't very nice. Also, 0.5 second delay doesn't really register in my brain, but 1 second delay does, and that makes 4.1.0 feel somewhat "laggy". That is, of course, subjective, but I think that if I was able to perceive that, others would be too.
Sorry if that got off-topic, whether this is related to the "wheel" I can't know, but that clearly needs some attention and wheel was the only visible UI change in 4.1.0.
But that's not all, actually. You said UI is not ready until the wheel is gone, but take a look at next gif. I figured mouse clicks would not be a reliable test, so I tried pressing Ctrl+R followed by pressing left/down arrows immediately, and...
this is what happens. I am able to interact with table UI using keyboard even while the wheel is still turning. How come I can't interact with the UI using mouse until the wheel is gone, but can do it just fine using KB? Interaction is not even limited to moving, I can edit the contents, insert rows with Ctrl+I, copy/paste etc.
Also, the seemingly same table control in worksheet query results doesn't lag at all.
Nice catch. It was drawing a single frame of the busy animation when the timer ran out even if the task was finished. It won't be doing that any more. -Brian.
Oh, that's cool. At least, no flickering! Were the increased delays (see previous post) also due to that? Can I get a patched .jar to test it out before release, as an exception? =)
Ok so I've been using EA2 for a few weeks now and my conclusion is that I absolutely need to disable this feature. It pops when it shouldn't, sometimes for a fraction of a second. Also, it makes SQL Developer unusable in terminal server, since it's very graphic/bandwidth intensive (this is my biggest beef).
Will we be able to disable it in the final release ? If not we will have to keep the devs on 4.0 or switch them back to our previous tool.
Except for that, we really like this version though, so keep up the good work !
Thanks !
Ok, 4.1.0 fixed at least one thing: it doesn't flicker anymore. That said, I still don't understand how is it that "UI is inaccessible" yet it's possible to fully interact with the editor UI using keyboard, even while busy indicator is on. Are you absolutely sure that showing busy indicator on and off doesn't take MORE time than actual task sql developer is performing? Because it really feels like that, currently. Like the indicator is required to stay on for at least one second, even if the task is already finished.
Actually, like @"2752746", I still want an option to disable it.
please start your own new thread, provide a test case