diff --git a/ar_AR/news/buzz/atom.xml b/ar_AR/news/buzz/atom.xml
index 84c690e933..4cef7092da 100644
--- a/ar_AR/news/buzz/atom.xml
+++ b/ar_AR/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/ar_AR/news/buzz/index.html b/ar_AR/news/buzz/index.html
index 8db388d477..3087b6960b 100644
--- a/ar_AR/news/buzz/index.html
+++ b/ar_AR/news/buzz/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/cs/news/buzz/atom.xml b/cs/news/buzz/atom.xml
index 170cb46c6c..dacc481090 100644
--- a/cs/news/buzz/atom.xml
+++ b/cs/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/cs_CZ/bee/index.html b/cs_CZ/bee/index.html
index d813674a49..c13b3d271f 100644
--- a/cs_CZ/bee/index.html
+++ b/cs_CZ/bee/index.html
@@ -175,12 +175,12 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/da/news/buzz/atom.xml b/da/news/buzz/atom.xml
index 01ebae5445..d41bb945ff 100644
--- a/da/news/buzz/atom.xml
+++ b/da/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/da_DK/bee/index.html b/da_DK/bee/index.html
index f2cda61ac6..7d40b6f5b6 100644
--- a/da_DK/bee/index.html
+++ b/da_DK/bee/index.html
@@ -175,12 +175,12 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/de_DE/news/buzz/atom.xml b/de_DE/news/buzz/atom.xml
index f6ef56fd78..b0a4d1a3fc 100644
--- a/de_DE/news/buzz/atom.xml
+++ b/de_DE/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/de_DE/news/buzz/index.html b/de_DE/news/buzz/index.html
index 7ea61dac3b..a43133f1d6 100644
--- a/de_DE/news/buzz/index.html
+++ b/de_DE/news/buzz/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/es/noticias/zumbido/atom.xml b/es/noticias/zumbido/atom.xml
index a3c4d42b0c..77e66ad823 100644
--- a/es/noticias/zumbido/atom.xml
+++ b/es/noticias/zumbido/atom.xml
@@ -1,5 +1,41 @@
-El Zumbidourn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+El Zumbidourn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Proyecto destacado: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>Este artículo fue publicado originalmente en la lista de correo de Entusiastas BeeWare. Si deseas recibir actualizaciones periódicas sobre el proyecto BeeWare, ¿Por qué no</em> <a class="reference external" href="/community/keep-informed/">suscribirse</a>?</p>
-<p>Cuando diseñas una aplicación de interfaz gráfica, ya sea para escritorio, dispositivos móviles o navegador, una de las tareas más fundamentales es describir cómo colocar widgets en la pantalla. La mayoría de los kits de herramientas de widgets usarán un modelo de empaquetamiento de cuadrícula o caja de algún tipo para resolver este problema. Estos modelos tienden a ser relativamente fáciles al comienzo, pero se desmoronan rápidamente cuando tienes necesidades complejas de diseño o cuando tienes diseños que necesitan adaptarse a diferentes tamaños de pantalla.</p>
-<p>En lugar de inventar un nuevo modelo de cuadrícula o de caja, el kit de herramientas del widget <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit adopta un enfoque diferente, utilizando un esquema conocido para diseñar contenido: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, o CSS. Aunque CSS es más conocido por especificar el diseño en las páginas web, no hay nada intrínsecamente específico de la web al respecto. Al final del día, es un sistema para describir el diseño de una colección jerárquica de nodos de contenido. Sin embargo, hasta la fecha, cada implementación de CSS está vinculada a un navegador, por lo que la percepción es que CSS es un estándar específico del navegador.</p>
-<p>Ahí es donde entra <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a>. Colosseum es una implementación independiente del navegador de un motor de renderizado CSS. Toma un árbol de "nodos" de contenido, como un DOM de un documento HTML y aplica instrucciones de diseño CSS para diseñar esos nodos como cuadros en la pantalla. En el caso de Toga, en lugar de diseñar los elementos <tt class="docutils literal"><div></tt> y <tt class="docutils literal"><span></tt>, diseñas objetos Box y Button. Esto le permite especificar diseños adaptativos increíblemente complejos para aplicaciones Toga.</p>
-<p>Pero Colosseum como proyecto tiene muchos otros posibles usos. Se puede usar en cualquier lugar donde exista la necesidad de describir el diseño <em>fuera</em> del contexto de un navegador. Por ejemplo, Colosseum podría ser la piedra angular de un renderizador de HTML a PDF <em>que no requiere</em> el uso de un navegador. También podría usarse como una librería de pruebas e implementación de referencia para la especificación CSS en sí misma, proporcionando una forma ligera de codificar y probar los cambios propuestos a la especificación.</p>
-<p>La implementación actual se basa en el proyecto de Facebook <a class="reference external" href="https://github.com/facebook/yoga">yoga</a>: originalmente era un código portado de JavaScript a Python línea a línea. Sin embargo, yoga solo implementa la sección de Flexbox de la especificación CSS3.</p>
-<p>Esta semana, comenzamos un gran proyecto: reescribir Colosseum para que sea un motor de CSS totalmente compatible. El trabajo hasta ahora se puede encontrar en la rama globo del repositorio Colosseum en Github. El primer objetivo es el cumplimiento de CSS2.1, con una implementación del modelo de caja de CSS tradicional y el diseño de flujo. Una vez que tengamos una implementación razonable de eso, buscaremos agregar diseños Grid y FlexBox desde el conjunto de especificaciones CSS3.</p>
-<p>Esto es obviamente un trabajo grande. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS es una gran especificación</a>, por lo que hay mucho trabajo por hacer, ¡pero eso también significa que hay muchos lugares para contribuir! Elije un párrafo de la especificación CSS, construye algunos casos de prueba que demuestren los casos descritos en ese párrafo y envía un parche que implemente ese comportamiento!</p>
-<p>Esto resalta por que tu apoyo financiero es muy importante. Si bien <em>podríamos</em> hacer esto completamente con un esfuerzo voluntario, vamos a progresar mucho más rápido si un pequeño grupo de personas pudiera enfocarse en este proyecto de tiempo completo. El apoyo financiero permitiría aumentar significativamente la velocidad de desarrollo de Colosseum y el resto de la suite BeeWare.</p>
-<p>Si deseas que Colosseum y el resto de BeeWare se desarrollen hasta el punto en que puedan utilizarse para aplicaciones comerciales, considera apoyar a BeeWare financieramente. Y si tienes alguna idea para fuentes de financiación potenciales más grandes, por favor <a class="reference external" href="mailto:russell@keith-magee.com">ponte en contacto</a>.</p>
\ No newline at end of file
diff --git a/es/noticias/zumbido/index.html b/es/noticias/zumbido/index.html
index a8685d5529..b1e1580042 100644
--- a/es/noticias/zumbido/index.html
+++ b/es/noticias/zumbido/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
Este artículo fue publicado originalmente en la lista de correo de Entusiastas BeeWare. Si deseas recibir actualizaciones periódicas sobre el proyecto BeeWare, ¿Por qué nosuscribirse?
-
Cuando diseñas una aplicación de interfaz gráfica, ya sea para escritorio, dispositivos móviles o navegador, una de las tareas más fundamentales es describir cómo colocar widgets en la pantalla. La mayoría de los kits de herramientas de widgets usarán un modelo de empaquetamiento de cuadrícula o caja de algún tipo para resolver este problema. Estos modelos tienden a ser relativamente fáciles al comienzo, pero se desmoronan rápidamente cuando tienes necesidades complejas de diseño o cuando tienes diseños que necesitan adaptarse a diferentes tamaños de pantalla.
-
En lugar de inventar un nuevo modelo de cuadrícula o de caja, el kit de herramientas del widget Toga widget toolkit adopta un enfoque diferente, utilizando un esquema conocido para diseñar contenido: Cascading Style Sheets, o CSS. Aunque CSS es más conocido por especificar el diseño en las páginas web, no hay nada intrínsecamente específico de la web al respecto. Al final del día, es un sistema para describir el diseño de una colección jerárquica de nodos de contenido. Sin embargo, hasta la fecha, cada implementación de CSS está vinculada a un navegador, por lo que la percepción es que CSS es un estándar específico del navegador.
-
Ahí es donde entra Colosseum. Colosseum es una implementación independiente del navegador de un motor de renderizado CSS. Toma un árbol de "nodos" de contenido, como un DOM de un documento HTML y aplica instrucciones de diseño CSS para diseñar esos nodos como cuadros en la pantalla. En el caso de Toga, en lugar de diseñar los elementos <div> y <span>, diseñas objetos Box y Button. Esto le permite especificar diseños adaptativos increíblemente complejos para aplicaciones Toga.
-
Pero Colosseum como proyecto tiene muchos otros posibles usos. Se puede usar en cualquier lugar donde exista la necesidad de describir el diseño fuera del contexto de un navegador. Por ejemplo, Colosseum podría ser la piedra angular de un renderizador de HTML a PDF que no requiere el uso de un navegador. También podría usarse como una librería de pruebas e implementación de referencia para la especificación CSS en sí misma, proporcionando una forma ligera de codificar y probar los cambios propuestos a la especificación.
-
La implementación actual se basa en el proyecto de Facebook yoga: originalmente era un código portado de JavaScript a Python línea a línea. Sin embargo, yoga solo implementa la sección de Flexbox de la especificación CSS3.
-
Esta semana, comenzamos un gran proyecto: reescribir Colosseum para que sea un motor de CSS totalmente compatible. El trabajo hasta ahora se puede encontrar en la rama globo del repositorio Colosseum en Github. El primer objetivo es el cumplimiento de CSS2.1, con una implementación del modelo de caja de CSS tradicional y el diseño de flujo. Una vez que tengamos una implementación razonable de eso, buscaremos agregar diseños Grid y FlexBox desde el conjunto de especificaciones CSS3.
-
Esto es obviamente un trabajo grande. CSS es una gran especificación, por lo que hay mucho trabajo por hacer, ¡pero eso también significa que hay muchos lugares para contribuir! Elije un párrafo de la especificación CSS, construye algunos casos de prueba que demuestren los casos descritos en ese párrafo y envía un parche que implemente ese comportamiento!
-
Esto resalta por que tu apoyo financiero es muy importante. Si bien podríamos hacer esto completamente con un esfuerzo voluntario, vamos a progresar mucho más rápido si un pequeño grupo de personas pudiera enfocarse en este proyecto de tiempo completo. El apoyo financiero permitiría aumentar significativamente la velocidad de desarrollo de Colosseum y el resto de la suite BeeWare.
-
Si deseas que Colosseum y el resto de BeeWare se desarrollen hasta el punto en que puedan utilizarse para aplicaciones comerciales, considera apoyar a BeeWare financieramente. Y si tienes alguna idea para fuentes de financiación potenciales más grandes, por favor ponte en contacto.
Este artículo fue publicado originalmente en la lista de correo de Entusiastas BeeWare. Si deseas recibir actualizaciones periódicas sobre el proyecto BeeWare, ¿Por qué nosuscribirse?
+
Cuando diseñas una aplicación de interfaz gráfica, ya sea para escritorio, dispositivos móviles o navegador, una de las tareas más fundamentales es describir cómo colocar widgets en la pantalla. La mayoría de los kits de herramientas de widgets usarán un modelo de empaquetamiento de cuadrícula o caja de algún tipo para resolver este problema. Estos modelos tienden a ser relativamente fáciles al comienzo, pero se desmoronan rápidamente cuando tienes necesidades complejas de diseño o cuando tienes diseños que necesitan adaptarse a diferentes tamaños de pantalla.
+
En lugar de inventar un nuevo modelo de cuadrícula o de caja, el kit de herramientas del widget Toga widget toolkit adopta un enfoque diferente, utilizando un esquema conocido para diseñar contenido: Cascading Style Sheets, o CSS. Aunque CSS es más conocido por especificar el diseño en las páginas web, no hay nada intrínsecamente específico de la web al respecto. Al final del día, es un sistema para describir el diseño de una colección jerárquica de nodos de contenido. Sin embargo, hasta la fecha, cada implementación de CSS está vinculada a un navegador, por lo que la percepción es que CSS es un estándar específico del navegador.
+
Ahí es donde entra Colosseum. Colosseum es una implementación independiente del navegador de un motor de renderizado CSS. Toma un árbol de "nodos" de contenido, como un DOM de un documento HTML y aplica instrucciones de diseño CSS para diseñar esos nodos como cuadros en la pantalla. En el caso de Toga, en lugar de diseñar los elementos <div> y <span>, diseñas objetos Box y Button. Esto le permite especificar diseños adaptativos increíblemente complejos para aplicaciones Toga.
+
Pero Colosseum como proyecto tiene muchos otros posibles usos. Se puede usar en cualquier lugar donde exista la necesidad de describir el diseño fuera del contexto de un navegador. Por ejemplo, Colosseum podría ser la piedra angular de un renderizador de HTML a PDF que no requiere el uso de un navegador. También podría usarse como una librería de pruebas e implementación de referencia para la especificación CSS en sí misma, proporcionando una forma ligera de codificar y probar los cambios propuestos a la especificación.
+
La implementación actual se basa en el proyecto de Facebook yoga: originalmente era un código portado de JavaScript a Python línea a línea. Sin embargo, yoga solo implementa la sección de Flexbox de la especificación CSS3.
+
Esta semana, comenzamos un gran proyecto: reescribir Colosseum para que sea un motor de CSS totalmente compatible. El trabajo hasta ahora se puede encontrar en la rama globo del repositorio Colosseum en Github. El primer objetivo es el cumplimiento de CSS2.1, con una implementación del modelo de caja de CSS tradicional y el diseño de flujo. Una vez que tengamos una implementación razonable de eso, buscaremos agregar diseños Grid y FlexBox desde el conjunto de especificaciones CSS3.
+
Esto es obviamente un trabajo grande. CSS es una gran especificación, por lo que hay mucho trabajo por hacer, ¡pero eso también significa que hay muchos lugares para contribuir! Elije un párrafo de la especificación CSS, construye algunos casos de prueba que demuestren los casos descritos en ese párrafo y envía un parche que implemente ese comportamiento!
+
Esto resalta por que tu apoyo financiero es muy importante. Si bien podríamos hacer esto completamente con un esfuerzo voluntario, vamos a progresar mucho más rápido si un pequeño grupo de personas pudiera enfocarse en este proyecto de tiempo completo. El apoyo financiero permitiría aumentar significativamente la velocidad de desarrollo de Colosseum y el resto de la suite BeeWare.
+
Si deseas que Colosseum y el resto de BeeWare se desarrollen hasta el punto en que puedan utilizarse para aplicaciones comerciales, considera apoyar a BeeWare financieramente. Y si tienes alguna idea para fuentes de financiación potenciales más grandes, por favor ponte en contacto.
diff --git a/content/project/projects/support/python-apple-support/contents.lr b/content/project/projects/support/python-apple-support/contents.lr
-index 9071485923..89df1a5d0d 100644
---- a/content/project/projects/support/python-apple-support/contents.lr
-+++ b/content/project/projects/support/python-apple-support/contents.lr
-@@ -15,3 +15,7 @@ incomplete: yes
-description: A meta-package for building a version of Python that can be embedded into a macOS, iOS, tvOS or watchOS project.
----
-customlogo: yes
-+---
-+image: python-apple-support.png
-+---
-+github_repo: beeware/Python-Apple-support
-
-
-
-
-
-
-
-
-
+
@@ -323,7 +201,7 @@
- El contenido de esta página está incompleto, puedes ayudar expandiéndolo.
+ El contenido de esta página está incompleto, puedes ayudar expandiéndolo.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/it_IT/news/buzz/atom.xml b/it_IT/news/buzz/atom.xml
index 2f32784aab..d17bcbef80 100644
--- a/it_IT/news/buzz/atom.xml
+++ b/it_IT/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/it_IT/news/buzz/index.html b/it_IT/news/buzz/index.html
index 266ce9f21d..4eee831b28 100644
--- a/it_IT/news/buzz/index.html
+++ b/it_IT/news/buzz/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/ko/news/buzz/atom.xml b/ko/news/buzz/atom.xml
index 6a06ca5f3b..a46dc451bd 100644
--- a/ko/news/buzz/atom.xml
+++ b/ko/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/ko_KR/bee/index.html b/ko_KR/bee/index.html
index 6583aad7f8..f9396038c1 100644
--- a/ko_KR/bee/index.html
+++ b/ko_KR/bee/index.html
@@ -175,12 +175,12 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/news/buzz/atom.xml b/news/buzz/atom.xml
index aca49383e8..38ca39a69a 100644
--- a/news/buzz/atom.xml
+++ b/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/news/buzz/index.html b/news/buzz/index.html
index a8f85b5385..015fcc6f78 100644
--- a/news/buzz/index.html
+++ b/news/buzz/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
-Posted by
-
-
- Russell Keith-Magee
-
-
-on
- 2024-04-02
-
-
... more articles
diff --git a/pl/news/buzz/atom.xml b/pl/news/buzz/atom.xml
index 440a866cde..0fb6a648f4 100644
--- a/pl/news/buzz/atom.xml
+++ b/pl/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-Nowinyurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+Nowinyurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/pl_PL/bee/index.html b/pl_PL/bee/index.html
index 598c2c3663..4dc35ffc99 100644
--- a/pl_PL/bee/index.html
+++ b/pl_PL/bee/index.html
@@ -175,12 +175,12 @@
+
+Opublikowane przez
+
+
+ Russell Keith-Magee
+
+
+dnia
+ 1 November 2024
+
+
+
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
-
-Opublikowane przez
-
-
- Russell Keith-Magee
-
-
-dnia
- 17 December 2022
-
-
-
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
+
+Opublikowane przez
+
+
+ Russell Keith-Magee
+
+
+dnia
+ 17 December 2022
+
+
+
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
-
-Opublikowane przez
-
-
- Russell Keith-Magee
-
-
-dnia
- 6 October 2017
-
-
-
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
+
+Opublikowane przez
+
+
+ Russell Keith-Magee
+
+
+dnia
+ 6 October 2017
+
+
+
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/pr_BR/news/buzz/atom.xml b/pr_BR/news/buzz/atom.xml
index c4c17444c7..ee3c9e88f6 100644
--- a/pr_BR/news/buzz/atom.xml
+++ b/pr_BR/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/pt_BR/bee/index.html b/pt_BR/bee/index.html
index a911c509cf..7e90336235 100644
--- a/pt_BR/bee/index.html
+++ b/pt_BR/bee/index.html
@@ -175,12 +175,12 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/tr/news/buzz/atom.xml b/tr/news/buzz/atom.xml
index c989e1b861..e5b2a20bf3 100644
--- a/tr/news/buzz/atom.xml
+++ b/tr/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-Vızıltıurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+Vızıltıurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/tr_TR/bee/index.html b/tr_TR/bee/index.html
index d4ce621ff1..eaa28b53ee 100644
--- a/tr_TR/bee/index.html
+++ b/tr_TR/bee/index.html
@@ -175,12 +175,12 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/zh_CN/news/buzz/atom.xml b/zh_CN/news/buzz/atom.xml
index df6ba2ab68..731479e0e7 100644
--- a/zh_CN/news/buzz/atom.xml
+++ b/zh_CN/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/zh_CN/news/buzz/index.html b/zh_CN/news/buzz/index.html
index bdffa5a31b..b778245c54 100644
--- a/zh_CN/news/buzz/index.html
+++ b/zh_CN/news/buzz/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
diff --git a/zh_TW/news/buzz/atom.xml b/zh_TW/news/buzz/atom.xml
index 8d8d40796d..eb916f3e54 100644
--- a/zh_TW/news/buzz/atom.xml
+++ b/zh_TW/news/buzz/atom.xml
@@ -1,5 +1,41 @@
-The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-10-02T00:00:00ZBeeWare's official blog2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
+The Buzzurn:uuid:0f18b85e-c1d4-3086-935d-f801edebea162024-11-01T00:00:00ZBeeWare's official blogOctober 2024 Status Update2024-11-01T00:00:00ZRussell Keith-Mageeurn:uuid:3bc76249-ea74-3dca-ba8d-774d23d28b4d<p>In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.</p>
+<div class="section" id="what-we-ve-done">
+<h2>What we've done</h2>
+<ul class="simple">
+<li>Most importantly, we released <a class="reference external" href="https://pypi.org/project/briefcase/0.3.20/">Briefcase 0.3.20</a> and <a class="reference external" href="https://pypi.org/project/toga/0.4.8/">Toga 0.4.8</a>, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.</li>
+<li>We've prepared an <a class="reference external" href="https://github.com/freakboy3742/cibuildwheel/tree/ios-support">initial patch to cibuildwheel that is able to build and test simple iOS wheels</a>. This patch isn't ready to submit upstream, but it is able to build simple iOS wheels.</li>
+<li>We've submitted a patch to Pillow to <a class="reference external" href="https://github.com/python-pillow/Pillow/pull/8497">isolate its build system from Homebrew when building on macOS</a>. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.</li>
+<li>We've made <a class="reference external" href="https://github.com/multi-build/multibuild">a number of improvements to multibuild</a>, the tooling that Pillow uses to compile non-Python binary dependencies.</li>
+<li>We've <a class="reference external" href="https://github.com/python/cpython/pull/126169">modified the CPython iOS testbed project</a> so that it can be used as a testbed for <em>any</em> iOS Python project.</li>
+<li>We've <a class="reference external" href="https://github.com/beeware/briefcase/pull/2033">improved error reporting when Briefcase can't clone a template</a>.</li>
+<li>We've switched to using <tt class="docutils literal">httpx</tt> instead of <tt class="docutils literal">requests</tt> for <a class="reference external" href="https://github.com/beeware/briefcase/pull/2041">Briefcase's internal download handling</a>. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using <tt class="docutils literal">httpx</tt> in Briefcase and in our example code.</li>
+<li>We've modified Toga to <a class="reference external" href="https://github.com/beeware/toga/pull/2686">lazily load components</a>, rather than importing everything into the <tt class="docutils literal">toga</tt> namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.</li>
+<li>We resolved an issue causing <a class="reference external" href="https://github.com/beeware/toga/pull/2893">intermittent test failures when testing Toga on Wayland</a>.</li>
+</ul>
+</div>
+<div class="section" id="what-s-next">
+<h2>What's next?</h2>
+<p>We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least <em>some</em> third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.</p>
+<p>We'll also be speaking at <a class="reference external" href="https://2024.pycon.org.au">PyCon AU</a> at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!</p>
+</div>
+<div class="section" id="want-to-get-involved">
+<h2>Want to get involved?</h2>
+<p>Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:</p>
+<ol class="arabic simple">
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2251">Update the Toga testbed test suite to use Pixel 7 Pro device sizes</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/780">Filter out a message generated after Xcode updates</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/808">Add the ability to configure the ABIs built by an Android project</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1099">Rationalise the application of adhoc signing on macOS</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1270">Add support for custom PyPI repositories</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1393">Document how to debug an application in popular IDEs</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/737">Add an option to select the Android base image when creating new emulators</a></li>
+<li><a class="reference external" href="https://github.com/beeware/toga/issues/2305">Add an API to entirely replace the style of a widget</a></li>
+<li><a class="reference external" href="https://github.com/beeware/briefcase/issues/1876">Correct the handling of quotation marks in Android apps</a></li>
+</ol>
+<p>Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a <a class="reference external" href="https://briefcase.readthedocs.io/en/latest/how-to/contribute-code.html">guide on setting up a Briefcase development environment</a>; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the <a class="reference external" href="https://beeware.org/bee/chat/">BeeWare Discord server</a>.</p>
+</div>
+2024Q4 Roadmap2024-10-02T00:00:00ZRussell Keith-Mageeurn:uuid:10dd2b41-f023-3662-89b5-5c2a39279898<p>Q3 has seen some major progress against long term goals of the BeeWare project. As always, this roadmap should be read as a guide to what we aim to focus on over the coming quarter, rather than a hard commitment of features that will be made available on a specific deadline.</p>
<div class="section" id="q3-progress">
<h2>Q3 progress</h2>
<p>In Q3 the biggest milestone we achieved was the finalisation of Tier 3 support for Android in CPython. The last of the compatibility and documentation issues associated with Android have been resolved, and Android buildbots are now running for both x86_64 and ARM64. Python 3.13.0 is due for release in about a week; we should be in a position to support this release very soon after the official release.</p>
@@ -1693,14 +1729,4 @@ started improvising halfway through the summer. I am so grateful for your help,
<p>Huge thanks to my mentor, Russell Keith-Magee for accepting my proposal, providing guidance and encouraging me when things didn't go as intended. It is truly an honor to be a part of the BeeWare community. I had a blast contributing to BeeWare project, and I'm sure I will stick around as a regular contributor.
Also shout out to the BeeWare community for answering my queries and reviewing my pull requests. 😄</p>
</div>
-Project Spotlight: Colosseum2017-10-06T00:00:00ZRussell Keith-Mageeurn:uuid:f22e59e5-ed97-3801-bee3-01bfa5768bb5<p><em>This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why not</em> <a class="reference external" href="/community/keep-informed/">subscribe</a>?</p>
-<p>When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.</p>
-<p>Instead of inventing a new grid or box model, the <a class="reference external" href="https://toga.readthedocs.io">Toga</a> widget toolkit takes a different approach, using a well known scheme for laying out content: <a class="reference external" href="https://en.wikipedia.org/wiki/Cascading_Style_Sheets">Cascading Style Sheets</a>, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.</p>
-<p>That's where <a class="reference external" href="https://github.com/beeware/colosseum">Colosseum</a> comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <tt class="docutils literal"><div></tt> and <tt class="docutils literal"><span></tt> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.</p>
-<p>But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout <em>outside</em> a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that <em>doesn't</em> require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.</p>
-<p>The current implementation is based on Facebook's <a class="reference external" href="https://github.com/facebook/yoga">yoga</a> project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.</p>
-<p>This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.</p>
-<p>This is obviously a big job. <a class="reference external" href="https://www.w3.org/TR/CSS/#css-levels">CSS is a big specification</a>, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!</p>
-<p>It also highlights why your financial support is so important. While we <em>could</em> do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.</p>
-<p>If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please <a class="reference external" href="mailto:russell@keith-magee.com">get in touch</a>.</p>
\ No newline at end of file
diff --git a/zh_TW/news/buzz/index.html b/zh_TW/news/buzz/index.html
index 3ad6af9094..2820d9d273 100644
--- a/zh_TW/news/buzz/index.html
+++ b/zh_TW/news/buzz/index.html
@@ -188,6 +188,64 @@
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
-
-
What we've done
-
-
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
In October, BeeWare saw some important releases, plus more good progress on binary packaging for iOS.
+
+
What we've done
+
+
Most importantly, we released Briefcase 0.3.20 and Toga 0.4.8, including support for Python 3.13 - which includes the official support in Python for iOS and Android! This is a major milestone for BeeWare as a project, representing a significant portion of the work done over the last 12 months.
We've submitted a patch to Pillow to isolate its build system from Homebrew when building on macOS. This is essential for iOS support, as it's easy for Homebrew macOS ARM64 binaries to leak into iOS builds; but it also has benefits for macOS builds.
We've switched to using httpx instead of requests for Briefcase's internal download handling. This provides slightly better error handling, better options for improving HTTP/2 usage, and we're now consistently using httpx in Briefcase and in our example code.
+
We've modified Toga to lazily load components, rather than importing everything into the toga namespace at startup. This should improve application startup times, especially on platforms like mobile and web where this startup time is noticeable.
We will be continuing to work on binary packaging in November. We're using Pillow as a demonstrator for this work - it's a package that has a significant binary component, is widely used (including on mobile), but has a non-trivial build process (largely due to the non-Python binary dependencies). The hope is that by the time we're able to compile Pillow for iOS, we will have resolved many of the issues facing other binary packages. Our goal remains to have at least some third-party projects officially supporting iOS and Android by the end of the year, but this may be impeded by the sequence of dependencies that need to land and be published before upstream projects can accept iOS and Android patches.
+
We'll also be speaking at PyCon AU at the end of the month, including attending both days of the sprints. If you're able to make it to Narrm/Melbourne, we hope we'll see you there!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This month, we have less to report by raw feature count - but the changes we have made represent extremely significant progress.
+
+
What we've done
+
+
Our primary focus this month has been making the changes to CPython needed to add support for iOS and Android. We've made major progress towards this goal: all the patches required for iOS have been merged; a large number of patches have been submitted for Android, with only a small number still required. This month, we have:
In April, we're hoping to wrap up the work on iOS and Android patches for CPython, and add buildbots for those platforms. With the buildbots in place, iOS and Android will officially be Tier 3 supported CPython platforms. We also plan to revisit the BeeWare tutorial, adding some more steps in preparation for a tutorial presentation at PyCon US in May. If you're coming to Pittsburgh and you'd like to attend that tutorial session, ticket sales are open!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
-
-
What we've done
-
-
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
-
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
-
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
-
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The year rolls on, and so does progress on BeeWare!
+
+
What we've done
+
+
We attended EuroPython 2023, presenting on Briefcase, attending the WASM summit, and running a very successful 2 day sprint.
+
We've completed the audit of all Toga widgets on macOS, iOS and GTK! We've also completed the audit of ScrollContainer and SplitContainer on Windows and Android.
Type annotations in Toga have been significantly improved. We've been adding type annotations as part of the widget audit, but some types (such as callbacks) weren't as specific as they could have been. We're now using Protocols to define some of the more complex types in Toga.
The widget testing audit is now complete on macOS, iOS and GTK. An audit of App and Window functionality is all that stands in the way of 100% test coverage on those three platforms; it seems likely we'll get there by the end of this month. Android and Windows coverage is close behind, but might take a little longer.
+
Part of the reason for this delay is that we need to address an important change in the most recent release of Android Studio. Over the last few years, the Android ecosystem has been in the process of migrating its build system from Groovy to Kotlin; Android Studio Giraffe makes Kotlin the default for new projects, so we need to make sure we're compatible with that change. The widget audit has also highlighted that we need to improve our handling of subclass inheritance in Java; we're hoping to make some changes that will enable us to fill in a few more gaps in widget API coverage on Android.
+
We'll also be at PyCon AU 2023 from August 18-22. We're presenting on Saturday; and we'll be there for the full duration of the sprints. See you in Tarntanya/Adelaide!
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
-
-
-
Want to get involved?
-
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
This status update is a little earlier than our usual end-of-month report because the team will be taking a well-earned break to spend time with family and friends over the holiday and new year period. As a result, we've got less to report than in past months; however, some significant progress and improvements have been made.
We merged the first draft of the Toga GUI testbed. There is still a lot of work to be done on this testbed, but it provides a solid foundation on which we can build tests of Toga's cross-platform GUI behavior.
There won't be much more progress from the core team for the rest of this year. We'll still be around to handle critical problems, answer questions and do code reviews for contributors; but our response times might be a little slower than normal. We'll publish our Q1 2023 roadmap when we return in January - but we'll be largely picking up where this year has left off - improving the testing story for Toga.
+
+
+
Want to get involved?
+
Want to get involved? Here are some open issues that would be a great place to get started with contributing to a BeeWare project. They're all relatively minor changes, but would provide a big improvement to the lives of BeeWare users:
Pick one of these tickets, drop a comment on the ticket to let others know you're looking at it, and try your hand at a PR! We have a guide on setting up a Briefcase development environment; but if you need any additional assistance or guidance, you can ask on the ticket, or join us on the BeeWare Discord server.
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
-
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
-
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
-
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
The position is a full time, Mid- to Senior position. You will be working full time in the Open Source group at Anaconda, on the BeeWare suite of tools. Full details of the position can be found on Greenhouse.
+
The position calls for an unusual combination of skills. The ideal candidate would have experience building GUI applications (especially mobile) and Python skills. However, because of the existing state of the Python ecosystem, most Python developers don't have GUI development experience, and most GUI developers don't have extensive Python experience. For that reason, if the position is interesting to you, but you don't have all the "must have" attributes - I would encourage you to apply anyway. A candidate with no GUI development experience will still considered, as long as they've got a demonstrated history of doing weird and wonderful things with Python. Similarly, a developer with deep GUI experience, but no Python experience, will also be considered.
+
The job location requirements are also unusual. The position is remote; the position requires that your working hours need to be compatible with UTC+8. This means candidates from Australia, South East and South Asia will be a natural fit. European candidates will need to be prepared for early morning starts. US/Canadian candidates will need to be prepared for evening work (very late evenings if you're in CST or EST timezones). Anaconda has the capacity to hire in the UK, Germany, India, Australia, US, and Canada. If you're not a resident of one of those countries, it may be possible to hire you, but it will likely require you to operate as a private contractor rather than a salaried employee.
+
I'm incredibly excited for what the future holds for BeeWare - if you'd like to come on this journey with me, please apply (and tell them Russell sent you)!
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
-
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
-
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
-
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
-
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
-
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
-
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
-
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
-
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
-
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
This article was originally published on the BeeWare Enthusiasts mailing list. If you'd like to receive regular updates about the BeeWare project, why notsubscribe?
+
When you're designing a GUI app - be it for desktop, mobile, or browser - one of the most fundamental tasks is describing how to lay widgets out the screen. Most widget toolkits will use a grid or box packing model of some kind to solve this problem. These models tend to be relatively easy to get started, but rapidly fall apart when you have complex layout needs - or when you have layouts that need to adapt to different screen sizes.
+
Instead of inventing a new grid or box model, the Toga widget toolkit takes a different approach, using a well known scheme for laying out content: Cascading Style Sheets, or CSS. Although CSS is best known for specifying layout in web pages, there's nothing inherently web specific about it. At the end of the day, it's a system for describing the layout of a hierarchical collection of content nodes. However, to date, every implementation of CSS is bound to a browser, so the perception is that CSS is a browser-specific standard.
+
That's where Colosseum comes in. Colosseum is a browser independent implementation of a CSS rendering engine. It takes a tree of content "nodes" - such as a DOM from a HTML document - an applies CSS styling instructions to layout those nodes as boxes on the screen. In the case of Toga, instead of laying out <div> and <span> elements, you lay out Box and Button objects. This allows you to specify incredibly complex, adaptive layouts for Toga applications.
+
But Colosseum as a project has many other possible uses. It could be used anywhere that there is a need for describing layout outside a browser context. For example, Colosseum could be the cornerstone of a HTML to PDF renderer that doesn't require the involvement of a browser. It could also be used as a test harness and reference implementation for the CSS specification itself, providing a lightweight way to encode and test proposed changes to the specification.
+
The current implementation is based on Facebook's yoga project - it was originally a line-for-line port of yoga's javascript codebase into Python. However, yoga only implements the Flexbox portion of the CSS3 specification.
+
This week, we started a big project: rewriting Colosseum to be a fully standard-compliant CSS engine. The work so far can be found in the globe branch of the colosseum repository on Github. The first goal is CSS2.1 compliance, with an implementation of the traditional CSS box model and flow layout. Once we've got a reasonable implementation of that, we'll look to adding Grid and FlexBox layouts from the CSS3 specification set.
+
This is obviously a big job. CSS is a big specification, so there's a lot of work to be done - but that also means there's lots of places to contribute! Pick a paragraph of the CSS specification, build some test cases that demonstrate the cases described in that paragraph, and submit a patch implementing that behaviour!
+
It also highlights why your financial support is so important. While we could do this entirely with volunteered effort, we're going to make much faster progress if a small group of people could focus on this project full time. Financial support would allow up to significantly ramp up the development speed of Colosseum, and the rest of the BeeWare suite.
+
If you would like to see Colosseum and the rest of BeeWare develop to the point where it can be used for commercial applications, please consider supporting BeeWare financially. And if you have any leads for larger potential sources of funding, please get in touch.
+ 