Big announcement ;)
MestreLion
Gathering all info from your last emails, I'm proud to announce:
- bugfix/es_AR_syntax is ready to merge.
A single-line fix, as you requested. The robust handling was transfered to public/improve_lang_handling
- public/improve_lang_handling is ready to merge.
All language-related changes prior to new i18n approach is there. There are MANY new and exciting stuff! The most proeminent one is using user's environment locale as default language
- public/linux_launcher is ready to merge
* improved launcher (both code and rename), symlink, chmod +x in non-executables
* dropped all changes to AUTHORS, as requested
* changes to README.txt were reduced to a minimum, no more "noisy" diff, as requested
- public/xdg_* were rebased and ready to merge.
* Have you decided about them yet?
These are all rebased onto your current master, and on top of each other, in that order. So if you can use a single Fast-Forward merge to integrate them all. Or merge just the ones you want, just do so in the provided order
And the most precious jewel of the crown....
- testing/i18n is ready for testing, based onto public/improve_lang_handling
You GOTTA see this one! It is amazing! Please take a look and test.. specially the new utils/gettext-singularity. I'm very excited about your feedback on this one...
Most commit messages are *very* comprehensive... that's why I didn't rebase them into 1-single-commit branches this time. They are a very detailed "manual" of the changes in each commit.
Enjoy!
ML
Phil Bordelon
> Hi Phil!
>
> Gathering all info from your last emails, I'm proud to announce:
>
> - bugfix/es_AR_syntax is ready to merge.
> A single-line fix, as you requested. The robust handling was transfered to
> public/improve_lang_handling
Merged.
> - public/improve_lang_handling is ready to merge.
> All language-related changes prior to new i18n approach is there. There are
> MANY new and exciting stuff! The most proeminent one is using user's
> environment locale as default language
Merged. This is a pretty big one, so testing will be necessary; if anyone's
up for that (I know more people than ML and I read this list :) feel free.
> - public/linux_launcher is ready to merge
> * improved launcher (both code and rename), symlink, chmod +x in non-executables
> * dropped all changes to AUTHORS, as requested
> * changes to README.txt were reduced to a minimum, no more "noisy" diff, as
> requested
Merged.
> - public/xdg_* were rebased and ready to merge.
> * Have you decided about them yet?
Not yet.
> These are all rebased onto your current master, and on top of each other, in
> that order. So if you can use a single Fast-Forward merge to integrate them
> all. Or merge just the ones you want, just do so in the provided order
>
> And the most precious jewel of the crown....
>
> - testing/i18n is ready for testing, based onto public/improve_lang_handling
>
> You GOTTA see this one! It is amazing! Please take a look and test..
> specially the new utils/gettext-singularity. I'm very excited about your
> feedback on this one...
>
> Most commit messages are *very* comprehensive... that's why I didn't rebase
> them into 1-single-commit branches this time. They are a very detailed
> "manual" of the changes in each commit.
I haven't looked at anything too deeply; turns out that a weekend where
family comes in from out-of-town is a bad one in terms of "sitting down at
the computer" time (but good otherwise). Hopefully I'll get some time this
week.
Thanks again for the solid work.
P
MestreLion
On Sunday, April 8, 2012 11:19:04 PM UTC-3, Phil Bordelon wrote:
I haven't looked at anything too deeply; turns out that a weekend where
family comes in from out-of-town is a bad one in terms of "sitting down at
the computer" time (but good otherwise). Hopefully I'll get some time this
week.
Options is partially i18n, all strings done but hotkeys are a mess. It required a complete revamp of my hotkey approach, now I'm ready to finish it along with all the other changes discussed in the other thread;
This is a good time to test that branch... next commit will be the last one before I completely rebase the branch and re-organize the commits, grouping them in logical blocks, and then renaming to public/i18n. It will be a "total makeover", so it's better to have all new code and input now before surgery :)
I know you guys have very little time to spend on E:S, but if you could at least *run* it just to see if there is some blatant atrocity that I missed, such feed would be great.
Also, take a look in public/setup and testing/restart.The former is ready to merge, the latter is definitely worth taking a look ;)
Thanks again for the solid work.
P
ML
Phil Bordelon
> I know you guys have very little time to spend on E:S, but if you could at
> least *run* it just to see if there is some blatant atrocity that I missed,
> such feed would be great.
I poked around at it. Ignoring the issues on the Options screen, things
seem fine. I dug around on the Knowledge screen, poked at some bases, etc.
and nothing seemed broken.
> Also, take a look in public/setup and testing/restart.The former is ready to
> merge, the latter is definitely worth taking a look ;)
public/setup should still work for Linux. You use it to install/build
packages/etc., not to actually run the application. You should drop the
Linux "don't bother running this" bit.
testing/restart has a single commit, which just adds the line g.restart().
I suspect there should be more there?
> It's been tons of fun working in this code. E:S is a delightful project :)
Glad to hear it!
P
MestreLion
On 04/11/2012 11:16 PM, MestreLion wrote:> I know you guys have very little time to spend on E:S, but if you could at
> least *run* it just to see if there is some blatant atrocity that I missed,
> such feed would be great.I poked around at it. Ignoring the issues on the Options screen, things
seem fine. I dug around on the Knowledge screen, poked at some bases, etc.
and nothing seemed broken.
> Also, take a look in public/setup and testing/restart.The former is ready to
> merge, the latter is definitely worth taking a look ;)public/setup should still work for Linux. You use it to install/build
packages/etc., not to actually run the application. You should drop the
Linux "don't bother running this" bit.
What should be the behavior in linux?
testing/restart has a single commit, which just adds the line g.restart().
I suspect there should be more there?
Phil Bordelon
> I just added that bit because that was previous behavior when accessing
> setup.py: it tried to import either py2exe or py2app, and, if both failed
> (and both fail in Linux), it exited with a nonsense message "py2exe or
> py2app must be installed"
>
> What should be the behavior in linux?
Eh, never mind. If it never worked in Linux, it's no big deal. I'd just
have it print "setup.py is not supported in Linux." and be done with it.
P
Phil Bordelon
> Yeah, my bad... somehow g.restart() function itself got lost in the reflog.
> I've published it now. It will restart E:S when you save settings. It does
> that in a clean, elegant, and (hopefully) cross-plataform way
This /is/ a simple, clean solution--something I never thought I'd say in
regards to execv()--but it is also a dataloss solution. If someone goes
into the option screen while playing a game and saves options without
having saved their game recently, they will lose progress, yes?
P
MestreLion
Some smart behavior could include:
- Autosave first (and adjust message accordinly, as in "(don't worry, you game will be automatically saved as xxx)"
- detect if user has already just saved the game
- auto-pop the save game dialog
- ... auto load after restart ;)
- refuse to restart without an updated save
etc etc...
many alternatives to prevent data loss. And all relatively easy to do. Which do you prefer?
Of course, ideally a restart would never be required, and all strings would be translated on-the-fly. This will require a MAJOR code revamp (no translatable strings in module globals or __init__()), but it was not forgotten yet ;)
Phil Bordelon
> Correct. And that's why this is still just a testing/ branch. The final
> version will show a dialog if user has changed current language. Something
> like "You have selected a different language, and this it requires a restart
> to fully apply. Do you want to restart now? (DON'T FORGET TO SAVE YOUR GAME
> BEFORE! [yes] [NO]"
>
> Some smart behavior could include:
> - Autosave first (and adjust message accordinly, as in "(don't worry, you
> game will be automatically saved as xxx)"
> - detect if user has already just saved the game
> - auto-pop the save game dialog
> - ... auto load after restart ;)
> - refuse to restart without an updated save
> etc etc...
>
> many alternatives to prevent data loss. And all relatively easy to do. Which
> do you prefer?
I'll have to think on this. Probably just doing an autosave.
> Of course, ideally a restart would never be required, and all strings would
> be translated on-the-fly. This will require a MAJOR code revamp (no
> translatable strings in module globals or __init__()), but it was not
> forgotten yet ;)
This is not the first time I've seriously thought about rewriting E:S from
the ground up. In fact... see my follow-up eMail.
P
MestreLion
And the most precious jewel of the crown....
- testing/i18n is ready for testing, based onto public/improve_lang_handling
You GOTTA see this one! It is amazing! Please take a look and test.. specially the new utils/gettext-singularity. I'm very excited about your feedback on this one...
Most commit messages are *very* comprehensive... that's why I didn't rebase them into 1-single-commit branches this time. They are a very detailed "manual" of the changes in each commit.
Enjoy!
ML
3 weeks later, I proudly announce that testing/i18n branch is finally ready for... well, testing :)
All code-related work is done. E:S is now fully internationalized, all strings are translatable.
My work now will be to polish this 18-commit monster branch down to 4~5 commits, rebase on top of latest changes, adjust readme, changelog, etc, and then rename to a ready-to-merge public/i18n branch.
But please, I beg you guys, don't wait for the rebase to test it. The "raw material" is all there, the code in polished version will be the same. To give you an idea how deep and wide these changes are, here are some interesting statistics:
27 files changed, 3585 insertions(+), 833 deletions(-)
Yes, 4418 lines changed. And even if we don't consider the new files (1686+545+561+122), we are still talking about 1500+ lines. And that's /not/ considering neither datadir bugfix nor the new options screen (~200 lines)
This makes public/improved_lang_handling, a branch that Phil said "This is a pretty big one, so testing will be necessary", blush in comparison:
16 files changed, 273 insertions(+), 328 deletions(-)
If that is not enough:
$ wc -l code/*.py code/screens/*.py | tail -n1
5759 total
So 1/4 of code and screens was re-written. (graphics was barely touched). Hence I urge you all to test this branch. And do it using pt_BR (no point in testing an i18n branch in default language). And I hope this time not only Phil.
As for the read ahead, I will now work on:
- revamping the options screen
- do the changes in launcher/setup
- continue my fun with my classdiagram toy branch :)
Good testing! :)
ML