Hello! Welcome back to my weekly status report. I want to finally start writing the reports on Fridays, so it hasn’t been that many days since the last report, and there was a holiday in the middle of this week and some craziness you may already be aware of, so this report may end up either shorter than usual, or at least different. Sorry about that!
I started the week by looking back at older “known issues”. I fixed the context menus of the start menu, which hadn’t been functional for a long while, and I refreshed my memory on a few others, although no fixes came out of that. One of the things I had in my list, was that quite a lot of menu items and toolbar buttons aren’t implemented, or at least aren’t doing anything when you click on them.
One of those is the start menu “Help and Support” button. In Windows, this button opens the support program, which has help topics, troubleshooting, and support links. Since we don’t have such a program in ReactOS, I decided to implement the button as a ShellExecute action. I wrote the code so that it should be extremely easy to change the behaviour in the future, or even make it configurable from the registry.
I looked at the Settings menu, and traced the issue to our ShellExecute function, which doesn’t know how to handle “special paths” using GUID identifiers instead of standard filenames. Those identifiers are needed to open special folders such as My Computer, or Control Panel.
Another item in the start menu that did nothing useful was the Search submenu. In fact, this menu wasn’t even implemented, showing only an empty popup with a separator. Because implementing the Search system is outside the current scope of the branch, I decided to hide the menu item completely, instead of adding dummy buttons.
I wanted to fix the redraw issues in the taskbar, but to this day, I still have no idea why those issues happen, since running the same exact code in Windows works just fine. The issues have to be either in the comctl32 code, or in win32k itself. The latter seems plausible since the issues also happen in the notification area of the tray, which does not use comctl32 at all.
I took this chance to sync the branch with the latest changes from trunk, after which I compiled a new set of builds.
The next day was a holiday, so I spent it with my family, away from my computer. In the evening, after returning from eating too much and spending too many hours in the swimming pool, I made the decision to take a step back, and compile a proper list of bugs and missing features, most of which are already known but not gathered in one place.
The next morning, I started putting together a rough list of issues, categorizing them between bugs and missing features. Later I decided that, because you need more than one set of eyes to see the whole picture, it would be best to let the community give their feedback on the builds. I set up a new document in a collaborative notepad service, based on the EtherPad code, and told about it around.
Amine saw me mention this, and suggested I should make it more formal, so that the community gives us feedback to how far the shell is from being worthy of being in trunk. To make this decision, the first step is to gather a more complete list of issues, including anything people may miss from the old explorer. You are still on time to test, just head to this page https://www.reactos.org/forum/viewtopic.php?f=2&t=13447 and read the text carefully.
In a few days (possibly Monday), I’ll triage and categorize all the issues and missing features, creating a document explaining the origin of each bug or missing feature, the components that need to be fixed/improved, and how much effort I believe would be involved (although this would be a rough estimate, since anything can surprise us).
Finally, once we know how much effort is required for each issue (and which issues are just simply out of the scope of my job and need some other developer to fix them), I’ll start a poll of sorts, where the community can rate how “blocking” the issue is (for example: from 0 “no problem if it doesn’t make it in” to 5 “the branch can’t be merged unless this works perfectly”). Based on this feedback, we’ll be able to decide if the branch is already ready to be merged, and if it isn’t, how much effort will be needed before it is.
After I set up the forum post, and made the collaborative pad contents more “formal”, I went back to the unimplemented buttons and menus.
In the file browser toolbar, the buttons can be subdivided into 4 groups:
- The navigation buttons, with history back/forward and “up”,
- The sidebar buttons, with “folders” and “search”,
- The file operations, with “copy to”, “move to”, “delete” and “undo”, and lastly
- The view mode, which shows a dropdown to select the listview style.
Sporadic bugs aside, the items in the first group are all functional. The second group needs support for sidebars, which is completely missing, and so it doesn’t have an easy fix. The fourth group works in windows, but appears to fail in ReactOS, and I will have to revisit it later. The one I focused on was the third group.
The third group contains buttons that relate to the selected items, and have equivalent actions to menu items. These buttons are usually implemented by using the same “command IDs” as the menus, allowing the code to handle them indifferently. Tracing the creation of the toolbar buttons confirmed that this was the case, so the items not working has to be a problem with the shell view object, which is the one that handles the menu commands related to the folder and its contents.
Running the filebrowser program in Windows Server 2003, confirmed that using the windows shell32 classes, those buttons work just fine, indicating that the missing code is indeed in our shell32 implementation.
By this point, some people had begun to notice the forum post and some of them were already writing in the collaborative pad. I took some time to sort out some of the entries, and fix up some grammar and typos. Unfortunately, overnight, someone thought they were funny and decided to translate the contents of the pad to Russian, which meant I had to revert to a previous saved version, and let others write again the few changes that hadn’t been saved.
One of the issues people wrote on the pad, that surprised me, was that the menus in Windows can be navigated by leaving the mouse button down, and moving to the item, then releasing the mouse on the item you want to activate. This method of using the menus was new to me, so I had never thought of implementing it in my shell menu classes. The logic for this turned out to be more complex than I initially thought, so it’s not quite working yet, but it’s high up on my list of WIP fixes.
Do you remember I mentioned spending a lot of time swimming? Well it may or may not be related, but by this point I had a sore throat and a bit of a headache, so my productivity suddenly went down. I slept badly that night, and when I woke up the next day my body confirmed me it was a cold.
It doesn’t help that when I woke up the pad had been vandalized again, and I had to restore another saved version. It was then that I noticed the undo buttons in the EtherPad, which appear to be able to revert the content back to the beginning. In the future fixing vandalism should be much simpler.
I spent most of the afternoon answering to replies in the forum and looking at the issues in the TODO list, trying to explain some of them.
I still have a runny nose, but the headache has subsided somewhat. The annoyance seems to have moved down to my stomach, though, so I hope to fully recover over the weekend.
Finally, the obligatory screenshot.
If you install wine-gecko during the second stage setup, or manually afterwards, or you install a proper browser that registers itself to handle URLs, and you click on the start menu “Help and Support” item, you should get a window with the contents of the ReactOS home page, like this: