Re: [MiNT] permanent solution for redraw menu issue

[Paul Wratt <paul.wratt@gmail.com>]

On Wed, Sep 12, 2012 at 10:04 AM, Eero Tamminen <oak@helsinkinet.fi> wrote:
> Hi,
>
> On maanantai 10 syyskuu 2012, Eero Tamminen wrote:
>> On keskiviikko 05 syyskuu 2012, Eero Tamminen wrote:
>> > The real problem is that there's no flag to tell that a window
>> > should be fullscreen (no menubar, no borders etc).  With that
>> > information, AES could handle redraws after window closes just
>> > fine.
>>
>> Without that, the kludge needed to get menubar drawn looks like this
>> (XaAES seems to require full menu, just few root OBJECTs wasn't enough):
>> ----------------------------------------
> ...
>> ----------------------------------------
>
> Above wasn't full menu structure, it was lacking ACC entries.
>
>
>> Not particularly pretty, but feel free to copy it if you bump into
>> same problem...
>
> Apparently that causes Desktop to freeze with some applications
> under XaAES (and caused bus errors with some single TOSes), when
> calling menu_bar().  This is although the ACC entries aren't even shown
> on screen as a result of calling menu_bar(), just the menu headings.
>
> This issue is a bit strange though, because exactly same menu structure
> didn't cause similar Desktop freezes for other apps.
>
>
>         - Eero
>

so atm a working solution is to draw install an empty menu on exit of
fullscreen app and where uninstalling it causes the AES to redraw
menu/desktop

bit of a kludge, but as long as it works with current AES, it can be
used (and documented)

What is this idea of WM_FULLSCREEN. That sounds much simpler and more
useful for current AES. How would one go about implementing it if
using an AES which doesn't support it?

Also, what is issue with mentioned "function that should not be used
with multi-tasking AES", the on that works in regular TOS. Is it not
possible to fix/patch in current AES so it can (safely) be used. This
is solution for none GEM apps, but different for GEM apps without menu
bar (GEM fullscreen apps).

JFL:
yeah I have not problem doing the coding for it, I do have need of it
for project. I would do what is required for current libs too, to
support "other" AES. But I dont like solution/code/patch sitting there
doing nothing for 2 years either.. so if I do it, I expect any coded
solution to be verified and adopted.

The people who know the AES/VDI the most are here and active atm,
along with those who use it too, so combined they are the best to
define permanent solution. If needed, I can do code after that..
(incl. libs etc)

Paul