Create "three-months roadmap" article #52
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Overall I think it will be really good to share this. A handful of details and potential additions, but nothing huge to change
Also, please move this to one sentence per line, including in the roadmap items; I believe bullet points in markdown properly support non-semantic newlines.
|
|
||
| - **Priority:** Highest. | ||
| - **Assigned:** Olivier Faure, Aaron Muir Hamilton. | ||
| - **Description:** We'd like to bring up Masonry's textbox widget to be best-in-class among Rust frameworks. We want to support native-feeling interactions out of the box, such as cursor movement (go to next word, go to beginning of line), selection (select to end of text) and edition (IME, deleting an entire word, etc). This is something other framework developers have expressed interest in, so we want to implement it in a composable way. |
There was a problem hiding this comment.
One sentence per line please.
Also edition should probably be editing?
|
|
||
| What follows is a comprehensive summary of what exactly we're planning to do. | ||
| We've tried to focus on blockers, where a missing feature in one project is stalling progress on other projects, because those are the hardest barriers to coordination, and we wanted to take advantage of being in the same room together to knock them down. | ||
|
|
There was a problem hiding this comment.
We should probably have a sentence here that this document will not be updated with the current status, and so includes both planned and completed work.
There was a problem hiding this comment.
I see that this is partially reflected in the conclusion, but I still think it would also be useful to have a similar preface
| - **Priority:** High. | ||
| - **Assigned:** Nico Burns. | ||
| - **Description:** Parley currently has virtually no documentation. If we want it to become a fundational crate, we need to explain to people how to use it. | ||
| - **PR:** [parley#26](https://github.com/linebender/parley/pull/26) |
There was a problem hiding this comment.
We really should try and just merge this "as-is"; it's not doing any good just sat as a draft.
| As we fill out gaps in our feature set, Xilem is moving closer to becoming a stable, mature framework for writing GUI applications. | ||
| We're not GUI yet, but we hope we'll be in the near future. |
There was a problem hiding this comment.
This is potentially "promising" more than we're willing to give (especially considering Raph's question answer in the RustNL talk). I like the optimistic sentiment.
I'd maybe rephrase it in terms of "filling out the features needed for Xilem to thrive"?
There was a problem hiding this comment.
I've changed the wording a bit to make it more of a "north star" thing.
PoignardAzur
changed the title
I really don't want to do that unless you think it's critical to stick to this standard. Honestly, I'm skeptical of the one-sentence-per-line rule. So far the only result of that rule for me has been having to rewrite more stuff. I get that it's supposed to make diffs more readable for large paragraphs, but it also makes the document itself less readable and more annoying to write. When it comes to bullet points, writing them as one paragraph is natural and writing them one sentence per line needs even more fiddling. It would be one thing if we had a canonical formatter that applied this rule, or if this was a living document that was going to see more diffs, but it's a blog post that will never be touched again after it's posted. |
|
The one sentence per line thing is mostly for the sake of reviewing - not having it makes it harder to add specific comments about specific sentences, because GitHub doesn't let us comment on a range more fine-grained than a line. It means we have to do really awkward things like quoting a sentence within a paragraph to comment on it. I'm not sure what we want the approval process for this to be; I think it's fine to land as-is, but maybe Raph will want to take a look? |
Isn't it rendered the same as without? Btw. regarding rendering, to keep the link in the first post up-to-date (when the filename doesn't change at least), I'd suggest using something like: (i.e. change the commit hash with the branch name, though this has problems, when it's merged and the branch is deleted obviously) |
|
|
||
| On May 7 and 8, 2024, folks from the Linebender team went to [the RustNL conference](https://2024.rustnl.org/) for two days, followed by two days of Unconference. | ||
|
|
||
| By that point, we all felt fairly exhausted, but Raph Levien being the cruel taskmaster that he is, he still made us work one extra day, and so we came together in our hotel's conference room to discuss the Linebender project, and what we wanted from it. |
There was a problem hiding this comment.
I understand that this is a joke. However a surprising number of people failed to understand that Raph's April 1st C++ post was a joke and that was a much more obvious joke. For that reason I recommend against using our blog for such banter, as too many people will take it literally.
| By that point, we all felt fairly exhausted, but Raph Levien being the cruel taskmaster that he is, he still made us work one extra day, and so we came together in our hotel's conference room to discuss the Linebender project, and what we wanted from it. | |
| By that point, we all felt fairly exhausted, but we still came together in our hotel's conference room to discuss the Linebender project, and what we wanted from it. |
There was a problem hiding this comment.
I'm conflicted on this; I think it's probably right to remove it, but I wish it wasn't 😆
There was a problem hiding this comment.
Yeah, that joke was funnier when I wrote it right after hell week. ^^
I'll soften it a bit, and make the joke framing more obvious.
There was a problem hiding this comment.
(Also, that joke is a lot funnier when you know Raph and how laid back he is, but people reading a blog post probably won't know that, so the framing should be obvious.)
|
I've fixed small errors and sanded down the more controversial/risky bits. I think this is ready to publish now. |
| * Accessibility isn’t just screen readers. Also color contrast, customizing size, IME support, motor disabilities (avoid stuff that requires simultaneous input). | ||
|
|
||
| * “Accessibility is more than adding a dependency to AccessKit” | ||
| * (Olivier: Note to self: include GMTK video about Celeste Assist Mode) |
There was a problem hiding this comment.
Maybe if I get around to writing an article about accessibility. In the meantime, those are unstructured notes.
There was a problem hiding this comment.
File date probably needs to change
|
Will publish this on Monday (and change the date then), to leave some breathing room between the two articles. |
Rendered.