Skip to main content

Task2.begin() - Moving GUI to use U32Strings!

This week, I got started with my new task - Moving GUI to U32Strings. 
Before I tell more about it, some miscellaneous things that happened this week:

A team-member of ScummVM had previously worked on adding the achievements for some Wintermute games. He was very nice to offer me a game copy to test out the achievements for my task, but I had some steam credit so I thought there was finally a use for them! This way, I have bought my first ever steam game! I have run out of games - pre-2011 - that I can play on potato pc, so I never really bought anything from Steam. I have yet to try out the game, maybe sometime soon!

While cleaning up the history and adding more code, I came across a merge conflict. Previously, I would just find a way around them, but this time I tried to solve it following step-by-step. This way, I learned how to solve merge conflicts! It was quite simple (at least for my small changes), and not as complicated as I thought it would be. I will try to solve more small issues with merge conflicts now.

Another member of the community is testing out new things and making some improvement patches for my previous task - "RTL GUI". He has written very clean and minimal code compared to the original code for Editables (widgets to type in) and Tabs. It was also a very great improvement over my code. It was very interesting to see how much a specific piece of code could be improved.

The new task:

So, how did I get started with my new task? In my last task, there were visual changes and behaviors I needed to change, and everything was pretty visible from the get-go. In this task, not so much. So, I decided to start small. Every widget in ScummVM has "Name" and "Label", amongst other things.

Names are used internally, while labels are the text that widgets have attached which eventually get rendered. So, at the very base, I changed the label of ButtonWidgets from String to U32String. Apart from Labels, there are also many other things needed to be converted, but this seemed like a great place to start.

In ScummVM, there is a very neat little system and macros defined for translations. To use them in code, you would just do something like
_("Message")
and I get my translated piece of string (if any present) as type const char *. Because translations are used everywhere in the project, I can't just change the return type here, because that will break too many things at 1 time and become a pain to solve each one without seeing any progress. So, after changing the label for one specific widget, I simply followed errors and converted the strings to U32Strings on a temporary basis like:
..., convertToU32(_("Message")), ...

When all compilation errors got solved, I moved widget by widget. First, I covered all types of Buttons, then TextWidgets, Tabs, and so on.

To make them draw as U32String, I also changed the internal code to the appropriate type. At one further internal step, the drawing function only accepted Strings. So, there and many places, I used overloading to temporarily accept U32Strings as well as Strings - so all other unconverted widgets also draw properly.

After converting all widgets and using a bunch of temporary code, I gave my code a try. It worked near-perfectly for English but broke a lot of things in other languages, which was expected. Hebrew broke it nearly completely (as in the picture below).



On Friday evening, I sat down to finally change translations to return U32Strings, which would mean that they affected the whole project. Because I had converted most widgets to U32Strings, I thought it was time. I hit compile and there were ~650 errors and 50 warnings! After widgets, I focused on converting tooltips from const char* to U32String. In code, everywhere a tooltip was not to be used, we used nullptr to mark a tooltip as absent. So, that also had to be changed. The issue with tooltips and my old temporary code made up half of the errors. 

So, that day I spent clearing out all of them.

Firstly I decided to focus on the small issues with nullptr and my previous temp code. Finally, my shell-scripting classes came to see real use! I was a little rusty and unsure because I haven't really used it in a project of this big size. But after some careful commits and checking, I was able to wipe these errors (~350-400) in a short period of time with minimal other side-effects.

Afterward, I manually went through the remaining to solve them out one-by-one. I found a lot of missing places where drawable text could be made as U32Strings.
I succeeded in solving all of them, but there was a small problem with a formatting function, which caused runtime exceptions when I tried to change the languages. Below is the result, with most things working properly! Now it is not broken compared to the previous image, which is nice!


I'm thinking by next week, I will be polishing up this task! I'm happy that this task also has a good little progress.



Thanks for reading!

Comments

Popular posts from this blog

The (official) end of an amazing journey!

 Hello! GSoC has officially ended, and I'm in the final stage - submitting my work for the entire summer to Google! When I first received the acceptance letter in May, I was very much baffled. It was exciting and a bit scary at the same time, because I have never ever worked on a project of this scale. Well, first time for everything I guess :) So, what have I been doing this past week? Last week I left off saying my U32 PR was showing some activity, and this week, @criezy helped out a lot by reviewing my U32 PR, and providing much feedback. He also helped out pretty much entirely towards the MacOS/iOS platforms, because it was quite not an area (Objective-C) I was comfortable in. It was really a huge help. Apart from that, I mostly spent the entire week looking at the PR to see what could be changed, fixing my mistakes, and making the PR ready for merge. It has improved quite a lot!  Criezy pushed an update for iOS, which led me to believe that there might be many more missing are

My first week experience and my first task!

Hello, it's nice to talk to you again!   This is my first week after being accepted into ScummVM and I have a lot to talk about, so let's get started. A little sidenote - Originally, I thought to update my blog once every two weeks and that it would be a good idea, but I just really wanted to update you guys with my exciting first week!  I was reading my fellow GSoC student's introductory blog post when I realized that the introductory blog post is also meant to introduce a person, something I completely forgot in my first post. Yes, that's right, I forgot to introduce myself - in my introductory blog post. You read that right - but I hope that you didn't find it rude, I was just really excited to be a part of ScummVM for this summer, and somehow forgot what I was supposed to write! Let's do it right this time before we move on to my first week's experience! Introduction Hiya! I am Aryan Rawlani, a Computer Science student in Ahmedabad, India

ScummVM plugins - The new task

Hello! This week, I got started with my new task - "Moving detection features to the executable". What is the task? ScummVM has over 50 engines that support many - many games. Currently, when compiled - these engines can either be compiled directly inside the scummvm executable (statically linked) or packed inside small packages of external libraries that can be loaded on demand (dynamic linking) So, why would we even opt for external libraries? Wouldn't packing everything into the executable give the best performance? Well, yes. But the thing is, ScummVM has a lot of platforms it supports ( ScummVM Platforms ) over 30! It's very portable, which is one of the really amazing features of ScummVM. With dynamic plugins, the executable sizes are lowered. Because of this, when we need to detect games - each engine is loaded by one and the relevant detection happens. This is slow. The main purpose of this task is to move the detection related features to the executa