Jump to content
Eternal Lands Official Forums
Entropy

Server chooser GUI

Recommended Posts

Can you show us some more screenshots please?

 

This is one from today, it shows a tooltip in the messageline at the bottom of the screen according to the button under the mouse.

 

Screenshot-EternalLandsServerSel-5.png

 

Since this application has only one screen, and there isn't that much action to see, what kinds of screenies are you looking for? Something specific?

 

And what is your opinion about Torg's post? Any suggestions or is the tooltip, like it's now ("click here to connect..") ok?

 

Piper

 

PS: Volunteers needed to test it for Windows and OSX, i will post a link to the source code here soon (when i'm done with cleaning up, documentation and such lovely things)

Share this post


Link to post
Share on other sites
*Bump*

Any input/suggestions/ideas/volunteers to test it under different OS?

 

1) I get a compile warning... "main.c: In function ‘main’: main.c:67: warning: implicit declaration of function ‘word’"

2) I still think it would be nice if moving the mouse of a button changed the highlight in the way pressing tab does.

3) The loading is now low when idling but still high when moving the mouse in the window, or when pressing tab etc.

 

Sorry, here comes some rather 'me' specific ramblings.....

 

4) As I understand your readme, the server bin must be in the same directory as the the bitmap and the server.lst file, and you must run the launcher from that directory too. Also the error log is written to the same location. This set up will be difficult to use for system wide installs or for the Debian/Ubuntu packages. There will be both permissions issues and problems with where the files are located; the bin would usually go in a different location to the image for example.

 

5) I've been trying to think how I could integrate this launcher into the Debian/Ubuntu packages. For these I already have a very simple launcher that uses zenity. The launcher itself does not run the client but simply returns (writes to stdout) the chosen server configuration name to use, e.g. main, pk or test etc. A wrapper script actually runs the client. This allows the launcher to be simple and flexibility is provided by the wrapper script. The wrapper script does all the data_dir checks and sets up the users ~/.elc directory first time through. It also detects a client crash and pops up a window with the contents of the error_log and any (more recently) client output.

 

So, I wonder if you could consider two things related to 5 & 6. i) Could the launcher have a mode that simply outputs the chosen server configuration name rather than launches the client? ii) Could the path+name to the image and the server.lst file be optionally specified on the command line? I could probably work without i) if the launcher had ii) and rather than calling system() to run the client, used exec() and so returned the client exit status. Obviously, this would not help -stay mode.

 

I realise your launcher is intended for a wider use that I'm considering but it would be nice to use it in place of zenity. I'm happy to help with patches if you're ready for contributions. :P

Share this post


Link to post
Share on other sites
1) I get a compile warning... "main.c: In function ‘main’: main.c:67: warning: implicit declaration of function ‘word’"

Funny, i dont. I'll have a look at it.

2) I still think it would be nice if moving the mouse of a button changed the highlight in the way pressing tab does.

Done. Dunno if it looks better or not, but at least it doesnt look ugly :P

3) The loading is now low when idling but still high when moving the mouse in the window, or when pressing tab etc.

I'll have a look at it. But since the program terminates (without -stay), i wont call it a big problem.

Sorry, here comes some rather 'me' specific ramblings.....

 

4) As I understand your readme, the server bin must be in the same directory as the the bitmap and the server.lst file, and you must run the launcher from that directory too. Also the error log is written to the same location. This set up will be difficult to use for system wide installs or for the Debian/Ubuntu packages. There will be both permissions issues and problems with where the files are located; the bin would usually go in a different location to the image for example.

 

5) I've been trying to think how I could integrate this launcher into the Debian/Ubuntu packages. For these I already have a very simple launcher that uses zenity. The launcher itself does not run the client but simply returns (writes to stdout) the chosen server configuration name to use, e.g. main, pk or test etc. A wrapper script actually runs the client. This allows the launcher to be simple and flexibility is provided by the wrapper script. The wrapper script does all the data_dir checks and sets up the users ~/.elc directory first time through. It also detects a client crash and pops up a window with the contents of the error_log and any (more recently) client output.

 

So, I wonder if you could consider two things related to 5 & 6. i) Could the launcher have a mode that simply outputs the chosen server configuration name rather than launches the client? ii) Could the path+name to the image and the server.lst file be optionally specified on the command line? I could probably work without i) if the launcher had ii) and rather than calling system() to run the client, used exec() and so returned the client exit status. Obviously, this would not help -stay mode.

So with 3 more command line parameters your problems could be solved?

 

-b<path_to_client.binary>

-l<path_to_error_log>

-d<path_to_data>

 

(if no parameter is given, the current directory would be used)

 

And i dont have an idea why just printing out the arguments for the client, instead of starting the client, would be useful. Isnt it easier just to look at servers.lst instead?

 

About shell() vs. exec(), the program terminates now (without -stay), so there is no need/possibility to check the return code of a crashing client and display error messages.

 

Piper

Share this post


Link to post
Share on other sites
So with 3 more command line parameters your problems could be solved?

-b<path_to_client.binary>

-l<path_to_error_log>

-d<path_to_data>

(if no parameter is given, the current directory would be used)

Yep, that would do it and if I could specify /bin/echo for the path_to_client.binary then I can get the information I need to start the client from the wrapper script.

 

And i dont have an idea why just printing out the arguments for the client, instead of starting the client, would be useful. Isnt it easier just to look at servers.lst instead?

The server selection GUI (your nice shiny EL themed one or my current ugly simple one) is used to select the server to use e.g. the main, test, pk etc string that is passed to the client. The client can then be launched by the wrapper script and its return status checked.

 

About shell() vs. exec(), the program terminates now (without -stay), so there is no need/possibility to check the return code of a crashing client and display error messages.

If you changed the current system() call to an exec() call, then your GUI program is replaced by the client program (the process remains the same). Then, when the process exits, it is the exit status of the client that is returned to the caller.

 

Edit: With all this talk of system() and exec() I forget this must run on platforms other than Unix! :P

Edited by bluap

Share this post


Link to post
Share on other sites
Edit: With all this talk of system() and exec() I forget this must run on platforms other than Unix! :D

 

Well, using dev-cpp or a mingcc cross compiler *should* make that possible :P

(hopefully for OSX too)

 

Piper

Share this post


Link to post
Share on other sites
*bump*

 

Has this been finished?

 

The zip file with the source code is still there and works fine under Linux, but no idea, if it compiles and works under other OS'es.

 

Piper

Share this post


Link to post
Share on other sites

Since Entropy originally requested this, do we know if it will be included in the next official client release?

 

And if yes, will it be the official way to start the client from that point forward (what everyone installing the game will see when they start "EL" by menu/shortcut/etc)?

Share this post


Link to post
Share on other sites

An idea from DHT:

 

PM from dht: something like "what about instead of server chooser GUI the el installed creates shortcuts for each server/

 

is this as doable as it sounds? Upon install, EL creates client shortcuts for both Main and PK servers.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×