-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Abstract information from RFB to the UI #950
Conversation
This interface was a band aid for poor design. The two cases where it was used was replaced by logging.
And make the log message a bit more detailed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Looks good, just some minor questions.
app/ui.js
Outdated
} else if (UI.getSetting('reconnect', false) === true && !UI.inhibit_reconnect) { | ||
document.getElementById("noVNC_transition_text").textContent = _("Reconnecting..."); | ||
document.documentElement.classList.add("noVNC_reconnecting"); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra blank lines in this general area
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove them
vnc_lite.html
Outdated
@@ -200,8 +180,7 @@ | |||
}; | |||
|
|||
function updatePowerButtons() { | |||
var powerbuttons; | |||
powerbuttons = document.getElementById('noVNC_power_buttons'); | |||
let powerbuttons = document.getElementById('noVNC_power_buttons'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bonus change? ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove this change
@@ -11,7 +11,6 @@ | |||
*/ | |||
|
|||
import * as Log from './util/logging.js'; | |||
import _ from './util/localization.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably move localization.js
to the app side of things now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, one small thing to note is that tests/test.util.js is generally written for core/util and will now test app/localization.js as well, but not a big problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or just split that test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, sounds good
app/ui.js
Outdated
visible_status_type = 'normal'; | ||
} | ||
} | ||
if (visible_status_type === 'error') { return; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about if warn
is visible and a normal
wants to be shown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will fix
I discovered an issue with the focus handling that was introduced with the 118d929 commit. It seems like running .focus() on an element that isn't rendered have no effect. I'll just move the focus call to after showing the canvas (like it worked before). |
68c78f7
to
5309a8c
Compare
All fixed now. API documentation still remaining though |
f4a4ffc
to
c4a7b77
Compare
API documentation updated as well now, I'm satisfied. |
Any thoughts @DirectXMan12? |
docs/API.md
Outdated
new connections. | ||
The `connect` event is fired after all the handshaking with the server | ||
is completed and the connection is fully established. After this event | ||
the `RFB` object is ready to recieve grahpics updates and to send input. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good eye
core/rfb.js
Outdated
|
||
let event = new CustomEvent( | ||
"securityfailure", | ||
{ detail: { result: security_result, reason: reason } }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The entire message is called SecurityResult
, but the code field is called status
, so perhaps we should use the same terminology here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed that, I'll change it
docs/API.md
Outdated
property is an `Object` optionally containing the property `reason` | ||
which is a `DOMString` specifiying the reason for the failure. The | ||
server can choose to not send a reason and in these cases the property | ||
`reason` will be omitted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try to make it clearer that this is a server provided message, rather than something internal? Perhaps also mention that the language is not fully known (although most likely english)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will do
docs/API.md
Outdated
property is an `Object` optionally containing the property `reason` | ||
which is a `DOMString` specifiying the reason for the failure. The | ||
server can choose to not send a reason and in these cases the property | ||
`reason` will be omitted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You haven't documented reason
/status
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you mean result
. Yeah, I missed to document that since we don't currently use it in the UI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify; result
which will be renamed to status
wasn't documented
Instead of exposing all the internal connection states, the RFB module will now only send events on connect and on disconnect. This makes it simpler for the application and gets rid of the double events that were being sent on disconnect (previously updatestate and disconnect).
c4a7b77
to
e48dd94
Compare
Fixed all your comments now @CendioOssman, I also found that I had forgotten to add tests for the new |
docs/API.md
Outdated
| `status` | `long` | The failure status code | ||
| `reason` | `DOMString` | The **optional** reason for the failure | ||
|
||
The property `status` corresponds to the *SecurityResult* status code in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users of the API might not be that familiar with the protocol. A link to the relevant section of rfbproto would be nice here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea!
e48dd94
to
65d6a6d
Compare
The API allowed strings to be passed from the RFB module to the application using the disconnect reason. This caused problems since the application didn't have control over translations for these strings. Most of the information being passed using this string was very technical and not helpful to the end user. One exception to this was the security result information regarding for example authentication failures. The protocol allows the VNC server to pass a string directly to the user in the security result. So the disconnect reason is replaced by a boolean saying if the disconnection was clean or not. And for the security result information from the server, a new event has been added.
And only show the first error. This means that if UI.showStatus() is called for a new error while one error is already showing, the new error will not be shown. However, if a warning was showing and a new error comes up, the warning will be overwritten.
Since it is no longer used in core. Also splits localization tests into a separate file.
65d6a6d
to
7279364
Compare
Added a link to SecurityResult in rfbproto for the |
I'll give people until tomorrow to review this, then I will go ahead and merge. |
@samhed @CendioOssman hey, sorry, was out sick. FYI, next week is a holiday in the US, so I'll probably be mostly unresponsive ;-). |
We had a problem with strings being passed from RFB to UI using the notification and disconnect events. These were strings that were intended to be shown directly to the end user. Since these strings were defined in RFB the UI did not have control over translations.
This PR removes the
notification
event, and theupdatestate
event. It adds aconnect
event, asecurityfailure
event, and modifies thedisconnect
event:notification
event was unnecessary and was easily replaced by loggingupdatestate
event was being sent at alongside thedisconnect
event, causing unnecessary complexity for the applications. Applications do normally not have any use for the more detailed internal state information anyway.connect
event that works nicely with thedisconnect
event.disconnect
event no longer includes a reason. Instead it includes a boolean that marks if the disconnection was clean (normal) or not clean (exited with errors).securityfailure
event is now available for applications that want to display the security result failure string that can be sent directly from the server. One example of this is authentication failures.I still have to update the API documentation, but feel free to review.