It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Community
General discussion (archive)GamesDesktop : A launcher for GOG - Pre-Alpha - Help needed(46 posts)(46 posts)
(46 posts)
Pages:
1
2
3
4
This is my favourite topic
Posted February 10, 2014
avatar
HiPhish: I'm still curious abut this part:

How are you going to keep the app up to date? Do you have someone constantly update a database or is there a form of official API you can hook up to?
avatar
HiPhish:
OK, there are a couple of things at work here:
1. GOG is pretty good about storing everything relevant in the Windows Registry. You don't actually need to keep track of much. Which games are installed, where they are installed, how to launch them... you can get all that from the registry.
2. That contains the supportlink ID... the link title. Unfortunately, these are sometimes missing from old installers. For that, I'd keep things simple. A simple text file for each game id on my servers that contains the support link as a fallback.
3. You can also do stuff like searching, querying the available games and so on via the AJAX api supplied at http://www.gog.com/games/ajax . For example [url=http://www.gog.com/games/ajax?a=search&f={%22sort%22:%22added%22}&p=1]http://www.gog.com/games/ajax?a=search&f={%22sort%22:%22added%22}&p=1[/url] gives you a neat list of all games available (the p=# is the page number).
For example, I'm using the search right now as a fallback for games without a support id.
4. A few things are not available via the AJAX API. For example the cover art or this neat list of news items (you can however use the RSS feed, but the one on the page is just nicer). For that you can use the DOM API (remember, XULRunner is a browser at heart) to extract and display the relevant information (as I am currently doing for cover art and news items).
5. For everything else, there's SQLITE, which is hard-baked into XULRunner and works wonderfully for small, local databases. For example, I'm using it right now for a caching mechanism.

avatar
Daniel Ruf: awesome
XULRunner looks interesting.
In my opinion one of the most under-appreciated tools around. WebKit is nice, but it's so much easier getting started with XULRunner. You just create a couple of config files, a XUL or HTML page and voilà: Your first alpha release is ready. And you can access all the Mozilla internal functions (which do stuff like file access, registry access and so on), as well as any other DLL via JS-CTypes. You want to manage memory manually? Fine, just import malloc and free. You want Joystick support? Well, you can try the COM interface, but I'd suggest simply loading the SDL DLL...
avatar
Daniel Ruf: awesome
XULRunner looks interesting.
If I understand it correctly, you want to make it a C app? Why not Java? You can also make a local webserver with it and use an embedded database like H2. But this was just an idea from me.

What are your plans for future releases?
I actually want to make it a Javascript app. I think it's simply the most awesome language around, with a lot more flexibility than Java. C is great, but I actually like the DocumentObjectModel and well... accessing the DOM from C is always a pain.

About the database: SQLite is really more than enough. We're not talking about Gigabytes of data here :)
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
hansschmucker: snip
Mh, and the GOG API? Could be helpful to use it for getting missing information.
Well, RSS just stores just the latest news or gives a limited result.
SQLite is great for the project.

Sounds good, but isn't this all limited to Windows? DLL, COM and so on ... not really crossplatform
So the app will be just available for Windows?

Well, there is for example Jsoup for Java, which is a very mature HTML processing library. Also it is still a C app with Scripting (JavaScript)

Did you try htmlcxx which is also used for lgogdownloader by Sude? Mh, personally I would say Java is more flexible than JavaScript as a Java and JavaScript developer ;-)

Do you plan to release the sourcecode on Github?

Why do you want to use something else than XUlRunner?
We can get this running on all platforms:
https://github.com/neam/webapp-xul-wrapper
http://www.zotero.org/support/dev/client_coding/building_the_standalone_client
Post edited February 10, 2014 by Daniel Ruf
Posted February 10, 2014
avatar
Daniel Ruf: Mh, and the GOG API? Could be helpful to use it for getting missing information.
Hmm... is there an additional GOG API? Sorry, apparently I missed that

avatar
Daniel Ruf: Well, RSS just stores just the latest news or gives a limited result.
SQLite is great for the project.
That's why I prefer the version available on the page, which is really, really easy to import.

avatar
Daniel Ruf: Sounds good, but isn't this all limited to Windows? DLL, COM and so on ... not really crossplatform
So the app will be just available for Windows?
Well, GOG is only available on Windows. Under Linux I could use WINEs registry, but let's be honest: There simply is no way to support a service that's only available on one platform cross-platform.

About XULRunner in general: The internal classes are platform-independent, as far as possible (like I said, you can't have cross-platform registry access), but of course if you call into C libraries, then you are limited by the inherit platform-dependence of binaries. If the library is available cross-platform, like SDL, you can use the same code.

avatar
Daniel Ruf: Well, there is for example Jsoup for Java, which is a very mature HTML processing library. Also it is still a C app with Scripting (JavaScript)
Well, XULRunner is a C application too... so it pretty much comes out the same... it's just how you define C-application or Javascript-application. At some point you always end up with something low-level.

avatar
Daniel Ruf: Did you try htmlcxx which is also used for lgogdownloader by Sude? Mh, personally I would say Java is more flexible than JavaScript as a Java and JavaScript developer ;-)
Haven't looked at it yet, but I seem to have some faint recollections. About Javascript:
I was talking only about the language, not the base-libraries.
Java has very restricted syntax, often with very strange workarounds to make it usable. Aside from the cursed RegEx literal (try writing a JS tokenizer... urgh), Javascript is very clean, with simple constructs. But these simple constructs can be re-used in practically every situation and you can make them do almost everything you want. There's a reason I like to compare Javascript to C. Simpler syntax, more flexibility.
It's not always what you need, because it's harder to analyze... but for writing, I'd prefer it to just about any language.

avatar
Daniel Ruf: Do you plan to release the sourcecode on Github?
That would be one way... So far I haven't used GIT, but I think it's about time. But you can read the sourcecode directly inside the alpha download. It's in the chrome directory.
avatar
Daniel Ruf: Mh, and the GOG API?
Found it! https://github.com/lhw/gogdownloader/wiki/API

Thanks for the pointer. Didn't event know it existed. Yes, I would definitely want to use this.

So... any suggestions regarding license? I usually prefer the Affero General Public License
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
Daniel Ruf: Mh, and the GOG API? Could be helpful to use it for getting missing information.
avatar
hansschmucker: Hmm... is there an additional GOG API? Sorry, apparently I missed that
Sure: https://github.com/DanielRuf/xgogdownloader/blob/master/src/Api.java#L84
Or did I misunderstand you?
I have also updated my latest comment about building XULRunner apps for different platforms at once.
avatar
Daniel Ruf: Well, RSS just stores just the latest news or gives a limited result.
SQLite is great for the project.
avatar
hansschmucker: That's why I prefer the version available on the page, which is really, really easy to import.
avatar
Daniel Ruf: Sounds good, but isn't this all limited to Windows? DLL, COM and so on ... not really crossplatform
So the app will be just available for Windows?
avatar
hansschmucker: Well, GOG is only available on Windows. Under Linux I could use WINEs registry, but let's be honest: There simply is no way to support a service that's only available on one platform cross-platform.

About XULRunner in general: The internal classes are platform-independent, as far as possible (like I said, you can't have cross-platform registry access), but of course if you call into C libraries, then you are limited by the inherit platform-dependence of binaries. If the library is available cross-platform, like SDL, you can use the same code.
GOG on one platform? Where does GOG store the information on a Mac?
avatar
Daniel Ruf: Well, there is for example Jsoup for Java, which is a very mature HTML processing library. Also it is still a C app with Scripting (JavaScript)
avatar
hansschmucker: Well, XULRunner is a C application too... so it pretty much comes out the same... it's just how you define C-application or Javascript-application. At some point you always end up with something low-level.
avatar
Daniel Ruf: Did you try htmlcxx which is also used for lgogdownloader by Sude? Mh, personally I would say Java is more flexible than JavaScript as a Java and JavaScript developer ;-)
avatar
hansschmucker: Haven't looked at it yet, but I seem to have some faint recollections. About Javascript:
I was talking only about the language, not the base-libraries.
Java has very restricted syntax, often with very strange workarounds to make it usable. Aside from the cursed RegEx literal (try writing a JS tokenizer... urgh), Javascript is very clean, with simple constructs. But these simple constructs can be re-used in practically every situation and you can make them do almost everything you want. There's a reason I like to compare Javascript to C. Simpler syntax, more flexibility.
It's not always what you need, because it's harder to analyze... but for writing, I'd prefer it to just about any language.
Well, because of this there are great Java libraries. But this is unimportant as we want to use the XULRunner solution in the future? I do not know hoch much Java experience you have, but Java is one of the most used languages (Twitter, Google, Facebook, ...) ;-)
avatar
Daniel Ruf: Do you plan to release the sourcecode on Github?
avatar
hansschmucker:
avatar
hansschmucker: That would be one way... So far I haven't used GIT, but I think it's about time. But you can read the sourcecode directly inside the alpha download. It's in the chrome directory.
This would be very helpful as issues, commits, and pull requests are much easier when using Git or Github
avatar
Daniel Ruf: Mh, and the GOG API?
avatar
hansschmucker:
avatar
hansschmucker: Found it! https://github.com/lhw/gogdownloader/wiki/API

Thanks for the pointer. Didn't event know it existed. Yes, I would definitely want to use this.
I know, C is very annoying but if you are in, it is not so hard.

So, you are also looking for webdevelopers as they use mostly JavaScript?
Posted February 10, 2014
I think OS portability to Linux and OS X should be a concern; while those operating systems are not officially supported that doesn't mean people don't use them. At least downloading and updating installers should work on all operating systems, allowing you to choose which installer you download. Not like Steam where you can't download Windows games when you're on OS X.

Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.
Post edited February 10, 2014 by HiPhish
Posted February 10, 2014
avatar
HiPhish: I think OS portability to Linux and OS X should be a concern; while those operating systems are not officially supported that doesn't mean people don't use them. At least downloading and updating installers should work on all operating systems, allowing you to choose which installer you download. Not like Steam where you can't download Windows games when you're on OS X.

Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.
There's very little you can do cross-platform. As you say, the UI has to be native to the OS. Also looking for installed games has to be native. The only cross-platform thing is calling the GOG APIs.
Posted February 10, 2014
avatar
Daniel Ruf: Why do you want to use something else than XUlRunner?
We can get this running on all platforms:
https://github.com/neam/webapp-xul-wrapper
http://www.zotero.org/support/dev/client_coding/building_the_standalone_client
Wait... I never said I wanted to use anything but XULRunner.

avatar
hansschmucker: Hmm... is there an additional GOG API? Sorry, apparently I missed that
avatar
Daniel Ruf: Sure: https://github.com/DanielRuf/xgogdownloader/blob/master/src/Api.java#L84
Or did I misunderstand you?
No, I really missed it. Happens from time to time when you don't expect something to exist :)

avatar
Daniel Ruf: GOG on one platform? Where does GOG store the information on a Mac?
Whoops. Forgot about Macs. No idea how it works there... my guess is that we'd enumerate the application bundles directly, but I have ZERO experience on Macs. Nothing. I know them from a user's perspective and I really don't like the interface logic, but that's about all I know. So that would have to be something that somebody with an actual Mac does. Shouldn't be an issue though. I define an interface and somebody who wants it to run on a Mac adds a class that implements it. Done.

avatar
Daniel Ruf: Well, because of this there are great Java libraries. But this is unimportant as we want to use the XULRunner solution in the future? I do not know hoch much Java experience you have, but Java is one of the most used languages (Twitter, Google, Facebook, ...) ;-)
I know Java alright. Same as C... I could write it in either of them, but it would just be more work... that's all there is to it :)

avatar
Daniel Ruf: This would be very helpful as issues, commits, and pull requests are much easier when using Git or Github
Alright, I'll set up an account right away.

avatar
HiPhish: I think OS portability to Linux and OS X should be a concern; while those operating systems are not officially supported that doesn't mean people don't use them. At least downloading and updating installers should work on all operating systems, allowing you to choose which installer you download. Not like Steam where you can't download Windows games when you're on OS X.

Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.
There really isn't that much aside from the interface that you could share between those programs. I'd say that all we can do is either giving the application its own look on all platforms, or ignore MacOS altogether :(


EDIT:
First Version is up on GitHub:
https://github.com/hansschmucker/GamesDesktop
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
HiPhish: I think OS portability to Linux and OS X should be a concern; while those operating systems are not officially supported that doesn't mean people don't use them. At least downloading and updating installers should work on all operating systems, allowing you to choose which installer you download. Not like Steam where you can't download Windows games when you're on OS X.

Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.
downloaders are already available, like lgogdownloader and the upcoming xgogdownloader ;-)
I pan to release a version of xgogdownloader with GUI

But if I have understood correctly, GameDesktop should not be like Steam and should only show the installed games on the computer, no downloading or updating of installers if I know so far.
avatar
HiPhish: I think OS portability to Linux and OS X should be a concern; while those operating systems are not officially supported that doesn't mean people don't use them. At least downloading and updating installers should work on all operating systems, allowing you to choose which installer you download. Not like Steam where you can't download Windows games when you're on OS X.

Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.
avatar
ChrisSD: There's very little you can do cross-platform. As you say, the UI has to be native to the OS. Also looking for installed games has to be native. The only cross-platform thing is calling the GOG APIs.
UI generally has not to be native, but in this case yes.
Also looking for installed games can be solved crossplatform (with the right libraries) ;-)
Post edited February 10, 2014 by Daniel Ruf
Posted February 10, 2014
avatar
hansschmucker: There really isn't that much aside from the interface that you could share between those programs. I'd say that all we can do is either giving the application its own look on all platforms, or ignore MacOS altogether :(
I don't think so. Take a look at the Model-View-Controller pattern:
http://en.wikipedia.org/wiki/Model–view–controller

The model would be written once and made cross-platform as a library, while the view and controller would be OS-specific. Someone writing a client for their toaster would just need to hook up to the view, where the heart of the application lies. That way someone could even write a text-based GOG client, if they really want.
Posted February 10, 2014
avatar
hansschmucker: EDIT:
First Version is up on GitHub:
https://github.com/hansschmucker/GamesDesktop
Awesome, thanks. I will take a look at it =)

avatar
hansschmucker: There really isn't that much aside from the interface that you could share between those programs. I'd say that all we can do is either giving the application its own look on all platforms, or ignore MacOS altogether :(
avatar
HiPhish: I don't think so. Take a look at the Model-View-Controller pattern:
http://en.wikipedia.org/wiki/Model–view–controller

The model would be written once and made cross-platform as a library, while the view and controller would be OS-specific. Someone writing a client for their toaster would just need to hook up to the view, where the heart of the application lies. That way someone could even write a text-based GOG client, if they really want.
But the problem is, to support this pattern in XULRunner as the project will still use XULRunner
The view and UI is already crossplatform (XUL) or did you mean creating a fork and starting from zero with another solution than XULRunner?
Post edited February 10, 2014 by Daniel Ruf
Posted February 10, 2014
avatar
hansschmucker: There really isn't that much aside from the interface that you could share between those programs. I'd say that all we can do is either giving the application its own look on all platforms, or ignore MacOS altogether :(
avatar
HiPhish: I don't think so. Take a look at the Model-View-Controller pattern:
http://en.wikipedia.org/wiki/Model–view–controller

The model would be written once and made cross-platform as a library, while the view and controller would be OS-specific. Someone writing a client for their toaster would just need to hook up to the view, where the heart of the application lies. That way someone could even write a text-based GOG client, if they really want.
I know the model, but try to apply it here: There really isn't much to do outside the view... and what is to do is platform-dependent! And the view isn't appropriate for MacOS. It really only makes any sense if we use the same view for MacOS as well, which probably wouldn't be accepted by users and therefore not worth the trouble.
avatar
HiPhish: Actually, the more I think about it, maybe it would be better to have a separate GOGTools library that handles all the low-level logic and then the actual client is built using that library and tailored specifically for the OS in question. I can tell you for a fact that Mac users can spot anything not written in Cocoa, even if you emulate the look down to the pixel.
avatar
Daniel Ruf: downloaders are already available, like lgogdownloader and the upcoming xgogdownloader ;-)
I pan to release a version of xgogdownloader with GUI

But if I have uderstood correctly, GameDesktop should not be like Steam and should only show the installed games on the computer, no downloading or updating of instakkers if I know so far.
Maybe at some point, but definitely not right away.
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
avatar
HiPhish: I don't think so. Take a look at the Model-View-Controller pattern:
http://en.wikipedia.org/wiki/Model–view–controller

The model would be written once and made cross-platform as a library, while the view and controller would be OS-specific. Someone writing a client for their toaster would just need to hook up to the view, where the heart of the application lies. That way someone could even write a text-based GOG client, if they really want.
avatar
hansschmucker: I know the model, but try to apply it here: There really isn't much to do outside the view... and what is to do is platform-dependent! And the view isn't appropriate for MacOS. It really only makes any sense if we use the same view for MacOS as well, which probably wouldn't be accepted by users and therefore not worth the trouble.
You mean because they want a view that looks native to them?
Nearly impossible. Why would they not accept it?
Posted February 10, 2014
avatar
Daniel Ruf: But the problem is, to support this pattern in XULRunner as the project will still use XULRunner
The view and UI is already crossplatform (XUL) or did you mean creating a fork and starting from zero with another solution than XULRunner?
Here is my "idea": The model would be written to be as simple as possible, in just C and it would not be able to do anything on its own, it would be just a library. Anything that's platform-specific could be handled by an appropriate library or conditional compiling.

Someone writing a client would take that library as the model and write the view and controller, i.e. the parts the user is interacting with, using Cocoa, .NET, Qt or whatever, even a command-line interface if they want to. Or XULRunner if that is a possibility.

To see this approach in action take a look at the BitTorrent client Transmission:
http://www.transmissionbt.com
See how the same application differs from platform to platform, even supporting a browser interface and a command-line interface. Only the top level needs to be custom-made, the rest is shared.

avatar
Daniel Ruf: You mean because they want a view that looks native to them?
Nearly impossible. Why would they not accept it?
it's not just about looking native; if you want to just look native you can use Qt. It has too work like native.
Post edited February 10, 2014 by HiPhish
Posted February 10, 2014
avatar
hansschmucker: I know the model, but try to apply it here: There really isn't much to do outside the view... and what is to do is platform-dependent! And the view isn't appropriate for MacOS. It really only makes any sense if we use the same view for MacOS as well, which probably wouldn't be accepted by users and therefore not worth the trouble.
avatar
Daniel Ruf: You mean because they want a view that looks native to them?
Nearly impossible. Why would they not accept it?
You think they would? I've got no idea, honestly. The mind of an average Apple user is a complete mystery to me ;)
avatar
HiPhish: Here is my "idea": The model would be written to be as simple as possible, in just C and it would not be able to do anything on its own, it would be just a library. Anything that's platform-specific could be handled by an appropriate library or conditional compiling.
You misunderstand the problem. The model is about as complex as the communication between such a model and the view would be. It's not hard. It's just a bit pointless in this specific case. In general, you're entirely correct, just in this case things are a little different.
Post edited February 10, 2014 by hansschmucker
Posted February 10, 2014
I don't think it's pointless, such a "GOGTools" library could be used by various projects. We already have an unofficial Linux downloader, a Java port of said downloader and now a Windows client. I just think it would make sense to sit down and write this one part once rather than having everyone re-invent the wheel. Oh sure, you can look at someone else's code and adapt it to your needs, usually that's not that hard, the problem is that each of those implementations has to be maintained individually instead of just updating it once and everyone profits.

Yeah, it won't matter in this case, not in the next or the one after that, but in the big picture it's re-inventing the wheel each time.
Pages:
1
2
3
4
This is my favourite topic
Community
General discussion (archive)GamesDesktop : A launcher for GOG - Pre-Alpha - Help needed(46 posts)(46 posts)
(46 posts)