1. Redy Project Questions
- Posted by xecronix Oct 02, 2015
- 1485 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'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.
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?
ldd libawt.so linux-vdso.so.1 (0x00007ffd409ea000) libjvm.so => not found libm.so.6 => /lib64/libm.so.6 (0x00007f1a1ee28000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f1a1ec24000) libjava.so => /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64/jre/lib/amd64/./libjava.so (0x00007f1a1e9f5000) libc.so.6 => /lib64/libc.so.6 (0x00007f1a1e634000) /lib64/ld-linux-x86-64.so.2 (0x000055e657c4e000) libjvm.so => not found libverify.so => /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64/jre/lib/amd64/./libverify.so (0x00007f1a1e425000) libjvm.so => not found ldd libawt_xawt.so linux-vdso.so.1 (0x00007fff06910000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f24f174b000) libm.so.6 => /lib64/libm.so.6 (0x00007f24f1442000) libawt.so => /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64/jre/lib/amd64/./libawt.so (0x00007f24f1172000) libXext.so.6 => /lib64/libXext.so.6 (0x00007f24f0f60000) libX11.so.6 => /lib64/libX11.so.6 (0x00007f24f0c1e000) libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f24f0a14000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f24f0810000) libXtst.so.6 => /lib64/libXtst.so.6 (0x00007f24f0609000) libXi.so.6 => /lib64/libXi.so.6 (0x00007f24f03f9000) libjava.so => /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64/jre/lib/amd64/./libjava.so (0x00007f24f01ca000) libjvm.so => not found libc.so.6 => /lib64/libc.so.6 (0x00007f24efe09000) /lib64/ld-linux-x86-64.so.2 (0x0000564d8c9f3000) libjvm.so => not found libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f24efbe6000) libjvm.so => not found libverify.so => /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.60-14.b27.fc22.x86_64/jre/lib/amd64/./libverify.so (0x00007f24ef9d6000) libXau.so.6 => /lib64/libXau.so.6 (0x00007f24ef7d2000) libjvm.so => not found
2. Re: Redy Project Questions
- Posted by euphoric (admin) Oct 02, 2015
- 1467 views
Redy Project
- 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?
One of his goals for this project was to have a Euphoria-only set-up. IOW, no third-party software required.
3. Re: Redy Project Questions
- Posted by ryanj Oct 02, 2015
- 1440 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.
4. Re: Redy Project Questions
- Posted by xecronix Oct 02, 2015
- 1436 views
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.
Thanks. Very cool idea. And your progress is remarkable!
On linux, Redy will basically have to do everything wxwidgets or gtk can do.
I'm not an expert here but I don't think they actually to the same thing. I think WxWidgets is much closer to your implementation of Redy thus far. WxWidgets has it's own widget set. But it sits on top of win32 or gtk in order to draw them. If the WxWidgets team wanted to implement their own clipboard, dnd, etc, there would have been no reason to link against GTK. They could have simply linked against X, which is what GTK does.
I'm not saying either is a better design. In fact, let me reiterate that I believe the team that has done this task the best so far has been the Java team. And they did not link against GTK. Instead they link straight to X. (Which is what you're planning to do.)
What I am saying though is "OS" integration was implemented in Motif, again in GTK, again in QT, and again in Java. And one day, again for Redy.
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?
I'm not sure I was as clear as I could have been here. But just to be sure, what I meant was that for the Linux platform only, using GTK for drawing and OS integration. GTK is so popular on Linux you can hardly consider it 3rd party.
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.
This is what I was thinking when I first started looking into your project. I think this sounds like a lot of fun. Though, I didn't consider OS integration until I learned (a bunch) from your Redy code. It's a tough problem you're solving.
5. Re: Redy Project Questions
- Posted by jimcbrown (admin) Oct 02, 2015
- 1467 views
I'm not an expert here but I don't think they actually to the same thing. I think WxWidgets is much closer to your implementation of Redy thus far. WxWidgets has it's own widget set. But it sits on top of win32 or gtk in order to draw them. If the WxWidgets team wanted to implement their own clipboard, dnd, etc, there would have been no reason to link against GTK. They could have simply linked against X, which is what GTK does.
Actually, they do have a version that only links against X. See wxUniversal and wxX11: https://www.wxwidgets.org/docs/faq/general/#univ
If the WxWidgets team wanted to implement their own clipboard, dnd, etc,
Actually, they can still do this and still share clipboard and dnd with GTK (and Qt for that matter). If the widget toolkits implemented their own unique clipboards, then applications written using different widget toolkits would not be able to share the clipboard with each other. That's why X does implement its own clipboard.
See http://www.edwardrosten.com/code/dist/x_clipboard-1.1/paste.cc for some example code that performs clipboard and dnd operations purely with Xlib.
6. Re: Redy Project Questions
- Posted by xecronix Oct 05, 2015
- 1388 views
Actually, they do have a version that only links against X. See wxUniversal and wxX11: https://www.wxwidgets.org/docs/faq/general/#univ
... they can still do this and still share clipboard and dnd with GTK (and Qt for that matter). If the widget toolkits implemented their own unique clipboards, then applications written using different widget toolkits would not be able to share the clipboard with each other. That's why X does implement its own clipboard.
See http://www.edwardrosten.com/code/dist/x_clipboard-1.1/paste.cc for some example code that performs clipboard and dnd operations purely with Xlib.
Very nice code example with explanation. Thanks. I didn't notice the wxX11 port either. I'm not sure why it doesn't show up when I search for it on Fedora or on my Raspberry Pi default repos.
Two of the most significant benefits that I see using Xlib directly are:
- I'm compiling and running example code today that was written in 1997. I'd say Xlib is pretty stable! (Very big deal IMO)
- No dependence on 3rd party libs. (though I might argue that GTK is hardly a 3rd party lib on a Linux system)
If you ignore *all* of the widgets and dialogs provided by GTK what you're left with is an already wrapped up API to xlib. I've never attempted to wrap up an API as complex as xlib but my initial novice investigation suggests that it may require wrapping up the following:
- Xlib.h (this is the bulk of the work, connection to xserver, clipboard, primitive drawing routines, etc )
- X.h (needed directly by Xlib)
- Xatom.h (needed for clipboard and drag 'n' drop)
- Xinerama.h (for multiple monitors)
- Xrandr.h (screen size, orientation, reflection)
This represents about 5400 lines of header code. That's all before you start talking about other sub systems like printing. (IE CUPS, cairo, postscript, etc)
So, I guess what I'm trying to understand is on a Linux system, what are the downsides to interfacing with xlib via GTK? So far, the only one that I've come up with is the fact that there are 3 versions of GTK out in the wild now. GTK2 and GTK3 are both currently competing for market share on Linux currently. On a modern Linux distro both GTK2 and GTK3 are likely to coexist. I'm happy to call this a form of bloat! Especially for a tiny embedded system.
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.
Given the project goals include window manager, desktop, etc. maybe wrapping up significant portions of Xlib is really just minor work relatively speaking. When I look at that task, I see a mountain where someone with more Euphoria experience may see a mole hill.
