Prep for 6.18 release
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4751 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
parent
e40d54e2f7
commit
9083c67595
@ -2,7 +2,7 @@
|
||||
|
||||
* The initial release of the NxWidgets package
|
||||
|
||||
1.1 2012-xx-xx Gregory Nutt <gnutt@nuttx.org>
|
||||
1.1 2012-05-19 Gregory Nutt <gnutt@nuttx.org>
|
||||
|
||||
* Updated and verified the NxWidgets DOxygen documentation. Contributed
|
||||
by Jose Pablo Carballo.
|
||||
@ -93,14 +93,14 @@
|
||||
* NXWidgets::CNxTkWindow: Reported size of a framed window must exclude the
|
||||
height of the tool bar (if present)
|
||||
* TODO.txt: Add a file to keep track of issues.
|
||||
* NXWidgets::CStartWindow and IApplicationFactory: This is a substantial
|
||||
* NxWM::CStartWindow and IApplicationFactory: This is a substantial
|
||||
redesign. IApplication wraps an application. However, if we want to
|
||||
be able to start multiple copies of an application, then we need to
|
||||
be able to create multiple IApplication instances from the start window.
|
||||
Enter IApplicationFactory. Icons in the start window now correspond
|
||||
to application factories; icons in the task bar no correspond to
|
||||
application instances.
|
||||
* NXWidgetes::CStartWindow and CWindowControl: The above change necessitated
|
||||
* NxWM::CStartWindow and CWindowControl: The above change necessitated
|
||||
another architectural change: When create applications, it is sometimes
|
||||
necessary to wait for windows events. The above change moved the
|
||||
application creation to the window event thread, hence, causing deadlocks
|
||||
@ -109,3 +109,5 @@
|
||||
asynchronously and can wait for windoew events.
|
||||
* doc/NxWM-ThreadingModel.ppt: Documented the now rather complex NxWM
|
||||
threading model.
|
||||
|
||||
1.2 2012-xx-xx Gregory Nutt <gnutt@nuttx.org>
|
||||
|
@ -74,7 +74,7 @@ nxwm
|
||||
small display.
|
||||
|
||||
The window manager consists of a task bar with icons representing the
|
||||
running tasks. If you touch the tas'ks icon, it comes to the top. Each
|
||||
running tasks. If you touch the task's icon, it comes to the top. Each
|
||||
window has a toolbar with (1) a title, (2) a minimize button, and (3) a
|
||||
stop application button using the standard icons for these things.
|
||||
|
||||
|
@ -1,9 +1,69 @@
|
||||
NxWidgets-1.0
|
||||
=============
|
||||
|
||||
The initial version of NxWidgets was released on March 22, 2012. This
|
||||
package has been used in several projects prior to its release to open
|
||||
source and is considered stable its initial release (although not all
|
||||
features have been fully verified).
|
||||
|
||||
|
||||
NxWidgets-1.0
|
||||
=============
|
||||
|
||||
The initial version of NxWidgets was released on March 22, 2012. This
|
||||
package has been used in several projects prior to its release to open
|
||||
source and is considered stable its initial release (although not all
|
||||
features have been fully verified).
|
||||
|
||||
NxWidgets-1.1
|
||||
=============
|
||||
|
||||
The 2nd release of the NxWidgets package as made on May 19, 2012. The
|
||||
headline new feature in this release is:
|
||||
|
||||
* NxWM, the tiny window manager based on NX and NxWidgets. NxWM is true
|
||||
multiple window manager but only one window is displayed at a time.
|
||||
This simplification helps performance on LCD based products (in the
|
||||
same way that a tiled window manager helps) and also makes the best
|
||||
use of small displays. It is awkward from a human factors point-of-view
|
||||
trying to manage multiple windows on a small display.
|
||||
|
||||
The window manager consists of a task bar with icons representing the
|
||||
running tasks. If you touch the task's icon, it comes to the top. Each
|
||||
window has a toolbar with (1) a title, (2) a minimize button, and (3) a
|
||||
stop application button using the standard icons for these things. User
|
||||
input via a touchscreen or mouse and keyboard is supported.
|
||||
|
||||
There is always a start window that is available in the task bar. When
|
||||
you touch the start window icon, it brings up the start window containing
|
||||
icons representing all of the available applications. If you touch an
|
||||
icon in the start window, it will be started and added to the task bar.
|
||||
|
||||
There is a base class that defines an add-on application and an
|
||||
interface that supports incorporation of new application. The only
|
||||
application that is provided is NxConsole. This is an NSH session
|
||||
running in a window. You should be able to select the NX icon in the start
|
||||
menu and create as many NSH sessions in windows as you want. (keybard input
|
||||
still comes through serial).
|
||||
|
||||
This initial realease of NxWM should be considered an alpha release.
|
||||
All know issues are listed in the top-level TODO list.
|
||||
|
||||
Other important new features include:
|
||||
|
||||
* NxWidgets::IBitmap and NxWidgets::CRlePalettBitmap: Extended to
|
||||
support different color look-up-tables (LUTs). This allows images
|
||||
to be highlighted when touched, for example.
|
||||
* NxWidgets::CImage: Extended to support button-like behavior. CImage
|
||||
widgets now work well as touchable icons.
|
||||
* NxWidgets::CWidgetControl: Add a semaphore to force clients to wait if the
|
||||
size or position of the window is not yet known (multi-user mode only).
|
||||
Enabled and verified creation of framed windows.
|
||||
* NxWidgets::CWindowEventHandler and NxWidgets::CWindowEventHandler: Add
|
||||
support for getting callbacks for window events.
|
||||
* DOxygen documentation support. Contributed by Jose Pablo Carballo.
|
||||
|
||||
An effort is underway to simplify NxWidgets and reduce its memory footprint:
|
||||
|
||||
* NxWidgets::CNxWidget: Removed support for "shelving" widgets, reference
|
||||
constants, and close types. Remove all support for widgets in a "vertical"
|
||||
hierarchy. Now widgets exist in a flat, two-dimensional space and should
|
||||
not overlap. Removed built-in modal loops.
|
||||
|
||||
Bug fixes include changes to the following (see the ChangeLog for details):
|
||||
|
||||
* NxWidgets::CRlePalettBitmap, NxWidgets::CRlePalettBitmap,
|
||||
NxWidgets::CGraphicsPort, NxWidgets::CWidgetControl
|
||||
|
||||
|
||||
|
65
TODO.txt
65
TODO.txt
@ -4,6 +4,24 @@ 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.
|
||||
@ -26,6 +44,20 @@ NxWM
|
||||
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
|
||||
@ -41,5 +73,34 @@ NxWM
|
||||
port. The necessary change is to create an NX input device for
|
||||
/dev/console that will get its input from NX.
|
||||
Status: Open
|
||||
Priority: Medium High
|
||||
|
||||
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: Open
|
||||
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
|
||||
|
@ -120,8 +120,8 @@ namespace NxWM
|
||||
* widget constructor
|
||||
*
|
||||
* NOTE: Actually, NxWM uses the CWindowMessenger class that inherits from
|
||||
* CWidgetControl. That class just adds some unrelated messenging capability;
|
||||
* It cohabitates with CWidgetControl only becuase it nees the CWidgetControl
|
||||
* CWidgetControl. That class just adds some unrelated messaging capability;
|
||||
* It cohabitates with CWidgetControl only becuase it needs the CWidgetControl
|
||||
* this point.
|
||||
*/
|
||||
|
||||
|
@ -72,11 +72,11 @@ namespace NxWM
|
||||
|
||||
/**
|
||||
* The class CWindowMessenger integrates the widget control with some special
|
||||
* handling of mouse and keyboard inputs neesed by NxWM. It use used
|
||||
* handling of mouse and keyboard inputs needs by NxWM. It use used
|
||||
* in place of CWidgetControl whenever an NxWM window is created.
|
||||
*
|
||||
* CWindowMessenger cohabitates with CWidgetControl only becuase it nees the
|
||||
* CWidgetControl as an argument in its messenging.
|
||||
* CWindowMessenger cohabitates with CWidgetControl only because it needs the
|
||||
* CWidgetControl as an argument in its messaging.
|
||||
*/
|
||||
|
||||
class CWindowMessenger : public NXWidgets::CWindowEventHandler,
|
||||
|
@ -759,8 +759,8 @@ void CTaskbar::clickIcon(int index, bool click)
|
||||
* widget constructor
|
||||
*
|
||||
* NOTE: Actually, NxWM uses the CWindowMessenger class that inherits from
|
||||
* CWidgetControl. That class just adds some unrelated messenging capability;
|
||||
* It cohabitates with CWidgetControl only becuase it nees the CWidgetControl
|
||||
* CWidgetControl. That class just adds some unrelated messaging capability;
|
||||
* It cohabitates with CWidgetControl only becuase it needs the CWidgetControl
|
||||
* this point.
|
||||
*/
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user