Contribute to Open Source. Search issue labels to find the right project for you!

Displaying Course Info in Search Results


There is a lot of information per course to display. Specifically, all generic information, all sections for that course plus their associated info, and all sections of labs/discussions. The sections + labs are especially troublesome since there are so many, but we should still be able to view them concurrently to the schedule we have built. Solution: Each course in the results has a “see full detail in new tab” button. Clicking this creates and opens a new tab within the search results, similar to the already planned “currently selected courses” tab. The tab contains the full information for the course, all its sections, and all its labs/discussions. Each course in the search results will also indicate if none of the sections fit in your schedule, before opening the new tab.

Updated 22/03/2018 23:14

get rid of landing page?


make it like reddit where you just see things immediately?

or if landing page there should be an option to immediately go to content “explore” button or something like that

Updated 22/03/2018 21:10

Landing Page Picture


Picture was originally in <body> tag, which is incompatible with the way html extension works in django (as far as I am aware). I have instead put it in the topmost level of the jumbotron, but it does not fill the whole screen.

Updated 22/03/2018 20:35

highlighting of crates in track context menu


When looking into I noticed that hovered crates in the track context menu do not have the normal background color style applied. I fixed that, however I have not found any way to set the background style for the selected crate when navigating the menu via keyboard. See the comment in the code for details.

Updated 22/03/2018 21:30 1 Comments



What I want to solve?

I want to implement a common unit for sizes for all components to avoid having components with styles like padding={2.5} or padding={4.5}. We need some pattern for sizes, otherwise developers will use random sizes.


Components should accept sizes. If the component role is very well defined, it can accept a single size. Multiple sizes are allowed too.

<VerticalSpacing size={2} /> // Single size

<View marginSize={2} paddingSize={1} /> // Multiple sizes

The size to pixel ratio is always 5px. Sizes should be a whole number, so 0.5 is not allowed.

0 = 0px
1 = 5px
2 = 10px
3 = 15px
4 = 20px
5 = 25px
6 = 30px
7 = 35px
8 = 40px

For most apps 8 is enough, but you could use, say, 20, it’s not an issue.

Alternative Approach

We could use a naming scheme like xs, sm, md, lg, xl. The problem is that it’s not very flexible, and we’ll end up having components with sizes like xxs or xxxl.

Implementation Draft

import { Block } from "jsxstyle"
import React from "react"

const sizedProps = ["marginSize", "paddingSize"]

const sizeToPixelRatio = 5

const View = props => (
    {...Object.keys(props).reduce((result, propName) => {
      const propValue = props[propName]

      if (sizedProps.indexOf(propName) > -1) {
        if (propValue % 1 !== 0)
          throw new Error(`"${propName}": "${propValue}" is not a whole number`)
        return {
          [propName.replace("Size", "")]: propValue * sizeToPixelRatio

      return {
        [propName]: propValue
    }, {})}

export default View
Updated 22/03/2018 16:58

Mechanism to inform UI of map interaction


At the moment the UI relies on input names to determine its behavior. If an input’s name matches some pattern, then clicking on the map will feed into the form. This will break if a process requires more than one map input.

  • We should think of a generic mechanism to tell the UI an input field should be fed with a map interaction (e.g. application/xml+gml mimetype).
  • Review the UI (for example right click to feed info to process, with a menu listing options in case process requires more than one map input).
Updated 22/03/2018 14:10

Implement Font Styleguide


Updated 22/03/2018 15:13

Part of User Filter section is blocked by keyboard


Steps to reproduce

  1. Try to add a rule to User Filter using a web report tool
  2. Sometimes the on-screen keyboard will block a part of User Filter screen, preventing it from adjusting its position on the screen.

Expected behavior

OSK shouldn’t block User Filter window

Actual behavior

OSK blocks user filter window

<details><summary>Screenshot and screen recording:</summary>

Available under 1799999.


Customer ID


Your environment

  • Device model and storage size: iPhone 5S
  • Operating system and version: iOS 11
  • Browser: n/a
  • Wi-fi or mobile internet connection: both
Updated 22/03/2018 10:11 1 Comments

Replace all instances of naked vgettext() calls with VGETTEXT()



This breaks the string freeze in one specific case, and it also seems it cannot be cleanly merged into master at this point, so I will need to provide a version specifically for master separately later. This is intended to be merged into 1.14 first, although I’ll probably do so myself after review from others.

The vgettext() function, while declared in src/formula/string_utils.hpp, actually has its implementation out-of-line in src/formula/string_utils.cpp where GETTEXT_TEXTDOMAIN is defined to "wesnoth-lib". Because vgettext() is implemented in terms of the _() function (an inline wrapper around translation::dsgettext()), it passes the textdomain defined in the file where it was implemented as a parameter.

This means that every case of vgettext() being used in other code units where GETTEXT_TEXTDOMAIN is not defined to "wesnoth-lib", is broken if the string being looked upon doesn’t coincidentally exist in the wesnoth-lib textdomain.

Ages ago, to work around this limitation, an overload of vgettext() that takes the textdomain name as a parameter was introduced (see commit 0ba3d05204abff72f7d95cf11a91536dab5aa20a). Since this form of vgettext() is rather unwieldy to use (and in particular, the xgettext message extraction tool mistakes the first argument for the msgid, see below), a VGETTEXT() macro was also added that uses the GETTEXT_TEXTDOMAIN symbol defined in the file where the call is made, and thus we get the correct string from the correct textdomain instead of the English original.

Switching all cases of naked vgettext() in mainline to VGETTEXT() fixes a myriad of situations where an interpolated string that has an extant translation does not actually get translated in practice because of the mismatched textdomain reference (see issue #2709 for an example with MP game titles). I couldn’t find any cases of the companion vngettext() function (which handles plurals) being used in the wild naked, but for future reference it also has a companion VNGETTEXT() macro to pass the correct textdomain to its textdomain-parameter overload.

One caveat is that this commit does break the string freeze in one particular casesrc/units/unit.cpp has a case where the textdomain-parameter version of naked vgettext() was in use with "wesnoth" as the first parameter, and xgettext misidentified this as a translation entry for a "wesnoth" string in the file’s assigned textdomain (which is the default textdomain, wesnoth). So this will result in the next pot-update both removing the spurious "wesnoth" string and adding the correct string to the relevant catalogue template ("<span color=\"$color\">$number_or_percent</span> HP") to that textdomain.

Other than that, I believe this does not break the string freeze in any other fashion and it shouldn’t result in any regressions for i18n.

It might be worth considering in the future renaming vgettext() and vngettext() to names that make people less likely to misidentify them as functions they can freely call directly without regard to the textdomain assignment issue.

Updated 22/03/2018 19:41 3 Comments

User config and data migration across branches


One common complaint about Wesnoth’s development approach is that players are expected to lose all their user configuration and data (add-ons, saves) when upgrading from one stable branch to the next one, or migrate them by hand and brace for the issues that can result from:

  • Trying to run Wesnoth with preferences from an older version (which usually works just fine, but issue #2612 is an example of how this can go wrong due to oversights)
  • Using obsolete add-ons (which usually have been updated to the newer stable branch, but the player has to go to the Add-ons Manager to reinstall them by hand or upgrade them at once if they copied over their data/add-ons dir themselves)
  • Loading older saves (start-of-scenario saves usually work just fine, but this is not always the case if the attached WML in units has changed in the meantime, e.g. abilities and other data that isn’t defined/overridden by the engine)

Even though it’s easy to shrug it off and just decide that the clean-slate approach for new stable branches is part of the project’s development philosophy somehow, once Wesnoth is released on Steam we can expect more vocal members of the audience (e.g. game reviewers) to complain rather loudly once the 1.16 stable series lands and people suddenly have lost all their gameplay progress and profile configuration from 1.14 unless they go out of their way to read instructions on a wiki/forum post and do file management operations to get their stuff back – or just give up, depending on the case.

So, in my opinion, going forward, some form of automated or semi-automated migration task will be necessary to avoid this issue from cropping up every time and demotivating players who’ve spent countless hours playing the game to get 100% SP campaign completion or what have you.

A potential implementation for this would be as follows:

  • On first start-up, if Wesnoth detects its user config and data dir are both empty or non-existent (obvious sign of the first launch of the new branch), it should look for the dir(s) for the previous stable branch and offer the user the option to migrate their profile from the previous version. If the user declines, then the game continues with a clean slate like it currently does.
  • If the user opts to migrate their profile, then saves, preferences, and credentials are copied (or moved?) over to the new version’s profile. The game should then gather a list of add-ons installed on the old version (currently this is a trivial directory enumerate operation), connect to the add-ons server, and see which add-ons are available for the new version and offer automatically downloading them.
  • Before finishing and loading the preferences file, the game should perform any syntax/structure changes that may be required on the new profile’s copy of it. If for some reason the process fails, inform the user accordingly and just proceed with fresh preferences (but this should never happen).
  • Saves are trickier because they can involve syntax changes that are defined by the engine (e.g. the structure of replays, how units are stored in the gamestate snapshot, etc.) and changes that are defined by Lua/WML. Some API for applying transforms to save files á la wmllint would need to be built into the engine, and those transforms would be applied when loading tainted saves according to the version of the game that generated them. The catch here is that this means that developers can no longer break WML/Lua API compatibility willy-nilly and a more formal transition process would be required for every API break.

This is an issue that at least concerns Windows (which uses a combined user config+data dir with a version identifier in its name for each branch) and Linux (which uses the version identifier for the user data dir by default but not for the cache and config dirs). I do not know anything about how Wesnoth manages user resources on macOS to suggest how the migration would work on that platform. Builds using a custom user config+data dir path (e.g. using SCons prefsdir option) can probably just have the migration code disabled by default since in that particular case the assumption ought to be that the user knows what they’re doing – unless there’s some Linux distribution making use of said option for stock packages for some weird reason.

Updated 22/03/2018 19:44 7 Comments

i18n: Unlocalized strings in the MP game setup UI


There are strings in the MP UI that despite having non-fuzzied translations in the wesnoth and wesnoth-lib textdomains for the Spanish locale, display in the UI unlocalized:


In particular, these strings:

Textdomain wesnoth * $login|’s game (the default value for a game title) * There are no custom options available for the selected era, game, or modification. * Independent, No Mirror, No Ally Mirror (options for the Random Faction Matchups combobox, whose label is in a different textdomain and also unlocalized – see below) * Search (the placeholder text for the map/scenario filter box) * Connected Players (heading for the player list sidebar during game sides setup)

Textdomain wesnoth-lib * Random Faction Matchups:

Unknown textdomain or missing strings * this game (default chat room when creating a game) * lobby (default chat room when joining the server)

Updated 22/03/2018 17:03 6 Comments

Add New Rule buttons could be better aligned


Type: code issue

Operating system: Windows 7 Home Premium Service Pack 1 Browser and version: Chrome 67.0.3377.0 canary

Steps to reproduce:

  1. Click on the HTTPS Everywhere icon in the toolbar.
  2. Click “Add a rule for this site”.
  3. Look at the buttons.

Expected behavior: Buttons are horizontally aligned and spaced reasonably apart.

Actual behavior: Buttons are smashed together, as well as to the “Show advanced” link.

Updated 22/03/2018 06:42

Custom rules show up as stable rules in the extension popup


Type: feature request


Operating system: Windows 7 Home Premium Service Pack 1 Browser and version: Chrome 67.0.3377.0 canary

Steps to reproduce:

  1. With HTTPS Everywhere enabled, open
  2. Click on the HTTPS Everywhere icon in the Chrome toolbar.
  3. Click “Add a rule for this site”.
  4. Click the “Add a new rule for this site” button.
  5. Reload the page.
  6. Click on the HTTPS Everywhere icon in the Chrome toolbar.

Expected behavior: The new custom rule shows under “Custom rules”.

Actual behavior: The new custom rule shows under “Stable rules”.

Updated 22/03/2018 06:43

highlight required form fields & validate forms onClick


Currently there’s no way to distinguish between an optional or a required field. Adding some kind of visual difference will help users fill out forms and correct mistakes.

Also in most* cases, I don’t think buttons need to be disabled until all inputs are filled and valid. Instead ‘submit’ buttons at the end of a form should validate the inputs onClick, then highlight any skipped or invalid inputs. This provides the same level of validation, but makes it easier to correct mistakes when submitting forms.

Updated 22/03/2018 15:40 2 Comments

lua errors during initialisation do not show in chat


this is aproblem since the user will then not know that hje is playing with a probably corrupted gamestate.

The reason for this behviour is quite simple, the lua initilisation code is run before the display object is created, so will do nothing.

Updated 22/03/2018 03:41

Fork me on GitHub