ozone is quite well developed using widgets and an internal compiler to test them live.
It even has a registry database but the issue is the source code is 20 years old, uses an old as hell version of gcc and c89. While it can support a multithreaded kernel, c89 and the threading code is not compatible with this. Lwp works great under dos and I often wondered about adding it to fltk. Seal 2 is a monstrosity. I managed to get it to build but the registry is broken and would load this and that. I still have the source code for cube gui (not the same as qube) but I don't actually think I've tried to build it which was like some seal 3 and ozone mixed up code. Most of these rely on allegro 4.2 which is miles out of date and can only handle legacy resolutions. Aura GUI is a continuation of ozone code with the LWP threading library, judasHD audio and watt32 but has the same inherent issues as the rest of them. It uses the latest version of dos compatible djgpp and allegro 4.4.3 but it's still too old. Geoworks is fun and while it's somewhat functional it also has issues. On Tue, 1 Oct 2024, 3:09 am Jerome Shidel via Freedos-devel, < freedos-devel@lists.sourceforge.net> wrote: > Hi Liam, > > > On Sep 30, 2024, at 8:08 AM, Liam Proven via Freedos-devel < > freedos-devel@lists.sourceforge.net> wrote: > > [..] > > GEM is misconfigured and doesn't work. That is easily fixable though. > > It needs to know if it's running in a subdirectory, and currently it > > installs to a subdirectory but is configured to run in root. I worked > > around that by mapping drive G: to its folder, and then running it > > from G: > > > > Seal and Ozone seemed incomplete and not worth having, along with > > several others. > > > > PGME does work but I had problems with the mouse driver and with the > > graphics mode and screen fonts. Personally I'd prefer to be able to > > turn that stuff off and just run it in plain text mode, but I think I > > suggested this and Jerome was very negative about the suggestions. :-( > > I personally rate function above looks, and think minimal looks more > > professional, but maybe that is just me. > > This must have been a long while back. > > I apologize if I may have seemed negative about any suggestions you may > have given. > > I always try to be very open about receiving comments on improving > anything I’ve written. Obviously, this is not the same as agreeing with or > implementing everything that is suggested. But, I do try and listen to them > without imposing any of my own personal and biased opinions. > > While there is a little bit of similarity, I don’t feel that PGME is at > all like GEM, Seal, Ozone or any of those other programs. They are all > Desktop Environments. PGME is “just" a program and game launcher. > > Although PGME requires a EGA or better video card, it does not run in > graphics mode. It is purely a text mode program. The included screen savers > of run in graphics mode. However, they can be easily disabled. > > It is possible to add an option for PGME not to use any of its fonts. And > if I remember to do it when I find the time, I will add that ability. > > It is also possible to add a setting for PGME to completely ignore a > mouse. Again, if I remember when I find the time. > > Everything about PGME is about function. For a “simple” program launcher, > it is very complex under the hood. It is built on top of a custom event > driven object oriented framework I wrote in Turbo Pascal that is more like > Delphi Forms than TurboVision. But not really like either. It has a context > aware help system that bases the help screens on what controls are present. > It also is completely customizable. It provides support for the end-user to > modify everything from what gets displayed along with the size, position > and colors. It also supports multiple languages in the interface and for > the menu items themselves. I user can even rebind event commands to > different actions or keystrokes to different event commands. > > Nearly all of that flexibility in PGME comes from the underlaying > framework I created. That has its pros and cons. On the plus side, I > recently updated the low level mouse routines in the framework to support > Mouse Wheel Up/Down movement. When the wheel is scrolled, the framework > generates either a Up or Down command event. That’s it. All done. Now the > wheel works across the entire program. On the other hand, sometimes what > may seem simple can be very complicated. Or, not even possible without > major fundamental changes in the framework. > > Also, the underlaying framework (QuickCRT, aka QCrt) is not perfect. There > are numerous areas I have not got around to doing. A great example can be > seen in PGME with the Pop-Up Menus. At this time, you cannot navigate them > using the arrow keys and must rely on keystroke->command->action bindings > or the mouse. While a user “could” bind each of those menu items to a > keystroke, that is not easy or practical. Adding that type of navigation is > intended, but I need to get motivated and find the time to implement it. > > Some of the power, flexibility and functionality that PGME provides can be > easily demonstrated. Simple execute the “Switch to KIOSK Mode” from the > menu. This changes to a completely different visual Theme that simplifies > the user interface. Locks out many options and prohibits termination. It > even removes that menu item in favor of a “Switch out of KIOSK mode” menu > item. You then can use the that item to switch back to the default mode and > theme. > > :-) > > Jerome > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
