mahlzeit
e664742f9d
- resources can now have fixed sizes git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3056 a95241bf-73f2-0310-859d-f6bbb57e9c96
38 lines
1.3 KiB
HTML
38 lines
1.3 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<TITLE>Planned features</TITLE>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF">
|
|
|
|
<H1>Planned features</H1>
|
|
|
|
<UL>
|
|
|
|
<LI><P>Simple integer expressions + - * / | & ~ ()</P></LI>
|
|
|
|
<LI><P>Make user-defined types more powerful. Some ideas: bitmask fields (for
|
|
app_flags), choice fields (for app_version), conditional constructs.</P></LI>
|
|
|
|
<LI><P>Attributes, so you can also use rdef scripts to add attributes to your
|
|
files instead of (or in addition to) resources.</P></LI>
|
|
|
|
<LI><P>In "auto names" mode, the decompiler currently does not use the enum
|
|
symbol table. So if two resources have the same name and that name is a valid
|
|
C/C++ identifier, the decompiler will add two conflicting symbols to the enum
|
|
statement. This can also happen when multiple input files have conflicting
|
|
resource IDs.</P></LI>
|
|
|
|
<LI><P>Support for the built-in types point, rect, and rgb_color is hardcoded
|
|
into the decompiler. The other built-in types--app_flags, mini_icon, etc--are
|
|
not supported at all. It would be better to use the type symbol table for this
|
|
as well. Then the decompiler can also support user-defined types (although these
|
|
type definitions must be provided to the decompiler somehow.)</P></LI>
|
|
|
|
<LI><P>Right now, archives are treated as messages. Maybe we should give them
|
|
their own type, B_ARCHIVED_OBJECT (type code 'ARCV').</P></LI>
|
|
|
|
</UL>
|
|
|
|
</BODY>
|
|
</HTML>
|