LCUI 3.0 development plan #239

Just out of curiosity - why complicate build process so much? Why not to use any cross-platform build system (meson, xmake, may be even simple makefiles?). I like LCUI, but I feel like installing it in the past was easier (at least on linux)

Just out of curiosity - why complicate build process so much? Why not to use any cross-platform build system (meson, xmake, may be even simple makefiles?). I like LCUI, but I feel like installing it in the past was easier (at least on linux)

Because the building tools I knew before I created LCUI project were autotool and Visual Studio, so I used them to build LCUI in Linux and Windows respectively. As the project is updated, the build configuration becomes more and more complex.

In the 3.0 development plan, I plan to use cross platform building tools to build LCUI. The new source code organization may allow me to compile LCUI by adding a simple configuration without spending too much time researching the documentation of the build tool.

I'm not a C programmer, so it might be a silly question, but why prefix all the names with "lib" prefix? By defition this is a library, so why specify it on all entities

I'm not a C programmer, so it might be a silly question, but why prefix all the names with "lib" prefix? By defition this is a library, so why specify it on all entities

@WhoAteDaCake

There are two reasons for using the lib prefix:

• Using LCUI as the prefix name is too long, so temporarily use lib instead of LCUI as the prefix.
• The lib prefix can describe that this identifier imported from a third-party library, rather than the code of the project itself.

For this prefix name problem, we have the following solutions:

• Choose a new name for LCUI. If the new name of LCUI can be abbreviated by one letter, as in Qt, it can be abbreviated as Q, then this letter can replace lib as the prefix name.
• Do not use lib as a prefix.

I want to know more about the basic tools library to decide whether I will try realizing it. Could you make a list of the features that are in need? For example, as for the container, do you need all the containers in STL(I mean the Standard Template Library in C++), or just a vector and map? By the way, the website says all the contributors of the project are Chinese, so must I use English when I write comments and documents?

the website says all the contributors of the project are Chinese,

@FireInIceCode The website you mentioned is summer.iscas.ac.cn?

No, the

the website says all the contributors of the project are Chinese,

@FireInIceCode The website you mentioned is summer.iscas.ac.cn?

No, I mean https://lcui.org/

主要理由如下： 给其他开发者一个打造或推广开源项目的机会。 寻找合适的解决方案。因悬赏任务而开发的项目，会优先考虑我们的需求并给出合适的解决方案，能让我们快速上手并将之应用到 LCUI 中。 促进技术交流和合作。都是国人开发的开源项目，交流和合作比较方便一些，而且由于项目的依赖关系，还有机会为对方的项目反馈问题和建议以及贡献代码。 合理利用现有资源，节约成本。在用其他开源项目前需要花大量时间找文档学习，遇到问题时不容易找到方法，如果用的项目是国人开发的且他有空给你提供技术支持，那就简单多了。 让更多的人参与进来。开源的意义在于大家都可以参与推动项目的发展，而让大家参与的前提是他们知道这个项目是什么、打算做什么以及他们能提供哪些帮助，如果所有工作都让我们自己独自承当的话，那这个项目就会一直停留在自娱自乐的水平。

@FireInIceCode

No, I mean https://lcui.org/

你贴的是 lcui.lc-soft.io 中文主页上的内容，不是 lcui.org。

so must I use English when I write comments and documents?

优先用中文。

Just out of curiosity - why complicate build process so much? Why not to use any cross-platform build system (meson, xmake, may be even simple makefiles?). I like LCUI, but I feel like installing it in the past was easier (at least on linux)

Because the building tools I knew before I created LCUI project were autotool and Visual Studio, so I used them to build LCUI in Linux and Windows respectively. As the project is updated, the build configuration becomes more and more complex.

In the 3.0 development plan, I plan to use cross platform building tools to build LCUI. The new source code organization may allow me to compile LCUI by adding a simple configuration without spending too much time researching the documentation of the build tool.

In terms of versatility, I recommend CMake.

1. A video component using small library (https://github.com/cisco/openh264) would be great!
2. Also since lcui uses cpu and gdi+ a host component can be very good to host other windows and controls inside the lcui UI.

Just out of curiosity - why complicate build process so much? Why not to use any cross-platform build system (meson, xmake, may be even simple makefiles?). I like LCUI, but I feel like installing it in the past was easier (at least on linux)

Because the building tools I knew before I created LCUI project were autotool and Visual Studio, so I used them to build LCUI in Linux and Windows respectively. As the project is updated, the build configuration becomes more and more complex. In the 3.0 development plan, I plan to use cross platform building tools to build LCUI. The new source code organization may allow me to compile LCUI by adding a simple configuration without spending too much time researching the documentation of the build tool.

In terms of versatility, I recommend CMake.

From what I've seen so far cmake is always horrible to maintain and understand :shrug:

In terms of versatility, I recommend CMake.

@Taswen

I've decided to use xmake because I can easily communicate with xmake author about usage issues.

Here is the xmake configuration file: https://github.com/lc-soft/LCUI/blob/v3.0-dev/xmake.lua

I've decided to use xmake because I can easily communicate with xmake author about usage issues.

Here is the xmake configuration file: https://github.com/lc-soft/LCUI/blob/v3.0-dev/xmake.lua

That is good. It depends on your convenient of development. But personally, I still think it will better to provide an option of CMake. For the following reasons:

1. Many IDEs integrate native support for CMake, such as VS, Clion, QT.
2. At least until now, the number of users using cmake is larger than that using xmake. To use LCUI, some people have to configure and learn xmake (IDE can generate CMAKE configuration) which means that the use cost increases.
3. More general and powerful.

CMake has become the de-facto standard of C/C++ development tools. For further promotion, CMake is still needed.

Maybe, you can think about it later.

From what I've seen so far cmake is always horrible to maintain and understand 🤷

Maybe it’s a bit more complicated, but it’s also very useful (just like C++ 🤪).

@Taswen

xmake supports generating CMakelists.txt file using the xmake project -k cmakelists command.

1. Many IDEs integrate native support for CMake, such as VS, Clion, QT.

This is not a necessary reason to use CMake. The IDE can also be used just as a code editor, the only bit of trouble is that we need to open the command line terminal and then type the xmake command if necessary to build the project. In Linux, I use VSCode to edit the code of LCUI and use xmake command to build LCUI in its built-in command line terminal. Such development mode does not affect my development efficiency.

2. At least until now, the number of users using cmake is larger than that using xmake. To use LCUI, some people have to configure and learn xmake (IDE can generate CMAKE configuration) which means that the use cost increases.

As a library, lcui is commonly used in two ways:

1. Download the compiled binary package and extract the header file and library file (.dll ,lib or. .a .so) from it, and then manually configure the header file directory and library directory of the compiler in your project.
2. Download the source code and compile it manually. In the simplest case, you only need to run the xmake command to build LCUI. If you have more needs, it is necessary to learn xmake, and I don't think the learning cost of xmake is high.

3. More general and powerful.

This is not a reason for me to use CMake. I only focus on whether I can describe the build configuration of the project with less and simple code, and I am not interested in whether it is powerful.

As you still in planning, may be you should have a look at Blend2D and think of QuickJS integration. (I'm not affiliated with them :) )

3.0 支持多窗口吗