List items
Items from the current list are shown below.
Blog
7 Oct 2023 : Day 52 #
As I mentioned yesterday the view outside my window has become thoroughly autumnal. After a night of solid rain the situation hasn't changed. There's a real feeling of anticipation in the air as the world starts preparing for the winter months. Work on gecko also reached a point of anticipation yesterday as the browser stack — gecko, qtmozembed, embedlite-components, sailfish-components-webview, sailfish-browser — now starts up and continues running without crashing. There's no rendering, so it's completely useless as a browser, but that goal looks ever closer.
Of the five components mentioned, two of them (embedlite-components and sailfish-components-webview) remain as-yet unchanged. The others I've had to make changes to in order to adjust to the ESR 91 API and changes in the underlying configuration.
My next steps are therefore to get these changes pushed to the repositories (not in the main branches, but so that they're publicly accessible) and built using OBS. This will then open the way for others to contribute if they want to.
If you've been following along you'll also know that I took numerous shortcuts to get to this point. Breaking the rendering pipeline was just one of them. The time has now come for me to collate all of these issues in the public sailfish-browser issue tracker on GitHub. That'll allow for a more structured approach to addressing the issues, as well as making it easier for others to pick up tasks to contribute to in case anyone fancies it.
I've no idea whether anyone will have the time or inclination, but that's not really the point. While it would be great if others were to, the important thing is to make this as open and accessible as possible.
So this morning I'm committing and pushing. Here are the results of these efforts: Time works in strange ways when you're writing a diary like this. It's quite late now and I've spent the evening combing through the various commits I've been making to gecko and its related projects to see how many of them left lingering tasks behind.
It turns out, there's quite a lot of unfinished business. I've written up all of the ones I could find and added them to the sailfish-browser issue tracker. I've given each of them an ESR 91 tag to make them easier to find, but here also is the list in full:
It's taken quite a while to write all of these up (not that I've done a particularly good job, but it's the quantity). So no time for any actual code development today.
The next step, which will be for tomorrow, will be to set up the build on OBS. After that, it's the rendering pipeline.
Before I sign off for today, let me just throw some timings out there, primarily for the benefit of Nico. During a conversation with Nico I mentioned that the link time for gecko using the Sailfish SDK was around 20 minutes. But when I said that it was just a guess and I promised to time it to check.
This turned out to be a misrepresentation, although arguably an understandable one. The actual link time is just 3 minutes and 20.32 seconds. That's a lot quicker than I claimed. However the final packaging step — that's the time needed to package everything up into rpms — takes 13 minutes 26.26 seconds. In between the two there's 3 minutes 45.91 seconds of general jiggery pokery &mash; performing checks, marshalling files, printing out information — that also needs to complete. So from the time the linking starts to the time the packages are actually spat out (which is the point at which the build finishes) is 19 minutes and 32.49 seconds.
Alright, that's enough for today. If you'd like to read more about all this gecko stuff, do take a look at my full Gecko Dev Diary.
Of the five components mentioned, two of them (embedlite-components and sailfish-components-webview) remain as-yet unchanged. The others I've had to make changes to in order to adjust to the ESR 91 API and changes in the underlying configuration.
My next steps are therefore to get these changes pushed to the repositories (not in the main branches, but so that they're publicly accessible) and built using OBS. This will then open the way for others to contribute if they want to.
If you've been following along you'll also know that I took numerous shortcuts to get to this point. Breaking the rendering pipeline was just one of them. The time has now come for me to collate all of these issues in the public sailfish-browser issue tracker on GitHub. That'll allow for a more structured approach to addressing the issues, as well as making it easier for others to pick up tasks to contribute to in case anyone fancies it.
I've no idea whether anyone will have the time or inclination, but that's not really the point. While it would be great if others were to, the important thing is to make this as open and accessible as possible.
So this morning I'm committing and pushing. Here are the results of these efforts: Time works in strange ways when you're writing a diary like this. It's quite late now and I've spent the evening combing through the various commits I've been making to gecko and its related projects to see how many of them left lingering tasks behind.
It turns out, there's quite a lot of unfinished business. I've written up all of the ones I could find and added them to the sailfish-browser issue tracker. I've given each of them an ESR 91 tag to make them easier to find, but here also is the list in full:
- Set up ESR 91 OBS project build: #1016.
- Check active flag still works on ESR 91: #1017.
- Check effect of user interaction flags on GoBack and GoForward for ESR 91: #1018.
- Check whether GetChromeOuterWindowID() returns the correct value: #1019.
- Fix ESR 91 rendering pipeline: #1020.
- Check whether Fission methods are needed for ESR 91: #1021.
- Check whether MessageChannel is broken on ESR 91: #1022.
- Check unapplied patches on ESR 91: #1023.
- Restore WebRTC code to ESR 91: #1024.
- Restore build processes for ESR 91: #1025.
- Convert ESR 91 gecko-mirror commits to patches: #1026.
- Convert VarCache values to static prefs for ESR 91: #1027.
- Restore ESR 91 build optimisation: #1028.
- Check Qt theming in ESR 91: #1029.
- Fix Qt printing pipeline for ESR 91: #1030.
- Build ESR 91 against newer Linux kernel headers: #1031.
- Avoid compiler crash when building swgl optimised for ESR 91: #1032.
- Enable debuginfo for ESR 91 Rust components: #1033.
- Check browser functionality with ESR 91: #1034.
It's taken quite a while to write all of these up (not that I've done a particularly good job, but it's the quantity). So no time for any actual code development today.
The next step, which will be for tomorrow, will be to set up the build on OBS. After that, it's the rendering pipeline.
Before I sign off for today, let me just throw some timings out there, primarily for the benefit of Nico. During a conversation with Nico I mentioned that the link time for gecko using the Sailfish SDK was around 20 minutes. But when I said that it was just a guess and I promised to time it to check.
This turned out to be a misrepresentation, although arguably an understandable one. The actual link time is just 3 minutes and 20.32 seconds. That's a lot quicker than I claimed. However the final packaging step — that's the time needed to package everything up into rpms — takes 13 minutes 26.26 seconds. In between the two there's 3 minutes 45.91 seconds of general jiggery pokery &mash; performing checks, marshalling files, printing out information — that also needs to complete. So from the time the linking starts to the time the packages are actually spat out (which is the point at which the build finishes) is 19 minutes and 32.49 seconds.
Alright, that's enough for today. If you'd like to read more about all this gecko stuff, do take a look at my full Gecko Dev Diary.
Comments
Uncover Disqus comments