24 Dec 2014

49621

0

Decorating the shell tree

Hello everyone,

Because Christmas was so close to the weekend, I decided to delay the report a few days, and release it on time for the holidays, and this way include in the report everything that has happened over the weekend and the beginning of this week.

The past week began by reviewing some patches that were pending for a LONG time. Sadly, most of them were too bit-rotten to be applicable as-is, so I had to contact the patches’ authors and request an update. Annoyingly, the whole process took a much longer time than it would seem from this explanation. Fortunately, some of the patches DID apply, such as the fix for the small icons in the shell.

After that, I turned my eyes on a problem with the start menu, where the shell menus wouldn’t properly close when clicking on windows not belonging to the taskbar. This issue took quite a lot of time to get right, due to the complexity of the shell menu hierarchy, but I believe that the improvements I made to the focus manager component will improve the stability and behaviour of the shell menus overall. The way the code worked before, was that it attempted to set a capture on the active menu window, and it would remove that capture and apply a new capture when the mouse moved from one menu to another. On top of that, it wouldn’t always set the initial capture correctly, so the result was that the capture didn’t always detect when the mouse was being clicked outside the menus. With the help of Giannis, we decided to follow Windows’ behaviour, and only set the capture on the initial shell menu, and never move it to any child menus. This works because the focus manager takes care of hot-tracking the menu items, instead of making use of the toolbar’s own code for it.

After fixing that, and while I was already looking at the start menus, I looked at the keyboard navigation, which I hadn’t tested in a long time. It turns out, it was already working quite well, but only as long as the start menu was open by clicking, and not with the windows key. In the latter case, the keyboard focus would remain on the parent, so the parent would receive the keyboard notifications instead of the start menu.

To fix this, we wanted to investigate which method Windows used, but after some time trying to find the right method, I decided to just put it in the focus manager, so that when the first menu is open, the parent of that menu is activated, and when the last menu closes, the previously foreground window is restored. Although the code is not the best, it will do for now.

I ended the week by going through some small issues. Among these, was the initialization of netshell’s notification icon manager class. This class implements all the interfaces and protocols used by Shell Service Objects, but for some reason it’s initialized through stobject.dll instead of being registered in the SSO key in the registry. To fix that, I could have gone in one of two directions. Either I made netshell register itself as an SSO, or I followed Windows’ choice and initialized it through stobject. I couldn’t see any reason not to do the former, but in the end I decided to follow Windows and do it from netshell. We don’t have any reason to do so, but if we ever decided to place netshell.dll or stobject.dll from windows in ReactOS, it may be best this way.

Over the weekend, I rested mostly, but then I picked up the “small issues” task on Monday, by going through the list of issues in JIRA, and triaging. A few were already fixed, others needed more information, and some others were ready to fix.

I don’t know if I will be able to fix anything else this afternoon before all the guests get home for Christmas eve, but for now, this is all.

Merry Christmas to everyone, and see you all later after the holidays (possibly next year ;P).

Discussion: https://reactos.org/forum/viewtopic.php?f=2&t=13881

This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.