6 ms·

Working with big folders tends to be a bit error prone to me. I would like to synchronize my filters/settings across different devices. On MacOs it randomly han

by Certhas 10y ago

Working with big folders tends to be a bit error prone to me. I would like to synchronize my filters/settings across different devices. On MacOs it randomly hangs for tens of seconds and eats batteries for some people (me included). So yeah, it's mostly done, but better virtual folder support, and a streamlined UI would both be hugely appreciated by me. But, because it's mostly done, I also will just happily keep using it as it is now for the next three years, waiting for the rewrite.

randomdata 10y ago
Is a rewrite necessary to improve on those aspects over modifying the existing codebase?
- Certhas 10y ago
  Maybe not, but from the sound of it, a rewrite is necessary just to keep the lights on and to keep Thunderbird compiling in the long run.
  - Silhouette 10y ago
    What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely? Changing the UIs within this particular family of software products has often given questionable results, confusing or upsetting the core user base for little real benefit. Other UIs built on JS and HTML technologies have so far tended to be slow and buggy compared to using native technologies on the desktop and mobile platforms. If the exercise is expected to take as long as 3 years with the available resources and the hope of getting back to more of a community-supported culture, that seems like a huge amount of work to essentially stay where you already were.
    - jcranmer 10y ago
      > What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely? Short answer: security bugs. Gecko has too high of a code churn to maintain long-term support branches, particularly for people who have little knowledge of the components in question (e.g., SpiderMonkey). Forking Gecko might be a viable short-term strategy, but it's not at all viable long-term.
      - Silhouette 10y ago
        That makes a lot of sense if we're talking about using Gecko to render the contents of arbitrary HTML emails. However, this proposal seems to be about problems supporting the UI itself and proposing a move to some other JS+HTML rendering system as an alternative. At first glance, that appears to be a separate issue, other than both types of functionality possibly relying on Gecko today and rendering engines being quite large so using two different ones not being desirable.
        jcranmer 10y ago
        Gecko is actually quite difficult to embed (Mozilla more or less gave up on there existing non-Firefox/Thunderbird embeddings around 2011 or so). There's a lot of low-level interfaces and design decisions that filter through Thunderbird, for example networking interfaces. Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.
        Silhouette 10y ago
        Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways. Right, but isn't the argument quite a few people are making here that moving to a different UI rendering engine doesn't seem to be obviously justified, given the goals of the project and its current situation? If the architecture is as inter-dependent and non-modular as your comments suggest, wouldn't that make changing significant parts of it even less likely to be successful? At that kind of level, you might be better putting the whole project into legacy mode with emergency updates only, and just letting it carry on for as long as it's useful and then die of natural causes when the time is right. For the other goals mentioned in the original proposal we were talking about, if there's sufficient interest to support doing that much work then an entirely new project with no baggage at all seems like a safer and more realistic bet.
- hashhar 10y ago
  Yes. Because the Thunderbird and Firefox codebases are diverging so much that instead of just maintaining Thudnebird people will have to maintain a fork of Gecko too.

by Certhas 10y ago

randomdata 10y ago

Is a rewrite necessary to improve on those aspects over modifying the existing codebase?

Certhas 10y ago
Maybe not, but from the sound of it, a rewrite is necessary just to keep the lights on and to keep Thunderbird compiling in the long run.
- Silhouette 10y ago
  What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely? Changing the UIs within this particular family of software products has often given questionable results, confusing or upsetting the core user base for little real benefit. Other UIs built on JS and HTML technologies have so far tended to be slow and buggy compared to using native technologies on the desktop and mobile platforms. If the exercise is expected to take as long as 3 years with the available resources and the hope of getting back to more of a community-supported culture, that seems like a huge amount of work to essentially stay where you already were.
  - jcranmer 10y ago
    > What I don't immediately understand is why they can't just fork Gecko and continue using it for their own purposes. Apparently the needs of Firefox and Thunderbird have diverged, and Mozilla seem to have little interest in supporting Thunderbird any more, so is it a crazy idea to just separate the projects completely and avoid the whole issue indefinitely? Short answer: security bugs. Gecko has too high of a code churn to maintain long-term support branches, particularly for people who have little knowledge of the components in question (e.g., SpiderMonkey). Forking Gecko might be a viable short-term strategy, but it's not at all viable long-term.
    - Silhouette 10y ago
      That makes a lot of sense if we're talking about using Gecko to render the contents of arbitrary HTML emails. However, this proposal seems to be about problems supporting the UI itself and proposing a move to some other JS+HTML rendering system as an alternative. At first glance, that appears to be a separate issue, other than both types of functionality possibly relying on Gecko today and rendering engines being quite large so using two different ones not being desirable.
      - jcranmer 10y ago
        Gecko is actually quite difficult to embed (Mozilla more or less gave up on there existing non-Firefox/Thunderbird embeddings around 2011 or so). There's a lot of low-level interfaces and design decisions that filter through Thunderbird, for example networking interfaces. Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways.
        Silhouette 10y ago
        Once you talk about moving to a different rendering engine for the UI, you're more or less talking about ripping out ¾ of the backend code or so anyways. Right, but isn't the argument quite a few people are making here that moving to a different UI rendering engine doesn't seem to be obviously justified, given the goals of the project and its current situation? If the architecture is as inter-dependent and non-modular as your comments suggest, wouldn't that make changing significant parts of it even less likely to be successful? At that kind of level, you might be better putting the whole project into legacy mode with emergency updates only, and just letting it carry on for as long as it's useful and then die of natural causes when the time is right. For the other goals mentioned in the original proposal we were talking about, if there's sufficient interest to support doing that much work then an entirely new project with no baggage at all seems like a safer and more realistic bet.
hashhar 10y ago
Yes. Because the Thunderbird and Firefox codebases are diverging so much that instead of just maintaining Thudnebird people will have to maintain a fork of Gecko too.