XaAES-current vs. XaAES-ozk

[mikrosk]

Just to write down observations made mostly by @skaftetryne and @GokMasE. In the future we can link concrete github issues to them.

Features missing in Ozk's (2010) XaAES build and present in current XaAES builds:

• "configurable" gradients (ozk's version contains only one hard gradient colour)
• translations
• integrated bubble gem
• custom palette for <= 256 colour resolutions
• switchable keyboard tables
• singletask mode (but has broken keyboard)
• Control+Alt+Home to force a redraw of the screen
• Control+Alt+TAB to switch applications
• When closing the last open window of an application with a menu, the menu still has focus (perhaps configurable by clwtna in xaaes.cnf)
• 1 pix window frame
• menu_attach working properly (fixed by b64d0b5)
• xaloader doesn't load xaaes<CPU>.km
• realtime moving the vertical slider in list boxes (used in eg. file selector, system window/environment listing, task manager) will result in a nervously "jumping" movement of the content when moving slowly downwards.
• support for on the fly resolution change
• Problems transferring the pointer to the text buffer in wind_get(handle, WF_NAME) (see XaAES-current vs. XaAES-ozk #241 (comment)) (fixed by 79dba5c)
• Support for function G_SWBUTTON() (see XaAES-current vs. XaAES-ozk #241 (comment))

Identified bugs not present in Ozk's XaAES:

• broken keyboard navigation
• dead menu for a few seconds after launching a program
• broken toolbars (Application receives bogus toolbar message at startup #230, Toolbars not renedered with borders #231)
• IBOX is drawn with frame if specified
• APPL_GETINFO_STR() bug (APPL_GETINFO_STR() returns incomplete data (text) #238) (fixed by 8a4d061)
• ever increasing window handle ids (XaAES doesn't reuse window handle IDs  #239) (fixed by 53f15d5)
• Popup menu will appear in wrong position y-wise if mn_item is >1 (Popup menu will appear in wrong position y-wise if mn_item is >1 #259) (fixed by 7d850b7)

Possible way of development for Ozk's XaAES (easily applicable also for the current XaAES):

• external taskmanager
• external file selector
• remove system window
• "about" window simplified
• better hotkeys (defined API, cleaner design in comparison to current xaaes)
• better wallpaper (ditto)
• get rid of the "clients" submenu alltogether
• AES rendering code moved from the kernel module to a separate library, similar to how MagiC allows external modules to draw window frames but for all AES objects.
• create an API to make the XaAES listbox functions available to user processes? (if we want to recreate processes like File Selector and Taskmanager as standalone processes in the future, we would perhaps not want to do that without access to the native listbox support, using real sliders/widgets)

Possible high-level goals:

• AES. No more, no less. Implement the APIs, make sure they work.
• Performance and memory footprint that makes it attractive for real Atari machines sans accelerators and graphics cards.
• Constantly re-iterate that we're all friends and want the best for our Atari-machines and clones.

LATEST BUILD COMPATIBLE WITH 1.19 KERNEL: xaaes-ozk-20220626-repacked.zip (rename xaaes*.km to xaaes.km for your CPU, xaloader doesn't do this automatically)

[skaftetryne]

On 11.02.2022 14:56, Miro Kropáček wrote: * IBOX is drawn with frame if specified

The other way around - in "OZK" XaAES ibox is drawn with a frame if ob_spec defines one, while current XaAES does not. Jo Even

[mikrosk]

Moved to xaaes-current bugs, thanks.

[lpgb]

Actually toolbars seem to work, but the borders are not drawn. Perhaps partially working. ;)

[skaftetryne]

On 11.02.2022 15:26, Lon Pursell wrote: Actually toolbars seem to work, but the borders are not drawn. Perhaps partially working. ;)

XaAES toolbars are more feature-rich than standard toolbars, basically you can put an entire dialog in the toolbar and XaAES will in theory handle this for you. So free windowed dialogs. There is an example somewhere in the source-tree, but if you test this it only partially works. This should either be fixed (but will the feature be used?) or removed (simplifies code). Jo Even

[mikrosk]

@lpgb I was referring to #230 but good point, applies to #231 as well.

[GokMasE]

Bug in MENU_ATTACH(me_remove,...) - RESOLVED (fixed by b64d0b5)

XaAES-ozk does have a bug that is not present in XaAES-current, regarding menu_attach() in mode 2 (me_remove).

In this mode, XaAES is supposed to remove an attached submenu, and according to TOS.HYP and Compendium, the last parameter (mdata, address to MENU structure) should then always be a NULL pointer. See here:

https://freemint.github.io/tos.hyp/en/menu.html#menu_attach
https://freemint.github.io/tos.hyp/en/aes_structures.html#MENU

However, XaAES-ozk will not remove the submenu unless the last parameter is set to <>0 which is clearly wrong.
Interestingly it seems that ANY value (including negative) except the documented NULL results in a removed submenu.
Sending the call according to docs (with mdata set to NULL) will still make the call return "1" (success), while in reality it did not de-attach the desired menu.

It would appear likely that it should be possible to fix this by just looking for mdata=NULL instead of mdata<>NULL.

[GokMasE]

Quirky movement in vertical sliders of list boxes (downwards only!)

In XaAES-Ozk, realtime moving the vertical slider in list boxes (used in eg. file selector, system window/environment listing, task manager) will result in a nervously "jumping" movement of the content when moving slowly downwards.

(This bug does not seem to be present in XaAES-current)

[GokMasE]

Problems transfering the pointer to the text buffer in wind_get(handle, WF_NAME)

It seems there are problems in XaAES-Ozk with wind_get(handle, WF_NAME,..) were the buffer passed in INTIN2/INTIN3 is not handled correctly on the XaAES side, resulting in BUS ERRORs. The problem can sometimes (but not always) be cured by a reboot, but it is always consistent within sessions.

Looking in the commit history it seems there has been a bugfix commited (83ef18e) in 2018 by @th-otto that did address errors in handling of the text buffer pointer within wind_get(handle, WF_NAME,..). Since the problem has not been possible to reproduce in XaAES-current, this might be a good candidate for "cherry picking".

[jflemaire]

On Thursday, 24 February 2022 12:11:44 CET Joakim wrote: It seems there are problems in XaAES-Ozk with wind_get(handle, WF_NAME,..) were the buffer passed in INTIN2/INTIN3 is not handled correctly on the XaAES side, resulting in BUS ERRORs. The problem can sometimes (but not always) be cured by a reboot, but it is always consistent within sessions.

How is it possible that a reboot does not cure the problem? I don't understand. Cheers, JFL -- Jean-François Lemaire

[GokMasE]

How is it possible that a reboot does not cure the problem? I don't understand. Cheers, JFL -- Jean-François Lemaire

Given the nature of the problem, it seems likely that XaAES-Ozk is doing something funky when merging the 2 WORDs (upper and lower word of the pointer to the text buffer) - into a LONG.

Why it works in some sessions and not others, I have no clue.

[mikrosk]

Problems transfering the pointer to the text buffer in wind_get(handle, WF_NAME)

Fixed & uploaded. @GokMasE basically did all the hard work. ;-)

[GokMasE]

I can confirm that the issue with wind_get(handle, WF_NAME) is gone for me after installing todays xaaes.km
Since this is one of the few really serious bugs that have surfaced after the "xaaes reboot", I appreciate this massively!

Thanks for putting the effort in @mikrosk :)

[Landemarre]

On 11.02.2022 15:26, Lon Pursell wrote: Actually toolbars seem to work, but the borders are not drawn. Perhaps partially working. ;)
XaAES toolbars are more feature-rich than standard toolbars, basically you can put an entire dialog in the toolbar and XaAES will in theory handle this for you. So free windowed dialogs. There is an example somewhere in the source-tree, but if you test this it only partially works. This should either be fixed (but will the feature be used?) or removed (simplifies code). Jo Even

This a nice feature include too in MyAES, I use it a lot for small tool, last one is name yoprez a resolution changer for modern AES (need support CH_REZCHANGE with resolution passed) without any need of any lib, very easy to use.

[GokMasE]

Support for function G_SWBUTTON() was added to XaAES-current branch as of 540995b - this needs backporting to XaAES-Ozk.

[mikrosk]

Support for function G_SWBUTTON() was added to XaAES-current branch as of 540995b - this needs backporting to XaAES-Ozk.

Easier said than done. This whole block had been added:

freemint/xaaes/src.km/draw_obj.c

Lines 949 to 1005 in 63da70b

	if( resized == true ){
	switch( c->ob->ob_type ){
	case G_SLIST:
	{
	c->ob->ob_width += dw;
	c->ob->ob_height += dh;
	list =
	object_get_slist(((XA_TREE *)get_widget(wt->wind, XAW_TOOLBAR)->stuff)->tree + c->item);
	if( list ){
	lwind = list->wi;
	/* resize the list-window */
	if( lwind && lwind->send_message )
	{
	short amq = AMQ_REDRAW;
	RECT dr = v->clip; /* send_message may change clipping */
	lwind->send_message(lock, lwind, NULL, amq, QMF_CHKDUP,
	WM_SIZED, 0,0, lwind->handle,
	lwind->r.x, lwind->r.y, lwind->r.w + dw, lwind->r.h + dh);
	(*v->api->set_clip)(v, &dr); /* restore clip */
	}
	}
	}
	break;
	case G_CICON:
	case G_BUTTON:
	//case G_FBOXTEXT:
	case G_BOXTEXT:
	case G_STRING:
	/* relocate: move objects on resizing
	* origin (upper left) of the window is set in set_and_update
	*/
	if( dh || dw )
	{
	if( (c->ob->ob_y + c->ob->ob_height) > (wt->wind->min.h) / 2 )
	{
	/* keep distance from lower border constant */
	c->ob->ob_y += dh;
	}
	{
	if( c->ob->ob_y < wt->wind->min.h / 2 && c->ob->ob_height > wt->wind->min.h / 2 )
	/* resize height for high objects */
	c->ob->ob_height += dh;
	if( c->ob->ob_x < wt->wind->min.w / 2 && c->ob->ob_width > wt->wind->min.w / 2 )
	/* resize width for wide objects */
	c->ob->ob_width += dw;
	else if( c->ob->ob_x + dw > wt->wind->r.w / 2 && c->ob->ob_x > wt->wind->min.w / 2 )
	{
	/* keep distance from right border constant */
	c->ob->ob_x += dw;
	if( c->ob->ob_x + c->ob->ob_width > wt->wind->r.w )

in commit 63da70b in usual Helmut fashion where I have to add just one more case (originally it came via 5e704435, just at the moment helmut-enhancements was created).

Trouble is that if actually requires handling of XAWS_RESIZED (added in the very same commit) and affects e.g. toolbars, too (not to mention that even adding of XAWS_RESIZED is very risky, I may easily overlook some seemingly unrelated code).

[mikrosk]

#212 has been backported, zip archive updated.

[GokMasE]

Bug #278 has been fixed in XaAES-current, would a backport to XaAES-Ozk be doable?

[GokMasE]

Bug #300 is partly affecting xaaes-ozk as well - mouse clicks are sent to the "invisible toolbar", but the toolbar buttons will not be redrawn as they are clicked. A fix should ideally be applied to xaaes-ozk of course, but perhaps it would be best to wait until @xdelatour has looked into a working solution for xaaes-cur - perhaps it could then simply be backported to xaaes-ozk.