2de19911f1
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4755 42af7a65-404d-4744-a932-0658087f49c3
111 lines
5.5 KiB
Plaintext
111 lines
5.5 KiB
Plaintext
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
|