If that's the Qube GUI I'm recalling in my mind, cool - you should put that up
on your site or GitLab or something. I always thought it had a sweet 90's MacOS
aesthetic, which I find quite visually pleasing.
Sent with [Proton Mail](https://proton.me/mail/home) secure email.
On Monday, September 30th, 2024 at 3:31 PM, Chelson a via Freedos-devel
<freedos-devel@lists.sourceforge.net> wrote:
> 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
