Update a README.

This commit is contained in:
Gregory Nutt 2019-05-25 16:17:19 -06:00
parent a38c85dbaa
commit 96d7679d6f

View File

@ -157,30 +157,46 @@ Issues:
when the window has focus.
4. A right click on the toolbar should bring up a window-specific menu.
There are no near-term plans to address these compatibility issues.
Other issues/bugs
5. Icon drag movement includes logic to avoid collisions with other
1. Icon drag movement includes logic to avoid collisions with other
icons and with the background image. That later is an issue. We
need to paint the image directly on the background without the
use of a widget.
6. There are a few color artifacts in the toolbar of the CONTEMPORARY
2. There are a few color artifacts in the toolbar of the CONTEMPORARY
theme. These look like borders are being drawn around the toolbar
widgets (even though the are configured to be borderless).
7. Most Twm4Nx configuration settings are hard-coded in *_config.hxx header
3. Most Twm4Nx configuration settings are hard-coded in *_config.hxx header
files. These all need to be brought out and made accessible via Kconfig
files
8. Things become buggy after perhaps 10 shell windows have been opened.
4. Things become buggy after perhaps 10 shell windows have been opened.
Most likely, some resource allocation is failing silently and leaving
things in a bad state. The board I am using has 128Mb of SDRAM so I
can't believe that memory is the limiting factor. These are, however,
RAM-backed windows and will use significant amounts of memory.
9. Menus with sub-menus have not been verified. There is no use of sub-
RAM-backed windows and will use significant amounts of memory. The
primary issue is that the number of windows should probably be
managed to assure that the end-user does not experience odd behaviors
with resource usage is high.
5. Menus with sub-menus have not been verified. There is no use of sub-
menus in the current code base so I expect that there are issues when,
for example, and item from a sub-menu item: That menu and all of its
antecedent menus should be closed.
10. There is an optional MENU button that may appear at the far left on
6. There is an optional MENU button that may appear at the far left on
the toolbar. It is not used by any window in the current code base
and, hence, is unverified. I would expect some issues with generating
and routing the MENU button events to applications.
There are likely other unverified features.
7. It has reported by one person that he experienced problems at high
levels of optimization (I have been using DEBUG configurations with
no optimization). This might be due to timing differences or perhaps
there is a location that needs 'volatile'.
8. X/Y input may be either via a touchscreen or a mouse. Only
touchscreen input has been verified. There is, however, very little
difference. The primary issue is in cursor support: Cursors are
needed with a mouse. Cursor images also change depending on the
state (like grabbing and dragging or resizing). There is also a
possibility of using auto-raise with a mouse as well. All of this
logic is in place, but none has been verifed.