Unified Setting Tool (based on Settings++)

koshi · Post by **koshi** » 04 Nov 2007, 21:51

Do you mean for menu items? Thats easily done.
Tabswitching, tabbing through controls I don't know.
Or do you mean something else?

Sidenote: fileroller can handle passworded files, or is that a matter of the underlying unrar. Iirc there is a free and an unfree tool. Can the unfree tool not handle passworded files? If that is so, must I reprimand myself for using the non-free one?

LordMatt · Post by **LordMatt** » 04 Nov 2007, 22:25

Agon wrote:BTW: Linux has rar support. You need to install unrar. If you use KDE with ark you only need to install unrar and you can extract all rar files which are not passworded with ark in a gui.

I think a tool aimed at linux users should work with the default archive manager package without having to install additional softwares.

Agon · Post by **Agon** » 04 Nov 2007, 23:13

LordMatt wrote:
Agon wrote:BTW: Linux has rar support. You need to install unrar. If you use KDE with ark you only need to install unrar and you can extract all rar files which are not passworded with ark in a gui.
I think a tool aimed at linux users should work with the default archive manager package without having to install additional softwares.

Yeah you are right. I prefer tar files ,too.

koshi · Post by **koshi** » 10 Nov 2007, 19:55

I want to add some descriptive text to some options, so I have some questions related to individual settings:

"never use shaders when rendering SM3 maps" and "catch AI exceptions":
i assume there is an underlying problem, what is it? should be default on or off?

"high-resolution LOS textures":
a typo? should it be LOD? otherwise, what are these?

"enable LuaShaders support":
what reason is there against those? what min. shadermodel is needed?

Tobi · Post by **Tobi** » 10 Nov 2007, 22:40

koshi wrote: "high-resolution LOS textures":
a typo? should it be LOD? otherwise, what are these?

No that's correct it means the coloring of the map when L is pressed is slightly higher resolution. This barely makes any difference in quality though, so I'd just strip the option from the UI.

theHive · Post by **theHive** » 11 Nov 2007, 02:04

Tobi wrote:No that's correct it means the coloring of the map when L is pressed is slightly higher resolution. This barely makes any difference in quality though, so I'd just strip the option from the UI.

It took me so long to find out about that settings' existence in the first place...

YokoZar · Post by **YokoZar** » 11 Nov 2007, 07:35

I've been debating whether or not I should actually package this, since it really should be a part of the lobby clients. How hard would it be to integrate this into SpringLobby?

Tobi · Post by **Tobi** » 11 Nov 2007, 10:52

Maybe make it a separate package and make the spring package suggest/recommend it?

koshi · Post by **koshi** » 11 Nov 2007, 11:24

It wouldn't be hard at all for SpringLobby to include it technically as it also is build on top of wxWidgets. I'd say less than 10 lines of code.
But since AFLobby probably would also like to able to call it I would prefer a seperate package and make it install to springs binary directory.
Better yet include it in the spring source itself and make it a seperate target once the building/dependencies issues are worked out.
The whole thing is a lot easier on windows, where it is no problem to produce a relatively small binary that has wxMSW statically linked. On linux I have to date successfully linked it statically to wxGTK, but I would also have to do that for the "real" GTK libs and that just seems wrong. I would even say that static linking (or shipping the dynamic libs) isn't the way to go on linux.
I'm willing to be convinced otherwise though, since I never distributed an app to a diverse lot of users.

Just to be sure: this app isn't ready for general distribution yet. (But I am aiming to a relatively complete feature set for next weekend)

-------

As to my earlier questions:
I'm going to drop the "high-resolution LOS textures" from the UI and default them to off? Or on (wasn't really clear what the default should be)?
The other three are still open.

Tobi · Post by **Tobi** » 11 Nov 2007, 12:03

default to off, it's just a waste of resources to have it on

I'll see if I can get around to updating the mingwlibs with wx etc sometime, didn't get around to that yet.

Agon · Post by **Agon** » 11 Nov 2007, 12:33

As I wrote I can make some rpm packages for the settings application in one hour depending on Spring and wxWidgets.
I think installing the settings application into /usr/bin with a desktop icon would be the best.
SpringLobby could search for the application in /usr/bin and could create a button for opening the application. AFLobby could do the same.

clericvash · Post by **clericvash** » 11 Nov 2007, 13:45

Could someone do a deb file for it?

YokoZar · Post by **YokoZar** » 11 Nov 2007, 23:31

koshi wrote:It wouldn't be hard at all for SpringLobby to include it technically as it also is build on top of wxWidgets. I'd say less than 10 lines of code.

Exactly. I guess this leaves us with an architectural decision: should springlobby launch the settings tool, or should the settings tool be internal code to SpringLobby (and then duplicated by AFLobby)?

But since AFLobby probably would also like to able to call it I would prefer a seperate package and make it install to springs binary directory.
Better yet include it in the spring source itself and make it a seperate target once the building/dependencies issues are worked out.
The whole thing is a lot easier on windows, where it is no problem to produce a relatively small binary that has wxMSW statically linked. On linux I have to date successfully linked it statically to wxGTK, but I would also have to do that for the "real" GTK libs and that just seems wrong. I would even say that static linking (or shipping the dynamic libs) isn't the way to go on linux.
I'm willing to be convinced otherwise though, since I never distributed an app to a diverse lot of users.

You don't need to ship a static lib at all; I'll be recompiling it anyway within the package. The package, in turn, will automagically depend on whatever shared libraries it uses (Ubuntu is really nice this way.)

Just to be sure: this app isn't ready for general distribution yet. (But I am aiming to a relatively complete feature set for next weekend)

As long as it's ready around 0.76 :D

AF · Post by AF » 12 Nov 2007, 01:51

AFLobby already has provisions for settings.exe and settings++. Go into aflobby settings and set the path and filename to the settings program and the splash screen spring settings button is enabled.

koshi · Post by **koshi** » 28 Nov 2007, 04:06

a quick heads up:
Development hasn't stopped, on the contrary: I've joined the springlobby team and been busy moving there.
UI refactor is almost complete, same goes for simple settings tab.
I moved to unitsync as backend for settings handling to remove direct dependency on spring source. Though some new issues arose (location of unitsync, etc.) once they are ironed out it will make things easier in the future.
It will take some time though to fully integrate the tool (buildprocess, git repository, etc.), but I'll try to get an intermediate build /source-package out by the end of the weekend.
Also, while settings++ will eventually be fully integrated into springlobby, standalone packages will then still be available.

AF · Post by AF » 28 Nov 2007, 19:34

So just to be clear, we'll still have a settings++.exe ?

It's just that dependency on spring lobby for the settings would be an unfair advantage that's completely unnecessary.

tombom · Post by **tombom** » 28 Nov 2007, 21:08

Also, while settings++ will eventually be fully integrated into springlobby, standalone packages will then still be available.

So I would guess so.

koshi · Post by **koshi** » 29 Nov 2007, 00:50

yeah I thought I was pretty clear on that.
But once more:
there will be standalone executables

koshi · Post by **koshi** » 01 Dec 2007, 20:00

i would like to know what the option FontCharLast (and maybe corresponding ones) really does (range of values, etc.) to possible include them in the gui

apparently changing the value solves problem with too small ingame fonts

for reference: http://spring.clan-sy.com/phpbb/viewtopic.php?t=11980

Spring RTS Engine

Unified Setting Tool (based on Settings++)