I think version 1.0 and 1.5 on macOS were a Web app, but IIRC Gog galaxy 2.0 was finally native on macOS, which they made a really, really, really big deal about. Although, it wouldn’t surprise me if it’s just a native app framework with a mostly web-reliant backend.
Given that we haven’t gotten it yet
I can’t speak to their development priorities, but from what I understand, they don’t exactly have a huge dev team over there. I’ve learned to be patient with them.
What I mean is that if they wanna make a linux native client that’s not just a web interface in a shell, then, yeah, it’s gonna take a bunch of effort. And their dev team is already stretched between maintaining a windows native and a relatively new macos native client.
But with most of the work already done and having made a macOS native client, pouring that to linux shouldn’t be too much more work. A lot of the extra work there should be in leveraging open source libraries to replace whatever proprietary Apple stuff they were using to make it work on macOS. (kind of guessing here)
Aye, I follow you. I honestly couldn’t say yay or nay. Might be as easy as switching some libraries out and making a good GUI in Qt/Adwaita/what have you, like what Kagi is doing with Orion. It could be more involved than that too.
my point is, i suppose, that most of the hard work of making a *NIX-version is done (or, at least half-2/3). macOS is BSD with a bunch of proprietary stuff added on by Apple. strip it down, and it’s still BSD and works like BSD/UNIX. so, usually getting something to be cross-compatible isn’t that difficult– at least not so bad as porting something directly from Windows.
hehe… but it’s certainly a lot easier going from linux > macOS than the other way around. that process is usually a seamless matter of downloading a couple of extra dependancies via homebrew.
I think version 1.0 and 1.5 on macOS were a Web app, but IIRC Gog galaxy 2.0 was finally native on macOS, which they made a really, really, really big deal about. Although, it wouldn’t surprise me if it’s just a native app framework with a mostly web-reliant backend.
I can’t speak to their development priorities, but from what I understand, they don’t exactly have a huge dev team over there. I’ve learned to be patient with them.
But I get where you’re coming from
Ah, well if they’re aiming to make a native client I can see it taking a bunch of extra time.
What I mean is that if they wanna make a linux native client that’s not just a web interface in a shell, then, yeah, it’s gonna take a bunch of effort. And their dev team is already stretched between maintaining a windows native and a relatively new macos native client.
But with most of the work already done and having made a macOS native client, pouring that to linux shouldn’t be too much more work. A lot of the extra work there should be in leveraging open source libraries to replace whatever proprietary Apple stuff they were using to make it work on macOS. (kind of guessing here)
Aye, I follow you. I honestly couldn’t say yay or nay. Might be as easy as switching some libraries out and making a good GUI in Qt/Adwaita/what have you, like what Kagi is doing with Orion. It could be more involved than that too.
my point is, i suppose, that most of the hard work of making a *NIX-version is done (or, at least half-2/3). macOS is BSD with a bunch of proprietary stuff added on by Apple. strip it down, and it’s still BSD and works like BSD/UNIX. so, usually getting something to be cross-compatible isn’t that difficult– at least not so bad as porting something directly from Windows.
hehe… but it’s certainly a lot easier going from linux > macOS than the other way around. that process is usually a seamless matter of downloading a couple of extra dependancies via homebrew.