Suggestion: keep backwards compatibility
Moderator: Forum Moderators
Re: Suggestion: keep backwards compatibility
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.
- Elvish_Hunter
- Posts: 1576
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: Suggestion: keep backwards compatibility
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. 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:
.
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: 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:
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. 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:
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 codevultraz wrote:I think you're being too verbose with your labels.
![Wink ;)](./images/smilies/icon_wink.gif)
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: 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:
- 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.
- The only image format supported by Tkinter is GIF
. 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...
![Smile :)](./images/smilies/icon_smile.gif)
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.CIB wrote:I think maybe polishing up lua documentation, convenience functions and examples to see it used more would help.
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
Re: Suggestion: keep backwards compatibility
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?
SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?
Re: Suggestion: keep backwards compatibility
No, they don't. Python3 compatibility is a planned feature, but we don't have it yet.
- Wintermute
- Inactive Developer
- Posts: 840
- Joined: March 23rd, 2006, 10:28 pm
- Location: On IRC as "happygrue" at: #wesnoth-mp
Re: Suggestion: keep backwards compatibility
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."
Re: Suggestion: keep backwards compatibility
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![Razz :P](./images/smilies/icon_razz.gif)
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.
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
![Razz :P](./images/smilies/icon_razz.gif)
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.
- Elvish_Hunter
- Posts: 1576
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: Suggestion: keep backwards compatibility
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.AI wrote:No, they don't. Python3 compatibility is a planned feature, but we don't have it yet.
However, my GUI is able to run on both Python2 and Python3.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Thanks!Wintermute wrote:This is looking great, keep up the good work!
![Cool 8)](./images/smilies/icon_cool.gif)
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)