Openarena Name Changer??

[swaggerall]

dbx the screenshot on your site says "OA" and "CFG" in the corners but the download doesnt have "OA" and "CFG" in the corner


and   these 2 buttons do what exactly?

[Gig]

Okay.. with the first checks:

- In the "Gnu modified lgpl" readme, carriage returns are not shown correctly (they are shown as white squares instead of going to new line). As usual, I'm testing under Windows only.
- In "Readme", a couple of missing spaces before "(", after "Windows" and "Linux" words.
- In the "Quick help" readme, in the "Save select" section, there is an extra space before a comma, and where you say <<only the 'Selected config file' mod will be shown>>, I suggest to change to <<only the mod containing the 'OpenArena Configuration File' set in 'Options' window (usually 'baseoa') will be shown>> or similar.
- In the "Quick help", in the "Other" section, there is a missing space in <<visible(on some platforms)>>
- In the "Quick help", I suggest to mention that, even if you don't "save" the currently typed name to OpenArena, it will be saved in OANC settings at program close, and will automatically be loaded when launching the tool again. One can quickly load the name stored in the main OA configuration file simply using the "Quick load OA" button on the upper right corner.
--Hey, I see in the "Others" section, that says <<The program will load your last used player name from the OA config file, if it can. If not it loads from it's own configuration file.>>. As I just told, it loads from its own file instead (and I think it's the right behavior)... so maybe is this line outdated?
- The "You need to select some mods to be able to load them into favorites" error even if you have selected some mods but not the first one of the list (bug), is still there! Changelog says you fixed a similar problem during saving, but previously I mentioned this one with loading... (at that time, I mentioned that maybe there could be a similar one with saving, but did not test it).
- Maybe it would be "safer" to make the "save mods" window start with all mods de-selected, instead of all of them selected (considering that, unlike using the "Save all" button, there is no confimation request here!).
- What about changing the "Save Mods" button text to "Save to Mods"? Maybe also "Save All" may be labelled "Save to All" or "Save to all mods"...
- The two "Save" buttons inside the "Save to Mods" are a bit confusing this way... what about naming them to "Save to all checked mods" and "Save to highlighted mod only"? (Italic is used just for explaining here). Similar terms could be used also in "load names" window buttons (also in that window, one button works with the checked lines and one with the hightlighted line).
- Another bug: the "name source" field in "save to mods" and "load names" windows sometimes appear with a name already in, before you select any line. I'm unsure from where that text comes from, but probably after you save/load one (it is not shown when you go to that window just after launching the program) it remains stored in the variable until you select another one, even if you close and open the load/save window again: probably the variable is not initalized each time you load that window.
- In the "configuration" window, to be clearer, the button "set to default configuration file" should be nearer to the text field that contains the path than the "save configuration to same directory as OANC" checkbox (that is a different thing and should be a little more separate from them). I really suggest this.
-- Still in the configuration window, but only if you have some more spare time, you could also do a cool thing: next to that checkbox, placing a read-only text field that shows you what will be the actual path of the OANC config file (that changes if you check or uncheck the box).
- The "quick load" text may be placed a litte nearer to the "OA" and "CFG" buttons. Wait... if you espressly placed it at that distance to preserve compatibility with systems with different fonts, leave it there (I see in your screenshot here that in your system it looks better than in mine with windows XP).

I understand you don't plan further development, but I hope you may make a 1.4.1 version with these small fixes.

PS: To swaggerall... please check you are using v 1.4.0. I have those buttons (that load the name from your baseoa folder or from OANC config file to the main window).

PPS: to everyone... Please do your own tests, also under Linux, and submit bugs if you find them.... finding all (or most) of them now, we will not need to disturb dbX in future too much.

[dbX]

Okay.. with the first checks:

- In the "Gnu modified lgpl" readme, carriage returns are not shown correctly (they are shown as white squares instead of going to new line). As usual, I'm testing under Windows only.
- In "Readme", a couple of missing spaces before "(", after "Windows" and "Linux" words.
- In the "Quick help" readme, in the "Save select" section, there is an extra space before a comma, and where you say <<only the 'Selected config file' mod will be shown>>, I suggest to change to <<only the mod containing the 'OpenArena Configuration File' set in 'Options' window (usually 'baseoa') will be shown>> or similar.
- In the "Quick help", in the "Other" section, there is a missing space in <<visible(on some platforms)>>
- In the "Quick help", I suggest to mention that, even if you don't "save" the currently typed name to OpenArena, it will be saved in OANC settings at program close, and will automatically be loaded when launching the tool again.
--Hey, I see in the "Others" section, that says <<The program will load your last used player name from the OA config file, if it can. If not it loads from it's own configuration file.>>. As I just told, it loads from its own file instead (and I think it's the right behavior)... so maybe is this line outdated?
- The "You need to select some mods to be able to load them into favorites" error even if you have selected some mods but not the first one of the list (bug), is still there!
- Maybe it would be "safer" to make the "save mods" window start with all mods de-selected, instead of all of them selected (considering that, unlike using the "Save all" button, there is no confimation request here!).
- What about changing the "Save Mods" button text to "Save to Mods"?
- The two "Save" buttons inside the "Save to Mods" are a bit confusing this way... what about naming them to "Save to all checked mods" and "Save to highlighted mod only"? (Italic is used just for explaining here)
- Another bug: the "name source" field in "save to mods" and "load names" windows sometimes appear with a name already in, before you select any line. I'm unsure from where that text comes from, but probably after you save/load one (it is not shown when you go to that window just after launching the program) it remains stored in the variable until you select another one, even if you close and open the load/save window again: probably the variable is not initalized each time you load that window.

I understand you don't plan further development, but I hope you may make a 1.4.1 version with these small fixes.

I'll try to implement these changes once I get back home, these should not take a lot of time. I might continue development on the program, I just don't plan on doing much in the near future.

[Gig]

Who knows, maybe near Christmas you may have more vacations and you may want to put in more features... I just thought to a science-fiction-like OANC 2.0 (or 3.0) feature: a system to associate names with key bindings (and remove them) in configuration files (bind <key> "name <name>", from the OANC GUI, e.g. one key for each favorite), that would allow users to switch between their names on-the-fly, directly from the game. That would be a great feature from the user's point of view, but a pain from the developer's point of view (since one should check carefully to do not overwrite existing bindings -unless they already contain a "name", "set name", "seta name" command-, that would be possible, and managing mods correctly, that would be a lot harder; maybe one could limit this feature to the main configuration file only...).

Well, this is simply a futuristic idea (who knows, maybe you may like it). For now, having the fixes mentioned in the previous post would be great.

[dbX]

- In the "Gnu modified lgpl" readme, carriage returns are not shown correctly (they are shown as white squares instead of going to new line). As usual, I'm testing under Windows only.

One of the things I hate about the Windows operating system, is how little effort is put into the base applications such as Notepad. Even after all these years, Notepad has practically not received much improvement. It still does not support Unix style line endings, and probably will not in Windows 8. Sure you can replace notepad with many other text editors, but most users wont, so I need to check line endings every time I modify a file on Linux so it's readable under Windows. I do not know why they're showed as squares. With notepad it does not show anything, it just makes one big line, which is also bad.

[dbX]

Who knows, maybe near Christmas you may have more vacations and you may want to put in more features... I just thought to a science-fiction-like OANC 2.0 (or 3.0) feature: a system to associate names with key bindings (and remove them) in configuration files (bind <key> "name <name>", from the OANC GUI, e.g. one key for each favorite), that would allow users to switch between their names on-the-fly, directly from the game. That would be a great feature from the user's point of view, but a pain from the developer's point of view (since one should check carefully to do not overwrite existing bindings -unless they already contain a "name" command-, that would be possible, and managing mods correctly, that would be a lot harder; maybe one could limit this feature to the main configuration file only...).

Well, this is simply a futuristic idea (who knows, maybe you may like it). For now, having the fixes mentioned in the previous post would be great.

I'm not sure how hard this would be to do, and it's unlikely I'll ever implement this. I like powerful tools, but this might be a bit over the top.

[Gig]

- In the "Gnu modified lgpl" readme, carriage returns are not shown correctly (they are shown as white squares instead of going to new line). As usual, I'm testing under Windows only.

One of the things I hate about the Windows operating system, is how little effort is put into the base applications such as Notepad. Even after all these years, Notepad has practically not received much improvement. It still does not support Unix style line endings, and probably will not in Windows 8. Sure you can replace notepad with many other text editors, but most users wont, so I need to check line endings every time I modify a file on Linux so it's readable under Windows. I do not know why they're showed as squares. With notepad it does not show anything, it just makes one big line, which is also bad.

I don't know which API your program uses to show text files, but it has got the same (silly) limitation as notepad: I noticed the problem (that is not new for notepad... somewhere in the Wiki I think I have suggested to edit q3config.cfg using Notepad++) opening it from the "help" menu of OANC.

[dbX]

I don't know which API your program uses to show text files, but it has got the same (silly) limitation as notepad: I noticed the problem (that is not new for notepad... somewhere in the Wiki I think I have suggested to edit q3config.cfg using Notepad++) opening it from the "help" menu of OANC.

Well, crap. I guess it's Lazarus
I'll see if I can change that. While I'm already at this, I might also fix the limitation for paths which contain special characters, I guess this will make for better user experience.

[Gig]

Well, if the problem is only a single text file, it would be quicker to fix that file (a thing that I suggest anyway, so if a user opens it with the classic notepad instead of from the help menu, it will work correctly anyway).
If you think there is a way to fix the special characters limit, and it is easy enough and without negative effects, you can try it. Personally, I don't have special characters in my path and I don't even know what kind of error messages the program shows in that case... can you tell me some specific special characters (but that Windows filesystem accepts) that should cause the program get in trouble, to make a test?

[dbX]

If you think there is a way to fix the special characters limit, and it is easy enough and without negative effects, you can try it. Personally, I don't have special characters in my path and I don't even know what kind of error messages the program shows in that case... can you tell me some specific special characters that should made the program get in trouble, to make a test?

There is a way, it should be relatively easy. Try any non-US, country specific characters (in my case čćžšđ). The program finds those paths unreadable. I need to use UTF8 when handling such paths. I need to test this anyway so you need not worry. However, a test after I implement this would be great.

[dbX]

I've completed the new 1.5.0 version. It can be downloaded from rapidshare or my crappy site (good luck getting that to work). I'm looking into new hosting and a new domain, so if anyone has suggestions on a good hosting company (I'm looking primarily into paid hosting, because free ones usually don't cut it with ads, limits ...), let me know.

In this version I've implemented most of the fixes Gig suggested, and the program can now work on systems with language specific characters in the file paths. Also some slight modifications to UI so text fits on all platforms I tested. Fedora 15 with Gnome 3.0 has a huge font. I'm satisfied with the program and I think it's well-rounded. If anyone encounters any additional bugs let me know, I'll fix them eventually.

[Gig]

Wow, you have been extremely fast! I haven't had the time to come back home and write this message before you uploaded a new version!

What I wanted to write to you is this one more suggestion... Call me paranoid if you think...
OANC saves q3config.cfg files, before changing them, copying them to q3config.cfg.bak. Well, adding a .bak extension is quite a common pratic when one wants to keep a copy of a file before making some changes, that usually is done manually. The point is: what does it happen if someone creates a .bak to keep a copy of his config for any other reason, and later uses OANC? That his manual backup will be overwritten by OANC. The solution? I suggest to add a different extension instead of .bak, something that people would not use by their own (.oanc, .oancbk, .oancbck, .ncbck, for example).

Well, if you decide to make this change, remember to check all the four save kinds (save to default config, save to all, save to checked mods, save to highlighted mod), and then to update the help, too...
 

[dbX]

Wow, you have been extremely fast! I haven't had the time to come back home and write this message before you uploaded a new version!

What I wanted to write to you is this one more suggestion... Call me paranoid if you think...
OANC saves q3config.cfg files, before changing them, copying them to q3config.cfg.bak. Well, adding a .bak extension is quite a common pratic when one wants to keep a copy of a file before making some changes, that usually is done manually. The point is: what does it happen if someone creates a .bak to keep a copy of his config for any other reason, and later uses OANC? That his manual backup will be overwritten by OANC. The solution? I suggest to add a different extension instead of .bak, something that people would not use by their own (.oanc, .oancbk, .oancbck, .ncbck, for example).

Well, if you decide to make this change, remember to check all the four save kinds (save to default config, save to all, save to checked mods, save to highlighted mod), and then to update the help, too...
 

It's not a problem. Only a single change needs to be made since all four save kinds use the same end routine to save the file. I'll make a 1.5.1 tomorrow, since today I'm not going to be home.

[Gig]

I was about asking to you to add a message, when you enable or disable the "Save configuration to same directory as OANC", to warn the user that the change will be effective after program restart, and that the existing configuration file will not be automatically copied from a location to the other -correct, but better to say it- (tested with OANC 1.4.0)....

And while doing such tests, I noticed a strange thing... where does OANC 1.5.0 store its configuration file, when "Save configuration to same directory as OANC" is NOT checked? The program is working (I can store and recall favorites after program closure), but is using with a different configuration file, that I don't find! The file in my %appdata%\.oanc folder is not being modified anymore...

PS: What about mentioning in the "quick help" that the user should have read/write permissions for the OANC installation folder?

PPS: No time for this, uh?

-- Still in the configuration window, but only if you have some more spare time, you could also do a cool thing: next to that checkbox, placing a read-only text field that shows you what will be the actual path of the OANC config file (that changes if you check or uncheck the box).

[dbX]

I was about asking to you to add a message, when you enable or disable the "Save configuration to same directory as OANC", to warn the user that the change will be effective after program restart, and that the existing configuration file will not be automatically copied from a location to the other (tested with OANC 1.4.0)....

And while doing such tests, I noticed a strange thing... where does OANC 1.5.0 store its configuration file, when "Save configuration to same directory as OANC" is NOT checked? The program is working (I can store and recall favorites after program closure), but is using with a new configuration file, that I don't find! The file in my %appdata%\.oanc folder is not being modified anymore...

PS: What about mentioning in the "quick help" that the user should have read/write permissions for the OANC installation folder?

The program no longer stores in %appdata%, I use the integrated Lazarus functionality, to make it work with different systems (since before I manually figured out for each platform where to store the configuration file). This way Lazarus does it for me, but it stores in a different path. It's no longer in roaming (AppData) but in local (LocalSettings\AppData\.oanc).

I could make the program store the settings to the local configuration file if the "Save configuration to same directory as OANC" option is checked. This way it will "copy" the settings. I guess I could add a message, but I don't expect this feature to be used much considering the program should now have no problems accessing paths with language specific characters.

I'll make a note in the quick help.

[Cacatoes]

In case you need:

http://openarena.tuxfamily.org/upload/

I'll upload/move your release to right FTP directory when you are done with developments

[Gig]

Uh... I don't like "local", I prefer the "%appdata%" one (that can be easily accessed using that "shortcut")... but if you say that it is better for other reasons (like code cleanup and, more important, O.S. compatibility)....
Side note: changelog should have told about this 1.5.0 change.

But in this case, considering that the path is different than the one used by OpenArena, I suggest again to show the saving path in the configuration window (in a read-only text field), if possible.


About automatically copying the configuration file from installation folder to user data folder and vice versa, maybe it is not worth of implementation. What would happen in a multi-user environment? What do you think about it? I fear if the "A" user checks the checkbox, its personal config would overwrite the "shared" one in OANC folder; and then if the "B" user unchecks the checkbox, the shared configuration (that would contain "A"'s favorites) would overwrite B's personal config...
I suppose a message that informs that the change will be applied after program restart, and that configuration data will not be automatically copied should be enough... what's your opinion?

[Gig]

Another thing...
I renamed the OANC folder, including non-US letters, and then enabled the "Save configuration to same directory as OANC": 1.5.0 did the same thing as 1.4.0 did... it does not say any error message, but does not create the configuration file there, and the next time you open it, you find the checkbox unchecked.

It seems there is still some problem with special characters, man... also that license information file is still shown without correct line endings...


PS: A very, very insignificant change, but, since we are here... I suppose you may change the "Current name in selected mod" text to "Current name in highlighted mod", and the "select all/select none" buttons to "check all/check none". In the same way, "No mods are selected" in save to mods may say "No mods are checked", and "you need to select some mods to be able to load them into favorites" in load names may say "check" instead of "select". Do you like it? Is "Check none" correct in English?

PPS: I just noticed that "Configuration" window is sizeable, but lower limits are too small, and enlarging it is useless, at the moment, since it does not expand the "path" field. Hey, about sizeable windows, maybe also the loading and saving windows could be sizeable (like main and favorites are, not allowing to set smaller than default size -I just checked that everything fits correctly also in a relatively "small" 800x600 screen-), if you wish...

PPPS: About "Favorites" window, what about some option to sort or change the order of lines the list?

PPPPS: In main window it is possible to create your name just using the mouse... but what about a sort of "backspace" button to be able to make corrections without switching from the mouse to the keyboard?

PPPPPS: In quick help, in "other" section, you talk about configuration files backups. I suppose it would be better to specify that you are talking about OpenArena configuration files, and not about OANC configuration files.

PPPPPPS: Maybe the "Save configuration to same directory as OANC" text would be clearer if saying "Save OANC configuration to its own directory", "... to its installation directory", "... to its executable directory" or similar (to explain that, unlike the two options above it, this option is not referring to OA configuration).

[sago007]

also that license information file is still shown without correct line endings...

Have you tried viewing it in wordpad?

Correct line endings are a relative term. At work I sit with text editors that does not support CRs.

[Gig]

also that license information file is still shown without correct line endings...

Have you tried viewing it in wordpad?

Correct line endings are a relative term. At work I sit with text editors that does not support CRs.

There is an "help" section inside the program itself that shows the content of the help and license files, directly inside the program. And it does not work correctly, just like the classic notepad. In theory, 1.5.0 should have fixed this (together with the special characters in paths problem), but someting seem to have went wrong, as both problems are still there...

[Cacatoes]

@Sago
"Correct line ending" is not that much a relative term, it just means: there is no crap displayed at the end of line, and, the end of the line is taken into account. You probably meant something like "there is no implementation more correct than the other, they only follow their own standards"
And I don't know what to think of a text editor which doesn't allow you to handle both of them.

@Gig
I'd tend to prefer the "more semantical" description than the more "visual" one. Good software is one which is both meaningful when used (GUI) while exposing its mechanism when needed (source code). For instance, representation of "selection" (which is something semantic) may change according to toolkits.

[Gig]

@Gig
I'd tend to prefer the "more semantical" description than the more "visual" one. Good software is one which is both meaningful when used (GUI) while exposing its mechanism when needed (source code). For instance, representation of "selection" (which is something semantic) may change according to toolkits.

This sounds correct and seems a good general approach... but how to best apply it to this case? In this parcular case, we have a single window with two "save" buttons... one of them works with the "n" elements of the list that have their checkbox enabled, and the other works with only the hightlighted element (without considering its checkbox state, and it not possible to hightlight multiple elements). They are two different kinds of "selections" in this window... any suggestions about how to semantically separe them, to be clear for both final users and developers?
Note: My suggestion of replacing the -in this particular case- ambiguous "selected" term with "checked" and "hightlighted" in the remaining strings related to that window was intended for making the final user's experience even easier, but it could also be leaved as it is now. Now it's not bad, I only said that it could be even clearer.

[swaggerall]

i just donwloaded the name changer gig o.O of course its up to date


i still dont have the buttons

oh and btw dbx i found an error




using a certain symbol AS THE FIRST in a name when its saved as a favorite it skips it and that symbols isnt there such as this



<SYMBOL>swaggerall

<---before saved



after closing program and opening it


swaggerall

the symbol doesnt save it gets skipped


ONLY IN FAVORITES

[Cacatoes]

@Gig
It could be necessary to rethink the whole GUI and I'm just too lazy to do that :p
I see there are several similar windows (each with their own "preview+source-nick" fields), many save and load options and ways to interact from different places/files, that's what confuses me the most (while I'm familiar enough with OA to understand the logic). I would have stick with a more simple "first window", like, favs are meant to be handy, they're probably not meant to be managed/added directly from the first window. Kinda the same with all the save options for "mods". Favorites could be managed directly from the list, instead of the tickable box column it could recognize which of these names are already in favorites or not and you would just have to de/select them in one click, that would also avoid the "add to favs" button. In general, I would try to avoid repetition. I didn't get yet what "Quick load from CFG" does, I suppose the tool has its own entry for a nick, this may not be necessary to save it if you already have stored name in favorites (as they are both meant as a "call back from an easy place").
I wouldn't have forbid moving the "centered window" either, his responsibility to move and not to lose it I even thought I had a problem with my window decorator or graphic driver ! (it already happened)

[dbX]

i still dont have the buttons

What buttons?

I wouldn't have forbid moving the "centered window" either, his responsibility to move and not to lose it I even thought I had a problem with my window decorator or graphic driver ! (it already happened)

It's not that I forbid it, I just don't save it (though I thought I did). Every program has to save windows size/position itself.