Closed Eitot closed 4 years ago
For the browser side, it is not necessary just yet. I will just build in a switch which selects the appropriate browser version depending on the macOS version.
I was looking at FeedKit, which requires 10.10. This version will also allow us to use NSVisualEffectView instead of the gradient views we currently have (which do not look good in dark mode yet). Raising it to 10.10 also exposes a bunch of deprecation warnings in Xcode, which we need to tackle at some point as well.
I would also be open to create a separate development branch for 10.10, that we could later merge with master.
For issues like FeedKit, VisualEffectsView and others (also basically WebKit), I agree to make a separate branch. We can then develop freely for 10.10, drop everything old, fix deprecations and move on to storyboards. When publishing Vienna 4.0, we can drop 10.9 support by replacing the master with our 10.10 branch. But we should keep a 10.9 branch around, and have a special label for tickets that are only related to 10.9, so we can fix them.
Thats why we kept legacy branches around. Issues that can be applied to previous versions can be applied there too, but structural improvements are applied only to master.
So the synopsis is, that we will finish developing 3.3, then concentrate on dropping everything and enhancing with the possibilities of 10.10 from then on? I think, then I will separate the browser cleanup for the old version and the new browser development.
I can understand your intellectual interest in FeedKit, but I would recommend the greatest caution and a lot of testing before deciding on such a change. The parsing code in Vienna is very mature and experienced and I am not convinced that it is easy to quickly reach the same capacity to deal with all the vicious cases that we encounter on the Internet.
Sometimes, old code is good code!
Related : #889
I am actually not that interested in it. I would prefer not relying on third-party frameworks at all. However, the code looks clean and is up-to-date and does exactly what the current parser does and nothing more. Reinventing the wheel would only further encapsulate and duplicate readily available open source code.
FeedKit is not the primary reason for 10.10. I have a bunch of branches ready that I would like to submit and continue working on.
My main interest in 10.10 is WKWebView which is probably safer than WebKit.
Which is all the more reason to do the groundwork. I am in favour of starting a separate developer branch that we can merge into master at a later stage. Then we can have a testing phase too, as we did before.
@TAKeanice mentioned that Yosemite has some quirks/shortcomings in relation to WKWebView that aren’t fully resolved until El Capitan. I would also like continuing cleaning up the view-controller code and it would help to have the improvements of El Capitan here as well.
What are your opinions on going straight to El Capitan, while we are at it? By the time testing is done and a release is in sight, 10.15 will probably have been announced.
Yes there are, and I think it is totally ok to jump. From Wikipedia about el Capitan:
All Macintosh computers that can run Mountain Lion, Mavericks, or Yosemite can run El Capitan,[6] although not all of its features will work on older computers.[7] For example, Apple notes that the newly available Metal API is available on "all Macs since 2012".
in contrary to Sierra, which dropped (according to CNET):
MacBook from 2008 and early 2009 MacBook Air from 2008 and 2009 MacBook Pro from 2007, 2008 and 2009 iMac from 2007, 2008 and early 2009 Mac Mini from 2009 Mac Pro from 2008 and 2009
This is not a list of computers that I would consider very relevant any more though, so I think within Vienna 4.x we could already begin to move on (as soon as we see relevant reasons to do so)
My main interest in 10.10 is WKWebView which is probably safer than WebKit.
Well, maybe not safer but more performant in any case! Additionally, the same API (even some more functions) exist on iOS. This could be one step towards an iOS version of Vienna!
We could aim end of February for the release of a stable El Capitan version (3.6.0)
What changes do you expect to be included in this ?
I want to go over Interface Builder and continue working on the transition towards Storyboard. MASPreferences will also no longer be needed.
I have started a branch for El Capitan here: https://github.com/Eitot/vienna-rss/tree/elcapitan
https://github.com/ViennaRSS/vienna-rss/projects/10 is the project I will work on, with enhancements mainly for el capitan
For the storyboard transition, the main and most difficult thing to do is putting the TabBar into a proper ViewController. There must be a custom solution to embed the articles tab via a segue as the first tab. I built the API of the browser so that a first tab can be set manually (just like the articles tab), but to use the storyboard properly, we should make the embedding of that tab visual.
As 3.6 gets closer to a release, I would also recommend sending out a heads up for the translators. Currently only 5 out of 20 localizations are fully up to date.
As we find ourselves facing another new macOS release, it makes sense to drop at least 10.9 and 10.10 support. I believe all macs that can run 10.9 can upgrade to 10.11 anyway. People are still free to use 3.5.x versions of Vienna on 10.9 and 10.10.
The project is essentially uhmm "sleeping" at 3.5.x currently anyway. We need to make some big changes for macOS BS due to the new UI, so now is the right time to drop the older stuff.
As I have by now sorted out my personal situation, and with the prospect of making those big changes, I am eager to try once again and replace the long-deprecated webview with the webkit api.
Closed by #1308
I think we agreed at some point that we would continue supporting older versions of macOS as long as no need arises to lift the minimum OS requirement for a particular enhancement or code change at the time of its merging. However, while working on several changes, I found it tedious to set to minimum OS, discovering a bunch of problems that would have to be fixed as well.
I propose to raise the minimum requirement to 10.10 now, so that we can continue working from there. We may want to create another legacy branch, as we did previously.
Thoughts?