-
-
Notifications
You must be signed in to change notification settings - Fork 28
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
First pass at editor GUI #421
Open
kanerogers
wants to merge
16
commits into
main
Choose a base branch
from
kanerogers/issue419
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+3,063
−22
Open
Changes from 7 commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
a80861f
Begin work on editor
kanerogers 774bbf3
Add `hotham-editor-protocol`
kanerogers 153463f
Actually, no bytemuck yet due to dependency hell
kanerogers f9e8325
Get images transferring from server to client
kanerogers f7fa44c
Finish first pass at editor input
kanerogers 2b269f3
Improve input handling
kanerogers a40f408
Fix up input
kanerogers 9b92f67
Begin adding support for JSON values
kanerogers 4219b67
WIP
kanerogers 901a0c9
[Editor] Finish first pass at editor GUI
kanerogers 854282f
Add missing SPRIV files
kanerogers 0253da0
Appease clippy
kanerogers 7269db6
Merge branch 'main' into kanerogers/issue419
kanerogers 16601dd
Specifically allow the editor's SPIRV files
kanerogers a83a36f
Merge branch 'kanerogers/issue419' of https://github.com/leetvr/hotha…
kanerogers 893f1a2
Accept the tyrany of The Republic
kanerogers File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,3 +21,6 @@ sponza* | |
|
||
# Ignore compiled shaders | ||
*.spv | ||
|
||
# Checking in a socket is probably a terrible idea | ||
*.socket |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
[package] | ||
name = "hotham-editor-protocol" | ||
version = "0.1.0" | ||
edition = "2021" | ||
|
||
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html | ||
|
||
[dependencies] | ||
ash = "0.37.2" | ||
openxr-sys = "0.9.3" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
# Hotham Editor Protocol | ||
## Why? | ||
Whenever two programs want to talk to eachother, the most complicated question is *where is the protocol defined?*. Sometimes the protocol is inferred from the way the programs serialise and deserialise their messages, but this leads to all sorts of problems. | ||
|
||
In essence, this is a *contract* problem. What is the contract, where is it, and how is it enforced? | ||
|
||
For more on this topic, we can, as always, defer to [Joe Armstrong (RIP)](https://www.youtube.com/watch?v=ed7A7r6DBsM). | ||
|
||
## How? | ||
Simple. We define: | ||
|
||
- What the messages of the protocol are | ||
- A means to **encode** them to bytes | ||
- A means to **decode** them to bytes | ||
|
||
We can even take that a step further and define FSMs (as Joe would suggest), but that is future work. | ||
|
||
|
||
## Examples | ||
Let's say we're using Unix sockets: | ||
|
||
```rust | ||
let socket = UnixStream::connect("hotham_editor.socket").unwrap(); | ||
let client = EditorClient::new(socket); // woah, generics | ||
|
||
let view_configuration = client.request(&requests::GetViewConfiguration {}).unwrap(); // view_configuration is the correct type!! | ||
``` | ||
|
||
This magic is made possible through the `Request` trait: | ||
|
||
```rust | ||
pub trait Request { | ||
/// What should the response to this request be? | ||
type Response: Clone; | ||
|
||
/// Get a `RequestType` tag that we can use to identify requests | ||
fn request_type(&self) -> RequestType; | ||
} | ||
``` |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This doesn't look portable
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, I'm thinking I should just remove this file from the repo
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'm not convinced the best way forward is to remove the whole file. These settings are good for keeping the files tidy and consistent. Can we at least resolve this in a separate PR?
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 guess the problem is that there's always going to be a case where a developer might have overrides that are unique to their specific environment, right? For me the rust analyzer one is super common that I need per project to avoid locking issues.
I think anything related to style etc should probably best be left to clippy, otherwise there's no way to, for example. get developers who aren't using VSCode to have their code correctly formatted.