编辑：现在我已经回去看看你的其他帖子我想我对你所问的问题有了更好的理解。 对于像 Nintendo DS 这样的嵌入式系统上的 GUI，我会考虑使用“立即模式”GUI。 Jari Komppa 有一个 关于它们的很好的教程，但是您可以使用比他提供的 C 代码更面向对象的 C++ 方法。
I wouldn't use OpenGL for the GUI unless you are planning for hardware accelerated and/or 3D effects that you don't think you would get with a more traditional GUI toolkit (e.g Qt, wxWidgets, GTK, etc). If you just need a quick simple GUI for hosting your OpenGL graphics then FLTK is a nice choice. Otherwise, for rendering the GUI directly in OpenGL their are libraries like Crazy Eddie's GUI that do just that and provide lots of skinnablewidgets that you won't have to reinvent. The window and OpenGL context could then be provide with a portable library like SDL.
EDIT: Now that I've gone back and taken at look your other post I think I have a better understanding of what you are asking. For a GUI on an embedded system like the Nintendo DS, I would consider using an "immediate mode" GUI. Jari Komppa has a good tutorial about them, but you could use a more object-oriented approach with C++ than the C code he presents.
For a platform like the PSP, I'd worry slightly about the performance of an IM GUI solution. With a traditional retained mode type of solution, when you create a control, you can also create the vertex buffer/display list or what-have-you required to render it. With an immediate mode solution, it seems to me that you'd need to recreate this dynamically each frame.
You might not care about this, if you're only doing a few buttons, or it's not going to be used in-game (assuming you're making a game) but, especially if you have a fair bit of text, the cost of rendering might start to hurt if you can't find a way to cache the display lists somehow.
Have a look at Qt. It is an open source library for making GUI's. Unlike Swing in Java, it assumes a lot of stuff, so it is really easy to make functional GUI's. For example, a textarea assumes that you want a context menu when you right click it with copy, paste, select all, etc. The documentation is also very good.
http://www.fox-toolkit.org has an API reference, if you're looking how to work with a specific framework. Or were you more interested in general theory or something more along the lines of how to do the low-level stuff yourself?
我会第二个Qt。 它是跨平台的，我发现它比内置的 Visual Studio GUI 更容易使用。 它是双重许可的，因此如果您不希望代码采用 GPL，您可以购买许可证。
I'll second Qt. It's cross platform, and I found it much easier to work with than the built in Visual Studio GUI stuff. It's dual-licensed, so if you don't want your code to be GPL you could purchase a license instead.
我最近根据 Jari 页面上的演示编写了一个非常快速的 IM-GUI 系统，就我而言，我真的只想能够在屏幕上获得几个按钮和框，或多或少只是硬代码对输入的响应，感觉确实是正确的做法，而不是寻求更全面的 GUI 架构。 （这是在 DirectX 应用程序中，因此我的选择数量非常有限）。
For more information about "immediate mode" GUI, I can recommend the Molly Rocket forums. There's a good video presentation of the thinking behind IM-GUI, along with lots of discussion.
I recently hacked together a very quick IM-GUI system based on presentation on Jari's page, and in my case, where I really just wanted to be able to get a couple of buttons and boxes on the screen, and more or less just hard code the response to the inputs, it really felt like the right thing to do, instead of going for a more full blown GUI-architecture. (This was in a DirectX-application, so the number of choices I had was pretty limited).
发布评论
评论（9）
我会看看 GLAM 和 GLGooey
I'd have a look at GLAM and GLGooey
我看过 Molley Rocket 的视频并浏览了 Jari Komppa 的缓存教程。
IM-GUI 似乎是最好的方法，我认为它将比我最初设想的系统更加精简，并且构建起来要快得多。
现在一个新问题，我只能排除一个答案。 :(
再次感谢 Monjardin 和 dooz，干杯
。thing2k
I've had a look at the Video from Molley Rocket and Looked through Jari Komppa's cached tutorials.
An IM-GUI seems the best way to go, I think it will be a lot more streamlined, and lot quicker to build than the system I originally had in mind.
Now a new issue, I can only except one Answer. :(
Thanks again to Monjardin and dooz, cheers.
thing2k
我不会在 GUI 中使用 OpenGL，除非您计划使用更传统的 GUI 工具包无法获得的硬件加速和/或 3D 效果（例如 Qt, wxWidgets, GTK 等）。 如果您只需要一个快速简单的 GUI 来托管 OpenGL 图形，那么 FLTK 是一个不错的选择。 否则，为了直接在 OpenGL 中渲染 GUI，它们是类似 Crazy Eddie's GUI 就是这样做的，并提供了很多 skinnable 小部件，您无需重新发明。 然后可以使用 SDL 等可移植库来提供窗口和 OpenGL 上下文。
编辑：现在我已经回去看看你的其他帖子我想我对你所问的问题有了更好的理解。 对于像 Nintendo DS 这样的嵌入式系统上的 GUI，我会考虑使用“立即模式”GUI。 Jari Komppa 有一个 关于它们的很好的教程，但是您可以使用比他提供的 C 代码更面向对象的 C++ 方法。
I wouldn't use OpenGL for the GUI unless you are planning for hardware accelerated and/or 3D effects that you don't think you would get with a more traditional GUI toolkit (e.g Qt, wxWidgets, GTK, etc). If you just need a quick simple GUI for hosting your OpenGL graphics then FLTK is a nice choice. Otherwise, for rendering the GUI directly in OpenGL their are libraries like Crazy Eddie's GUI that do just that and provide lots of skinnable widgets that you won't have to reinvent. The window and OpenGL context could then be provide with a portable library like SDL.
EDIT: Now that I've gone back and taken at look your other post I think I have a better understanding of what you are asking. For a GUI on an embedded system like the Nintendo DS, I would consider using an "immediate mode" GUI. Jari Komppa has a good tutorial about them, but you could use a more object-oriented approach with C++ than the C code he presents.
对于像 PSP 这样的平台，我会稍微担心 IM GUI 解决方案的性能。 使用传统的保留模式类型的解决方案，当您创建控件时，您还可以创建顶点缓冲区/显示列表或渲染它所需的内容。 对于立即模式解决方案，在我看来，您需要在每个帧中动态地重新创建它。
如果您只做几个按钮，或者它不会在游戏中使用（假设您正在制作游戏），您可能不会关心这一点，但是，特别是如果您有相当多的文本，则成本如果您找不到以某种方式缓存显示列表的方法，渲染的性能可能会开始受到影响。
For a platform like the PSP, I'd worry slightly about the performance of an IM GUI solution. With a traditional retained mode type of solution, when you create a control, you can also create the vertex buffer/display list or what-have-you required to render it. With an immediate mode solution, it seems to me that you'd need to recreate this dynamically each frame.
You might not care about this, if you're only doing a few buttons, or it's not going to be used in-game (assuming you're making a game) but, especially if you have a fair bit of text, the cost of rendering might start to hurt if you can't find a way to cache the display lists somehow.
看看 Qt。 它是一个用于制作 GUI 的开源库。 与 Java 中的 Swing 不同，它假设了很多东西，因此制作功能性 GUI 非常容易。 例如，当您右键单击文本区域并进行复制、粘贴、全选等操作时，假设您需要一个上下文菜单。 文档也非常好。
Have a look at Qt. It is an open source library for making GUI's. Unlike Swing in Java, it assumes a lot of stuff, so it is really easy to make functional GUI's. For example, a textarea assumes that you want a context menu when you right click it with copy, paste, select all, etc. The documentation is also very good.
http://www.fox-toolkit.org 有一个 API 参考，如果您正在寻找如何使用特定框架。 或者您对一般理论更感兴趣，还是对如何自己做低级工作更感兴趣？
http://www.fox-toolkit.org has an API reference, if you're looking how to work with a specific framework. Or were you more interested in general theory or something more along the lines of how to do the low-level stuff yourself?
我会第二个Qt。 它是跨平台的，我发现它比内置的 Visual Studio GUI 更容易使用。 它是双重许可的，因此如果您不希望代码采用 GPL，您可以购买许可证。
I'll second Qt. It's cross platform, and I found it much easier to work with than the built in Visual Studio GUI stuff. It's dual-licensed, so if you don't want your code to be GPL you could purchase a license instead.
最快的方法之一是使用带有 gui 绑定的 python，例如 pyQt、PyFLTK、tkinter、wxPython，甚至通过使用 SDL 的 pygame。
它简单快速且独立于平台。
包裹的管理也是无与伦比的。
请参阅：
One of the fastest ways is to use python with a gui binding like pyQt, PyFLTK, tkinter, wxPython or even via pygame which uses SDL.
Its easy fast and platform independent.
Also the management of the packages is unbeatable.
See:
有关“立即模式”GUI 的更多信息，我可以推荐 Molly Rocket 论坛。 有一个很好的视频演示了 IM-GUI 背后的想法，以及大量的讨论。
我最近根据 Jari 页面上的演示编写了一个非常快速的 IM-GUI 系统，就我而言，我真的只想能够在屏幕上获得几个按钮和框，或多或少只是硬代码对输入的响应，感觉确实是正确的做法，而不是寻求更全面的 GUI 架构。 （这是在 DirectX 应用程序中，因此我的选择数量非常有限）。
For more information about "immediate mode" GUI, I can recommend the Molly Rocket forums. There's a good video presentation of the thinking behind IM-GUI, along with lots of discussion.
I recently hacked together a very quick IM-GUI system based on presentation on Jari's page, and in my case, where I really just wanted to be able to get a couple of buttons and boxes on the screen, and more or less just hard code the response to the inputs, it really felt like the right thing to do, instead of going for a more full blown GUI-architecture. (This was in a DirectX-application, so the number of choices I had was pretty limited).