Suggestion: keep backwards compatibility

Discussion among members of the development team.

Moderators: Forum Moderators, Developers

Re: Suggestion: keep backwards compatibility

Postby CIB » April 19th, 2014, 12:43 pm

I think maybe polishing up lua documentation, convenience functions and examples to see it used more would help. I've been maintaining a (rather complex) campaign that's written entirely in lua where possible for over a year now, and in that whole year I had to do only one update to maintain compatibility(and yes, I'm updating from git regularly). I think a big reason for that is because I don't even touch on the WML stuff that's related to scripting, nor any macros. And once someone uses an "official" lua function, it is pretty trivial to keep that lua function backward compatible.
CIB
Code Contributor
 
Posts: 625
Joined: November 24th, 2006, 11:26 pm

Re: Suggestion: keep backwards compatibility

Postby Elvish_Hunter » April 25th, 2014, 9:10 am

New post for the usual WeeklyUpdate™ on the GUI project.
After discussing it with zookeeper on IRC, I added two more tabs to the main window: one allows running wmlscope, and the other allows running wmlindent.
wmlscope tab.png
Please do note that the Run button changes its label (and its callback, obviously) each time that you select a different tab. That indirectly answers to vultraz's suggestion:
vultraz wrote:I think you're being too verbose with your labels.
Personally, I prefer the labels to be a bit more verbose; however, this may be changed later, especially if I find some good code example to implement tooltips. Modifying a label is a matter of editing just one line of code ;) .
Another thing that I added is a right-click menu. Unlike other toolkits, where text-related widgets have a context menu, Tk requires you to define your own.
So, I created a context menu and attached it to every Entry widget by subclassing them:
wmlindent tab.png
You may notice that there are a few icons on the left side of the menu. These icons are taken from the Tango icon set, and are released in the Public Domain (they're even reposted at OpenClipArt). Before that I go further with my experiment, there are a few question:
  1. Am I allowed to use some of these icons in a mainline tool? Of course, I'll add a note to the credits of the script.
  2. The only image format supported by Tkinter is GIF :augh: . To be honest, Python 3.4.0 is compiled against Tcl/Tk 8.6.0, and as such supports PNG images as well. But it's unlikely that the 2.7.x series will be patched to support it. So, if I want to include a few icons, I must use the GIF format.
    However, we won't have GIF files floating around, because (as suggested in some tutorials) I plan to encode them in base64 and inject them directly in the source code. Am I allowed to use the GIF format (that, by the way, is supported by the SDL library as well) and then encode it? The only other way to load images will be to use the Python Imaging Library, but adding an external dependency will make things pointlessly complicated for the final users...
Apart from these issues, the tool is almost finished, and after some more testing and fixing on my own I'll push it in the data/tools directory. :)
CIB wrote:I think maybe polishing up lua documentation, convenience functions and examples to see it used more would help.
Sure. But there's also the fact that at least some UMC authors are not interested in learning a second language... However, I agree with you on that point: I remember that, when I was learning it, I had a really hard time grasping the concept of WML tables.
Current maintainer of The Sojournings of Grog, Children of Dragons, A Rough Life and Wesnoth Lua Pack
Co-author of The White Troll
On Wesbreak until the 21th of December
User avatar
Elvish_Hunter
Developer
 
Posts: 1359
Joined: September 4th, 2009, 2:39 pm
Location: Lintanir Forest...

Re: Suggestion: keep backwards compatibility

Postby vultraz » April 25th, 2014, 9:27 am

Why do you need to use Python 2.7? IIRC wmltools work with Python 3.x as well.
Creator of Shadows of Deception (for 1.12) and co-creator of the Era of Chaos (for 1.12/1.13).
SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?
User avatar
vultraz
Community Manager
 
Posts: 824
Joined: February 7th, 2011, 12:51 pm
Location: Dodging Daleks

Re: Suggestion: keep backwards compatibility

Postby AI » April 25th, 2014, 12:01 pm

No, they don't. Python3 compatibility is a planned feature, but we don't have it yet.
AI
Developer
 
Posts: 2394
Joined: January 31st, 2008, 8:38 pm

Re: Suggestion: keep backwards compatibility

Postby Wintermute » April 25th, 2014, 5:02 pm

This is looking great, keep up the good work!
"I just started playing this game a few days ago, and I already see some balance issues."
User avatar
Wintermute
Developer
 
Posts: 840
Joined: March 23rd, 2006, 10:28 pm
Location: On IRC as "happygrue" at: #wesnoth-mp

Re: Suggestion: keep backwards compatibility

Postby Coffee » April 28th, 2014, 9:48 am

Just want to chime in my opinion on another way to accomplish the same thing.

Perhaps a compatibility layer could be considered (potentially a future GSoC project or something) that would allow for everything to work exactly as it worked in 1.12,1.10, 1.8, etc.? You could specifically set the version of wesnoth the addon is playable against and the compatibility layer would load WML, etc. exactly to match.

I am thinking you might be able to specify differences between WML in different wesnoth versions and the preprocessor would load the macros from the layer if there are differences between versions.

Then each time there is a difference between new versions and before you would just write the difference into the compatibility layer and specify how it differed between the 2 versions. A sort of version control system.

I am of course in no way volunteering to make such a compatibility layer :P

Otherwise, I think we have to be very specific about our goals for backwards compatibility, as things do change between releases. If the goal is to get UMC addons working faster between versions this should be reflected in how it is done. If the goal is to stop good addons from dropping off due to not being ported I think we need to first make sure this is actually happening, and not just the author leaving and wouldn't port it over even if backwards compatibility was not affected.
User avatar
Coffee
Developer
 
Posts: 170
Joined: October 12th, 2010, 8:24 pm

Re: Suggestion: keep backwards compatibility

Postby Elvish_Hunter » May 5th, 2014, 4:10 pm

AI wrote:No, they don't. Python3 compatibility is a planned feature, but we don't have it yet.
Out of curiosity, I attempted running the 2to3 script supplied with Python3. Surprise: it seems like there is only a little work needed to make wmllint and the other tools compatible with Python3 - mainly it's about converting the print statement to calls of print() function. While we're at it, we can also convert the C-like string interpolation to Python's string.format() method. I guess that I'll create a branch and see how things go from there.
However, my GUI is able to run on both Python2 and Python3. :D
Wintermute wrote:This is looking great, keep up the good work!
Thanks! 8) I just pushed it in mainline and opened a development topic here: viewtopic.php?f=10&t=40397 . I also removed the old Wx-based GUI, as it is surpassed and never really worked.
Current maintainer of The Sojournings of Grog, Children of Dragons, A Rough Life and Wesnoth Lua Pack
Co-author of The White Troll
On Wesbreak until the 21th of December
User avatar
Elvish_Hunter
Developer
 
Posts: 1359
Joined: September 4th, 2009, 2:39 pm
Location: Lintanir Forest...

Previous

Return to Developers’ Discussions

Who is online

Users browsing this forum: No registered users and 1 guest