Update a README.
This commit is contained in:
parent
a38c85dbaa
commit
96d7679d6f
@ -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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user