[Hellzed]

Hi
Sorry for my bad English,I'm french and I stopped learning this language 2 years ago.
I have some ideas about a new linux freespace 2 open launcher.
IMHO, YAL or fs2-open#launcher, even if they are useful for configuring fs2_open, are NOT user friendly: too many buttons and options, while making a simple startup script (or getting it from ubuntu-fr or hard-light) is quick and easy...
In the same time, FSOInstaller is a good idea, but if I'm not wrong, we have to download the new version first, and then update freespace... It is usefull, but it seems a bit complicated too.
My idea is that we could make a single thing with these 2 programs for Linux users, with a very simple user interface.

I'm preparing mockups, but I have to explain how I want it to be (it could look like Edge of Choas launcher for people who played it):
- on the first run, it asks where to install the game (and it could detect older installations and update it)

- a start window, with the image of the currently selected mod, and only four button: Play (Play - Update - Settings - About, or Play(disabled) - Install - Settings - About if the game isn't installed)
- Play instantly launches the game, with the last settings.
- Update only updates currently installed files.
- Settings : exactly like YAL or  fs2-open#launcher settings: game folder, use debug build or not, video, graphics, audio, input ... ( we could get some parts of their source code)
- About Hard Light (with a link)...

- In the image of the mod (in a corner, for example), there could be a pop-up list with the installed mods, and a "Add/Remove" option, opening a mod browser, with a list of mods, descriptions, and a checkbox for each, to install or uninstall.
- Perhaps we could install or uninstall two or more mods at the same time ! And while it's installing, play the game, or leave the installer work (just an icon in the systray)...

So, what do you think about it ? Is someone interested ?

ps: I know I am talking about hours of hard work, and I am not a very good C or C++ (or Python) coder. But I'm one of the main contributor to the french fs2_open documentation on Ubuntu-fr wiki, and I think I know what users expect from an installer/launcher.

ps2: I think update system could work with a list of up-to-date files and their url so that url of a mod could change without breaking the update system, downloaded each time the launcher is started (or only when asked, it could be in the settings)... I candidate to be the maintainer of this kind of server !

ps3: the advantage of such a linux-only launcher is that it could detect the architecture (32 or 64) and download only the good binary. I always thinked amd64 support for FS2 had to be increased (official builds for example).

[karajorma]

I'm kinda surprised this got no responses (presumably because it referred to Linux in the title and everyone assumed it was nothing to do with them if they were on Windows or Mac OS X).

The eventual plan for FS2_Open is to end up with a single cross platform installer/launcher. Portej05 has been pushing for one for a while and I fully agree with the idea (and have suggested it myself in the past). I'd love to see your mock ups.

[kkmic]

Yeah, I'm surprised too that his did not got any attention.

Anyway, Hellzed please check your PM.
It seems that there were some trouble with the board recently, so if you missed my message, tell me.

[Hellzed]

I read your message !
So, as I told you, I've got many ideas, but since I have a little knowledge in programming, I know what can be done and what cannot. But I'm not a very good coder. I'm trying to learn GTK but it's a very slow work-in-progress. For example, I'm trying to do mockups with Glade, but it does not render as i want it to be...
And i really want this to be done, because I created this page : http://doc.ubuntu-fr.org/freespace (a complete install and configure guide for FreeSpace on Ubuntu), but it's still too hard for a beginner.

[kkmic]

GTK? I'm a KDE user, so I'd go for Qt  (not sure if it's that portable though...)

Anyway, Turey's installer does a pretty neat job ATM, I think you should concentrate in doing a launcher instead of a launcher/installer, as an installer needs work beyond the scope of a simple desktop application.

Looking forward for your mock-ups too.

And for someone to fix the board 

[Zacam]

I'd actually like to see a cross-platform Launcher/Manager/Installer where the Installer portion is also capable of applying updates.

Using cfile, cfileextractor and cfilearchiver, it should be possible to write something so that, for instance, future updates to the MediaVP's won't require re-downloading the whole shebang for what little may or may not have updated since the last version. Instead, you get an update package that rebuilds your VP's with the latest changed content.

[karajorma]

I'd suggest avoiding those files and just doing whatever WMCoolmon did with VPMage except in C++. That would give us the advantage of being able to choose whatever license we wanted for the launcher rather burdening ourselves with the one.

[Bobboau]

what he did was use java and thus avoided the issue entirely.

[karajorma]

Yeah I know that he used Java which is I why I said we should do the same in C++

Having an installer that can patch VP files would mean we need a hell of a lot less bandwidth for minor updates and it would remove the need to constantly have to manually deal with silly mistake via patches that half the fans forget/never hear about until they have a problem.

[Tomo]

GTK? I'm a KDE user, so I'd go for Qt  (not sure if it's that portable though...)

QT is indeed portable. My employer uses QT for all their 'new' projects, which are designed to run on both Windows and Mac.

However, Goober has been looking at the wxWidgets framework for FRED, and I think Spicious built a wxWidgets-based Stand-alone multi-server.

So it would make sense to use that framework, given that a fair bit of work has already been done using it.

[kkmic]

I still believe that there should be two separate applications (launcher and installer). But hey, you're welcome to prove me wrong

Being able to download small patches instead of the whole thing is a great idea, as long as someone is wiling to make and keep them available online.

And in this case we need a system to quickly determine what patches need to be downloaded for a certain file (sometimes you might need to download multiple patches to get a file up to date, and this situation should be considered too).

As for the launcher, I think that the only thing it has to do with updates is to quickly determine if there are updates available for your files (all of them? should you be able to select which one to check?) and prompt you to launch the installer. And this brings us back to the chicken or egg problem (since the installer basically should do the same checks as the launcher first before determining the required updates)

[Iss Mneur]

I still believe that there should be two separate applications (launcher and installer). But hey, you're welcome to prove me wrong

Ya they shouldn't be one program, but a suite of programs, which I hope is the plan.

And in this case we need a system to quickly determine what patches need to be downloaded for a certain file (sometimes you might need to download multiple patches to get a file up to date, and this situation should be considered too).

This could be fairly easily setup with a proper version number system and some meta-data for the installer to use.

As for the launcher, I think that the only thing it has to do with updates is to quickly determine if there are updates available for your files (all of them? should you be able to select which one to check?) and prompt you to launch the installer. And this brings us back to the chicken or egg problem (since the installer basically should do the same checks as the launcher first before determining the required updates)

Well just have the launcher call the check_for_updates program or function on the installer and just have the installer do the work and just return "up-to-date" or "needs-updates".  If the user wants to know what the updates are the launcher calls the installer show_needed_updates which will result in a URL to display in a web browser (the users default one or in something like a webkit window in the launcher).

Also, I would suggest using wxWidgets over qt, especially it there are other projects around freespace that are or will be in wxWidgets.  All in all there does not seem to be much here that difficult because most of the pieces already exist in some form (the existing launchers, Turey's installer) and just need to be tied together in a neat little cross-platform package.  That being said "neat little package" takes quite some time, and "cross-platform"....we will be at this a while.

Having stuck my head out like that, I am programmer and while my C/C++ is a bit rusty, I will be able to help in this endeavor starting in October.

[The E]

Okay, speaking from the POV of a support guy, I like having as few programs, with as few dependencies as possible. One Launcher, with an update functionality (however that will be implemented), would be fine by me. And I would prefer a complete, start-from-scratch rewrite to a quick hack job.

[kkmic]

This could be fairly easily setup with a proper version number system and some meta-data for the installer to use.

Indeed. I did not said that with the meaning "how could we do this", but rather as "there will be a little more work than just downloading one big file if it's different than what you have"

@The E:
Hellzed proposed an installer/launcher for Linux, this spilled over to a new installer proposal. Somehow, if we manage to make a unified and platform-independent launcher/installer, I feel it might be worth building it as an one application.

Me, I'm mostly a designer than a coder, though I wrote code too. Hellzed said he will try some mock ups, and I'm still waiting for them before putting anything on the table.

Iss Mneur, would you like to join this project as a coder, assuming that we manage to truly start it?

Open question:
What the purpose of the "Registry" tab in the launcher? Who uses the registry? The launcher? FS2_Open?  Both? If FS2_Open uses it, does it really need to?
I mean, I want to know if we can scrap that tab. I always disliked the registry, and it's not portable.

[The E]

The registry tab shows the current state of all registry keys the selected executable uses. Just like the command-line readout in the features tab, it serves mostly as a quick way to find out if all the settings are correct. Speaking again as a troubleshooting person, I would hate to lose it.
Of course it would have to be adapted for the way this data is stored on MacOS and Linux; but a function like that is still useful, IMHO.

[portej05]

I've been evaluating using the RakNet autopatcher system for this, and the Qt framework (I'm more familiar with that than wxWidgets).

FSO uses the registry under windows - it's ugly, but we're working on removing the dependence on that.

[The E]

Yeah, but unfortunately, the registry read/write functionality has to be maintained for older builds to work correctly with the new Launcher.

[kkmic]

I would rather see it gone (the registry dependence).

I understand that the old builds NEED to read something from the registry, but I'd keep the settings in a file and WRITE them to the registry before launch, if the current OS is Windows and if the build requires it. Otherwise, everything else is passed through to the binary via parameters at launch.

How is  the registry dependence handled on OSX? In Linux is a simple config file in ~/.fs2_open if I remember correctly.

[The E]

Umm. The Linux and MacOS builds store their settings in a config file somewhere else. And once you write some values to the registry (which happens when you start the Launcher and click "Run"), those values stay there, unless you delete those settings again when the program exits. The way it is currently handled is the best one available for the circumstances.

[portej05]

The other issue is that there's some limit to the length of the command line (IIRC) on windows, and we have _a lot_ of possible command line parameters, which are currently (if I've read the code correctly) passed to the engine through a text file (way to go to mix everything up ).
Just passing them to the engine on the command line might not be feasible.