20,741
edits
Talk:TerraGear scenery build server: Difference between revisions
Jump to navigation
Jump to search
Talk:TerraGear scenery build server (view source)
Revision as of 15:03, 15 February 2014
, 15 February 2014→WebService / UI (Gijs, Hooray, reeed ): new section
(→WebService / UI (Gijs, Hooray, reeed ): new section) |
|||
| Line 51: | Line 51: | ||
* http://www.turnkeylinux.org/forum/support/20120507/how-create-customized-appliance | * http://www.turnkeylinux.org/forum/support/20120507/how-create-customized-appliance | ||
* https://github.com/turnkeylinux-apps/tkldev/tree/master/docs | * https://github.com/turnkeylinux-apps/tkldev/tree/master/docs | ||
== WebService / UI (Gijs, Hooray, reeed ) == | |||
'''Gijs:'''It'd be nicer/better to have a web interface. That'll allow you to keep the interface and backend in sync (without asking people to recompile/redownload the GUI om each change), save people from downloading yet another tool and make it work/look the same on all systems. | |||
: '''Hooray:''' As I mentioned on the forum, I am not at all opposed to having a webservice, I just consider it much more straightforward to modify [[TerraGear GUI]] for now. if there's anybody interested in working on a web interface that would obviously be great, but short of that, I would simply modify TerraGear GUI to support two modes local (default) and remote (build server) over SSH. I already looked at the code briefly and the main issue is the amount of Qt code that runs locally, i.e. to download stuff for example - if that could be moved out into external programs, preferably part of TerraGear itself, then it would be trivial to support both, local AND remote TG installations. Currently, there's just too much stuff directly done, without calling external tools - so that would need to be factored out. | |||
: Overall, the TerraGear GUI is not such a complex code base, so I am not sure if keeping the frontend/backends in sync is such a huge issue ?? I mean, people ALREADY need to have a matching TG/TGGUI versions after all ... | |||
: I am certainly not going to stop anybody from coming up with a webservice - it's just something that I am probably not going to work on anytime soon - while modifying TGGUI accordingly would just take a few hours and involve well-understood steps. | |||
: So I wasn't thinking of forking TGGUI, but more about extending it to support local AND remote installations - selected/configured during startup. | |||
: Obviously you are much more familiar with the code in question here - but based on what I've seen, it would not be such a difficult undertaking to turn TGGUI into a "remote control" for a TG build server setup. | |||
: If frontend changes are such an issue, I would actually suggest to get rid of the hardcoded GUI and use Qt's scripting support for those *.ui files instead - that would allow you to automatically download QtScript while booting. | |||
: Finally, coming up with a working web service is in my opinion more difficult than using SSH to teach TGGUI to run a handful of commands remotely and fetch the results via SFTP - so yeah, I am kinda lazy here | |||