Re: [MiNT] Changing toolbars and redraw message

[Jean-François Lemaire <jflemaire@skynet.be>]

On Wednesday 07 January 2015 14:08:50 skeezix wrote:
> 	Sorry for jumping into the conversation without any context, but
> sounds to me like..
> 
> i) if an application changes its own toolbar, it could trigger its own
> redraw; but since the burden is supporting historical applications, what
> is expacted? Do that.
> 	--> If changing the behaviour breaks 'much'/anything, don't change
> it?
> 	--> Does the change actually improve much, for many applications?
> (sounds like a performance improvement, always welcome, if it doesn't
> break much.)

I don't know of any application that uses AES toolbars except for a couple of 
test apps. The Atari AES implementation was a bit restrictive and MagiC never 
supported toolbars so there were very few incentives to use them. 

However, XaAES comes with many improvements in that respect. That's why I 
dediced to use them, and to report the issues I find.

> ii) or is the risk that the toolbar could be changed from outside an
> application? like, what about a GEM desktop environment with multitasking,
> where an application toolbar could be switched out for another .. is there
> a possibility that changing toolbar is asking the app (or many apps) to
> redraw, to proplerly handle an application switch? (like an expose of some
> or all of a window)?

I'm not sure I understand. You seem to be talking about an app changing the 
toolbar of another app?

> 	--> could perhaps have AES work out if any application window is
> now exposed/dirty, and in that case ask for those windows to redraw.

That's basically what the AES does already, unless I'm missing what you mean.

Cheers,
JFL
-- 
Jean-François Lemaire