For the most part of this week I was exploring new ideas, exploring Wt’s capabilities, debugging some annoying bugs, and designing algorithms for some objectives.
First, let me start with the interface bug.
Slow connection rendering bug
When the interface was changed to the current one, a weird bug occurred on slow connections where the two widgets (the code editor and the schematic editor) overlaps. However, whenever the browser size changes (hence, Wt will calculate new dimensions for the widgets) it returns normal again. This problem only occurred on slow Internet connection (so it has something to do with timing). Investigating such a problem is quite difficult, as it is hard to see which line (or lines) of code are responsible for this. I had to come up with theories and then test these theories until one proves right. And that’s what happened.
I tried commenting out some of the third party libraries (so the rest would finish loading faster), then tried to delay the creation of the widgets, but with no luck. After many experiments, I found out that the stretch factor we are using for the schematic editor when added to an WHBoxLayout might be the problem as when it’s removed, the problem would not occur. Theoretically, this should not be a problem, as we are using it exactly the way it should be used, and we get the correct (expected) output on normal connection. However, the moment the connections slows down, everything falls apart. I am not sure if it is a bug with our code, or Wt’s, and may be that’s why it is recommend in Wt documentation itself ti use CSS if possible (which absolutely possible in our case), but removing that stretch factor fixed the problem.
Some changes needed to be done after that to keep the interface as it is. Then, finally, the problem was fixed.
Cookies for storing session id
I was also asked to see if Wt can use cookies to store the session-id instead of using the URL. It appears that Wt has this option (sort of!), however, there are two catches. First, only one session can be opened on the browser, and second, it will be a security concern. That’s why Wt’s documentation also recommends against using cookies for session tracking.
To enable this “feature”, the property in Wt’s configuration file needs to be changes from URL, to Auto. Now when a new session is created, a cookie will be created that stores that session ID. When another session is created, this cookie will be overwritten. Wt doesn’t have an API to manually set the session-id to a specific value. The only function there is, is changeSessionId() which changes the session id to a new randomly generated string.
The board internal components
We were asked to create Verilog modules, classes, and JointJS elements for the internal components of the board, namely the SD card, Ethernet, and the analog to digital converter (the PIC18 analog port). There are a lot of questions here that needs to be answered in order to handle these internal components properly.
Questions such as how is the UCF file generated? Does each component has its own UCF file or there is one that defines all the ports once? Do these components need JointJS elements? How can two modules share the same connections (i.e. Ethernet and ADC sharing the UART)? Won’t that create a conflict? Will the user define “objects” in his code for these components? Then what will happen if the user defines two Ethernet objects for example? Or is it better to have the user use functions for these components such as the Arduino instead of defining objects?
Well, this topic is a bit complex as it involves many aspects, and it introduces many new considerations. Hence, most of the above questions haven’t been answered yet. Hopefully, next week you can read the answers for all these questions.
So that’s it for the week. Till next time.
0 Comments