357e4b55dd
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4763 42af7a65-404d-4744-a932-0658087f49c3
145 lines
7.5 KiB
Plaintext
145 lines
7.5 KiB
Plaintext
NxWidgets
|
|
---------
|
|
|
|
NxWM
|
|
----
|
|
|
|
(4) General issues
|
|
(3) NxConsole 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 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
|