Shisheng Chen

由于rust语言的特性，似乎将AWTK绑定到rust比较困难，并且rust还是比较难入门。 所以个人不是太看好在嵌入式领域使用rust了。个人目前比较看好zig这门新语言，虽然还没达到1.0版本，但它跟C融合得比较好，甚至可以拿zig当C编译器来用。

AWTK的构建系统确实一般，我都提好多意见了。貌似李大侠相较于python更喜欢javascript，所以构建系统里有好多javascript写的工具，这就导致很多东西没有形成依赖关系。另外很多编译配置都是写死在构建脚本里面的，不够灵活。 像RT-Thread的构建系统就很完善：kconfig + scons，配置灵活、依赖清晰、功能完善。 另外一个问题是，AWTK不接受PR,有点闭门造车的感觉。

最终链接还是通不过，看了下，要链接比较多windows系统内的库，看来跨平台编译是不行了。 然而尝试在windows本地编译时，发现要装nodejs,而nodejs不支持win7了！坑爹！

更好的实现方式是用`pages`控件，将同一位置上显示的不同内容放到不同的页里面。

随便添加类似printf那样的格式化字符串API也很有用: `ret_t str_format(str_t* str, const char* fmt, ...);` `str_format(str, "count: %d", 3);`

> 可以看 awtk\src\charset 里面提供的api 哦，原来在这里。不错！

> > 随便添加类似printf那样的格式化字符串API也很有用: > > ``` > /** > * @method str_format > * 通过格式设置字符串。 > * @param {str_t*} str str对象。 > * @param {uint32_t} size format生成的字符串的最大长度(用于预习分配内存)。 > * @param...

经测试awtk\src\charset里的API`encoding_utf8_to_gbk`发现，在X86_64 linux平台上转换成功、但在arm linux平台上的转换总失败。 怀疑是此平台的glibc编译的iconv支持有问题，于是在`encoding.c`文件的开头加入`#undef LINUX`以强制不使用iconv后字符串转换成功。 故不建议在linux平台默认使用iconv,而由用户选择是使用iconv还是awtk内部支持。

> 定义宏NDEBUG即可。 > > ```c > #if defined(WIN32) && !defined(NDEBUG) > #define TK_ENABLE_CONSOLE() \ > { \ > AllocConsole(); \ > FILE* fp = NULL; \ > freopen_s(&fp, "CONOUT$", "w+t",...

> 应该是在自己的应用程序里定义。 我现在使用的是awtk_main.inc里的application_init函数作为入口。看了下awtk_main.inc源码，如果编译器是mingw的话程序的入口是main函数而非GUI程序的WinMain之类，所以必定会有控制台窗口。 我没什么win32 api的编程经验，搞这个还要花点时间，建议官方在awtk_main.inc里就做好WinMain入口。 这其实算是一个BUG,我的APP类型都已经定成 `APP_DESKTOP`了，但实际编译出来的却是console类型程序。