Create draft for Unconference report #53
Conversation
| There was discussion about various platforms and build system, and the difficulty of having to eg write Java code for an Android port, and whether anyone wanted to take responsibility for maintaining that glue layer for the rest of the ecosystem. | ||
|
|
||
| Unfortunately the discussions on this subject didn't really go anywhere, as far as I could tell. | ||
| Packaging Rust apps is still very much an open problem. |
There was a problem hiding this comment.
In general? Or just on mobile etc?
There was a problem hiding this comment.
To be honest, I dropped out of that discussion pretty quickly. I think someone else than me would be better placed to summarize it.
There was a problem hiding this comment.
For the Android-specific Java build, I've published the android-build crate under Project Robius.
We started some work on packaging Rust apps as of last week, but nothing there to share yet. Unfortunately David, who was working on this, has recently decided to leave the project, so packaging/bundling work has been stalled a bit.
Co-authored-by: Alice Cecile <[email protected]>
|
|
||
| ### Winit | ||
|
|
||
| By now all of the Rust ecosystem has firmly converged on [`winit`](https://github.com/rust-windowing/winit) as the windowing platform-abstraction solution of choice. |
There was a problem hiding this comment.
I think Tauri also still uses TAO, although afaik they hope to use upstream.
|
|
||
| - [winit](https://github.com/rust-windowing/winit) for creating windows. | ||
| - [AccessKit](https://github.com/AccessKit/accesskit/) for plugging into accessibility APIs. | ||
| - [Parley](https://github.com/linebender/parley) for rendering text and as a basis for a text-editing widget. |
There was a problem hiding this comment.
Afaik, rendering is out-of-scope for Parley, although I haven't dug into it too much.
Co-authored-by: Alice Cecile <[email protected]>
Co-authored-by: Daniel McNab <[email protected]>
Co-authored-by: Daniel McNab <[email protected]>
|
@alice-i-cecile @emilk @jkelleyrtp @DogeDark @kevinaboos @eddybruel @makepaddev Could you confirm that the "Corporate funding" is currently accurate?
|
|
Also @hecrj, pinging you to confirm, is this paragraph currently accurate?
|
|
@tronical Same question. |
|
@PoignardAzur System76 does not directly fund iced development (i.e. me). They fund the development of a fork (maintained by them) with occasional contributions upstream. iced is mainly funded by Kraken. |
Regarding #53 (comment) , yes, that seems accurate. We were not present at RustNL (time constraints). cc @ogoffart |
|
accurate
… On 10 Jun 2024, at 15:00, Olivier FAURE ***@***.***> wrote:
@alice-i-cecile <https://github.com/alice-i-cecile> @emilk <https://github.com/emilk> @jkelleyrtp <https://github.com/jkelleyrtp> @DogeDark <https://github.com/DogeDark> @kevinaboos <https://github.com/kevinaboos> @eddybruel <https://github.com/eddybruel> @makepaddev <https://github.com/makepaddev>
Could you confirm that the "Corporate funding" is currently accurate?
Corporate funding
For open-source projects, "Who funds this" is a difficult question: in any healthy project, there is a large scale of contributions, with individual non-corporate contributors at one end, and companies paying cash to the project's treasury at the other.
In-between are self-employed people like me contracted to work on an open-source project, and corporate employees who contribute to the project as part of their 9-to-5 job.
Some monetary contributions can also come from individual non-corporate donors: Servo has about fifty of them, for instance.
With that in mind, some notable sponsors for projects represented at the Unconference were:
Google Fonts: Linebender projects.
Futurewei: Dioxus, Makepad, and Servo.
Embark: Bevy, winit and rust-gpu.
Foresight Spatial Labs, MeetKai, Encultured and a few others: Bevy.
Igalia: Servo.
Wyeworks: Makepad.
Rerun.io: egui.
Not present at RustNL but relevant to the ecosystem are System76 (funding iced and COSMIC-Text) and Slint who are self-funding as a startup targetting embedded UIs.
Overall the number of different backers feels like a symptom of a healthy ecosystem: while some large corporate sponsors bring much more resources than others (Google and Futurewei especially), the ecosystem isn't in a state where any specific backer pulling out would completely collapse progress.
—
Reply to this email directly, view it on GitHub <#53 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3REHBYNTZP3IF3Z2UT4X3ZGWPNBAVCNFSM6AAAAABIPFX4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYGI4DKMRRGU>.
You are receiving this because you were mentioned.
|
|
My understanding is that much of Igalia's work on Servo is ultimately being funded by Futurewei (with some funding also coming NLnet and Github/OpenCollective donations to the Servo project). I'm not sure if they're independently putting money into the project. @mrego may be able to give you more accurate information on the Igalia/Servo funding situation. |
| I'm not sure the self-organized format worked well. | ||
|
|
||
| From what I saw, the Embedded team took well to it, and the Rust team was kept productive thanks to Alice Cecile's efforts in marshalling everyone. | ||
|
|
||
| In the case of the GUI team, people were spread in a very large room, which should have been conducive to small side-discussions and people splitting up to talk about the problems that interested them. Instead, there was an unspoken accord to progress through agenda items one by one, with a few people dominating the discussions on these items. | ||
|
|
||
| Because those people we spread around a large room, they had to talk loudly to address each other, which left little room for side-discussions. | ||
| Because the people talking were naturally the more confident and extraverted, more introverted people ended up taking a passive role in the discussion. | ||
|
|
||
| To me, this feels like a strategic mistake. | ||
| It was a setup that encouraged bikeshedding and long back-and-forths, and discouraged plurality of opinions. | ||
| It's no coincidence that the most interesting conversations of the Unconference happened at lunch: lunch was the point of the Unconference where people were most mixed, had the most spontaneous conversations, and were least constrained by having to follow what someone else was saying. | ||
|
|
||
| Our discussion were still productive, I just feel like the format could have been improved. |
There was a problem hiding this comment.
thanks for the critiques and feedback here; we'll definitely incorporate this and the other feedback we received for next time.
Regarding the agenda/topics/structure, given the total absence of replies to my requests before the unconf, I felt like I had no alternative but to bring up the suggested topical agenda and steer everyone through it at the top of the actual unconf proceedings, in order to ensure that nobody's views/issues got excluded. Hopefully, with more time to plan ahead of future unconfs (and ideally some additional participation from UI experts in the planning phase), we can receive more input from the attendees and come up with an agreed-upon agenda before we actually meet.
There was a problem hiding this comment.
The web engines hackfest had people suggest breakout sessions as github issues (https://github.com/Igalia/webengineshackfest/issues). These were then scheduled prior to the start of the conference (which some room for reorganisation) and people could choose which sessions they wanted to attend. I think this is quite a good way of doing it as it allows everyone to participate in negotiating session content rather than putting everything on a central organiser. I think you're bound to not get much in the way of responses if people are asked to submit privately.
Not blaming you - it's a learning experience for everyone - and you at least stepped up to try and organise things. But some suggestions for next time :)
There was a problem hiding this comment.
suggest breakout sessions as github issues
that's a good idea!
you at least stepped up to try and organise things
i was "voluntold", haha, but yea, someone's gotta do it
|
thanks for the nice summary, overall it's a great writeup! I left a few comments (apologies if I came off defensive 😅, I really don't mind the critiques of the unconf organization). |
In accordance with our markdown formatting guidelines. Co-authored-by: Daniel McNab <[email protected]>
Co-authored-by: Aaron Muir Hamilton <[email protected]> Co-authored-by: Daniel McNab <[email protected]> Co-authored-by: Alice Cecile <[email protected]>
|
I think the article is ready to publish now. |
|
|
||
| By now all of the Rust ecosystem has firmly converged on [`winit`](https://github.com/rust-windowing/winit) as the windowing platform-abstraction solution of choice. | ||
|
|
||
| (Well, not all! [One small project](https://github.com/makepad/makepad) with indomitable maintainers still holds out against the invaders.) |
There was a problem hiding this comment.
In what sense do you mean "small" here?
There was a problem hiding this comment.
It's an "Asterix the Gaul" joke.
|
|
||
| (This might sound like it contradicts my section about structurelessness above. | ||
| It doesn't. | ||
| I'm not saying organizers should have pushed harder for accessibility - they did try - I'm saying that we should strive for a culture where framework developers think about accessibility without waiting for someone to tell them to.) |
There was a problem hiding this comment.
Definitely agree on this point - I was pleased with how Kevin pushed for Accessibility to be discussed, but am disappointed that it didn't catch.
| ### Requests for Rust features | ||
|
|
||
| Jon Kelley, the creator of Dioxus, had [a laundry list of features](https://dioxus.notion.site/Dioxus-Labs-High-level-Rust-5fe1f1c9c8334815ad488410d948f05e) he wanted from the Rust language. | ||
| That list was later [filed in the Project Goals repository]((https://github.com/rust-lang/rust-project-goals/pull/10)). |
There was a problem hiding this comment.
What do the doubled brackets here represent? They seem to stop the link being rendered on GitHub - is that intentional?
|
|
||
| ### Requests for Rust features | ||
|
|
||
| Jon Kelley, the creator of Dioxus, had [a laundry list of features](https://dioxus.notion.site/Dioxus-Labs-High-level-Rust-5fe1f1c9c8334815ad488410d948f05e) he wanted from the Rust language. |
There was a problem hiding this comment.
Is there an advantage to linking to both the document and the PR? It seems to me that the PR (/where it is merged into) is the canonical reference.
|
|
||
| - [winit](https://github.com/rust-windowing/winit) for creating windows. | ||
| - [AccessKit](https://github.com/AccessKit/accesskit/) for plugging into accessibility APIs. | ||
| - [Parley](https://github.com/linebender/parley) for rendering text and as a basis for a text-editing widget. |
There was a problem hiding this comment.
In discussions since the unconference, Bevy has (correctly) decided to go with cosmic-text for text layout.
If you want a third example, I think wgpu is probably a better candidate.
|
|
||
| ### Requests for Rust features | ||
|
|
||
| Jon Kelley, the creator of Dioxus, had [a laundry list of features](https://dioxus.notion.site/Dioxus-Labs-High-level-Rust-5fe1f1c9c8334815ad488410d948f05e) he wanted from the Rust language. |
Co-authored-by: Daniel McNab <[email protected]>
No description provided.