Re: Redy Project Questions
- Posted by ryanj Oct 02, 2015
- 1689 views
Redy Project
I've looked at the Redy project with some level of detail since you last posted your update. Honestly, I like what you're doing a lot. In my opinion the best cross platform GUI comes from Java. On Linux, you can run ldd to see that Java AWT links directly to X11 lib and doesn't link to GTK, QT, etc. All this is to say, I think you're on the Java track.
I appreciate your interest. My design philosophy for Redy is to be as purist as possible. I want to rely on minimal 3rd party libraries, using direct win32api, x11, or other commonly installed C libraries as much as possible. Because all widgets in Redy are pure euphoria code, only basic window, event, graphics, and OS integration wrappers are needed on each platform.
I've never attempted an effort like the one you are working on but I'm guessing the most challenging part will be "OS" integration. For example drag and drop, printing, copy and paste (text, images, files, etc) common keyboard short cuts/hot keys, and similar are likely to eat up a lot of time. The problem has to be exaggerated on Linux since these features aren't implemented at the lower X11 level but rather at the Window Manager level such as Gnome or KDE. Or perhaps more accurately, the features are implemented at the GTK/GDK or QT level. This is probably why WxWidgets integrates at this level instead.
OS integration is pretty challaging, but much of it is already in place on Windows. Primary display resolution, clipboard functions, common file open/save dialog, and basic window handling works fine. I haven't implemented drag and drop yet, and i need a solution for handling image file formats other than bmp. I also need to add multi-monitor support, regional and language settings, shell integration, etc.
On linux, Redy will basically have to do everything wxwidgets or gtk can do.
So my questions are:
- In light of Irv M. efforts in keeping GTK up to date for years now, why not use GTK as your win32 substitute?
- If you're going the X11 lib route, how would you approach the "OS" integration issues?
The GTK wrapper is great, but it has way too much stuff that Redy doesn't need (all the widgets). Win32api is really not very hard to wrap, since i don't need Windows Controls at all.
I don't know how i'm going to port it to linux yet, but i'm pretty sure it is going to be direct xlib and/or xcb wrappers. Perhaps i will get some ideas after looking at C source code of various projects such as simple x-window applications, simple window managers, etc. If i understand correctly, xlib lets you process window events and draw to windows (with a separate graphics library?), which is all i need, since i don't need any widget library. Another possibility is to use opengl to draw all the widgets, but i haven't really looked into that yet. I don't know how window management or clipboard functions work, so i will have to do alot of research. In the end, i suppose i'll have a much better understanding of how linux works. 
i think Redy will include it's own window manager. I picture Redy being able to make gui applications that work in other desktop environments, as well as provide a complete desktop environment by itself (display manager, window manager, desktop, application manager, file manager, taskbar, system status monitor, etc.) that follows x11 standards like xfce, lxde, etc. Once all that is in place, i plan to put together a simple linux distro called Redy OS that will probably be something like debian with minimal specific packages installed, such as a basic x-window system with euphoria and redy installed. When it boots up, it will have it's own graphical login screen and desktop environment. If you want to run non-redy programs, no problem. Just like other DEs, you can run kde apps, gnome apps, gtk apps, x apps, etc. with redy window manager drawing it's own borders around the windows and stuff. It would really just be debian under the hood, so it wouldn't be difficult to maintain the Redy OS distro. One purpose for Redy OS would be to provide a very light-weight GUI for embedded computers. Another purpose is to experiment with some new GUI OS concepts, which i might explain at a later time.
