NxWidgets --------- NxWM ---- (4) General Issues (3) NxConsole Issues (1) CHexCalculator Issues (1) Platform specific Issues See also the NuttX TODO list graphics/ section for related issues. o General NxWM Issues ------------------- Title: DISPLAY INTIALIZATION Description: During the initialization of the display, the basic frame of the start window is draw momentarily. The is just the empty window frame. This is a consequence of how NX creates windows: The are enabled all of the time so the windows are visible when they are being created. The solution would be to add some disable logic in NX so that that nothing gets displayed when a window is created until it is fully initialized and enable. Status: Open Priority: Medium Title: DRAGGING ACROSS WINDOWS Description: Need some indication if the touch/mouse drags from one window to another then is release. Release event is lost in this case. Status: Open Priority: Low. ICON just stays selected and must be touched again. Title: AUTO-RAISE DISABLED Description: Auto-raise is currently disabled in nuttx for NX multi-server mode. The reason is complex: - Most touchscreen controls send touch data a high rates - In multi-server mode, touch events get queued in a message queue. - The logic that receives the messages performs the auto-raise. But it can do stupid things after the first auto-raise as it opperates on the stale data in the message queue. I am thinking that auto-raise ought to be removed from NuttX and moved out into a graphics layer (like NxWM) that knows more about the appropriate context to do the autoraise. Status: Open Priority: Medium low Title: THREAD SAFETY Description: I am not sure how thread-safe the NxWidgets are. There is is very little mutli-thread in the widgets now. The "NX listener" thread interacts to update mouse (and keyboard) data but all of the heavy work is done on the "start window" thread. I think everything is okay now, but it may be necessary in the future to introduce some semaphore protection in theCWidgetControl methods to make them thread safe. Status: Open Priority: Low Title: COMBINE CTouchscreen AND CKeyboard THREADS Description: Right now, two separate threads handle touchscreen and keyboard/ console input. Each just waits on read() and when toushcscreen or keyboard input is received, it injects the data into NX. These two threads should be combined into one thread that waits on poll for read data from either device. Then when read data becomes ready for either device, it could perform the read and data inject from a single thread. Status: Open Priority: Low, this is not a product but a text example. If NxWM were to be productized, this change should be done in order to reduce stack memory consumption. o NxConsole Issues ---------------- Title: MULTIPLE COPIES OF AN NxCONSOLE Description: From the start window, you an create multiple copies of the NxConsole. However, there is a problem in the current implementation: Each NxConsole receives its input from the serial console so, for example, it you enter text one character will go to one NxConsole instance and the next character goes to a different instance. That is correct behavior within the current design, but not very usable. We need a mechanism to assure that the top window is the one that receives all eyboard input. NX already provides this capability with its nx_kbdin interface(), but that is not currently used. At present, NxConsoles get their input from /dev/console which is the serial port. The necessary change is to create an NX input device for /dev/console that will get its input from NX. Status: Closed with was fixed with the check-in of 5/20/2012 (about SVN version 4755). The fixed version is available in SVN but won't be in a released version until NxWidgets-1.2 is released. Priority: Medium high, basically prohibits the use of multiple NSH windows. Title: CLOSING AN NxCONSOLE Description: If you open multiple NxConsole applications, they all receive serial input (as noted in the previous bug). However, if you close one of the NxConsoles, then the others no longer received input (or no long generate output -- that cannot be distinguished). Status: Closed with was fixed with the check-in of 5/20/2012 (about SVN version 4755). The fixed version is available in SVN but won't be in a released version until NxWidgets-1.2 is released. Priority: Medium high, basically prohibits the use of multiple NSH windows. Title: DOUBLE DISPLAY UPDATES Description: When the NxConsole window is first opened, there are usually double updates, i.e., the display forms twice. Status: Open Priorioty: Low, this would be necessary to fix to productize the windows. o CHexCalculator Issues --------------------- Title: NEW DATA ENTRY IS APPENDED TO PREVIOUS RESULT Description: For example 1+2= and 3 is shown. But if you enter 4, then 34 is shown. You have to manually clear the calculator ("C") before entering the next number. Status: Open Priority: Low, this is only a demo. This would, of course, have to be fixed if you wanted a production quality calculator (but then you would probably also want to add quite a few more features as well). o Platform specific Issues ------------------------ Title: MISSING TOUCH RELEASE Description: Using the STM3240G-EVAL board with the STMPE11 touchscreen, you will find that there are occasional missing indications of when you release a icon. This is believed to be a data overrun in the STPMPE11 data path. The STMPE11 generates data a very high rate and it is believe that it sometimes misses the interrupt that indicates that the touch is released. The symptom in NxWM is that you touch an icon, it is highlighted but when you release the touch nothing happens. The icon stays highlighted. Touching the icon again usually works around this problem. Status: Closed with was fixed with the check-in of 5/21/2012 (about SVN version 4758). The was change made to NuttX, not NxWidgets. The fixed version is available in SVN but won't be in a released version until NuttX-6.198 is released. Priorioty: Low, but really annoying. Title: BUGS WHEN CANNOT READ FROM LCD Description: There is a kludge in there to handle the case where we cannot read the background data because the LCD does not support read operations. You cannot read from the STM3240G-EVAL LCD right now (it might be possible, but I have not figured out how yet). In that case, we just use the default background color. However, that doesn't work either for the case where the background color changes when the widget is selected. Then the background color in the font is wrong. There is a hack in in CButtonArrary that fixed this problem, but the problem certainly exists in other places as well and begs for a better solution. Status: Open Priority: Medium-Low