You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
110 lines
5.5 KiB
110 lines
5.5 KiB
NxWidgets |
|
--------- |
|
|
|
NxWM |
|
---- |
|
|
|
(3) General issues |
|
(3) NxConsole issues |
|
(1) Platform specific 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 |
|
|
|
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 last check of 5/20/2012 (about |
|
SVN version 4754). 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 last check of 5/20/2012 (about |
|
SVN version 4754). 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 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: Open
|
|
|