[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] XaAES bugtrack (admin and) feature requests



can someone give Helmut admin access ot XaAES bugs so he can close any
verified and fixed bug in the Mantis Bugtracker.

Also, can the BT give a historical list at all, or are they deleted
form the system when closed, as it may be better to log faults through
there, as there are quite a few aesthetic (resource) bugs and fixes
needed, plus people can start making feature requests which will allow
for some sort of development planing for after his current changes
have been committed to CVS and there is a (beta) point release.

Anyone who has any ideas they would like in XaAES, especially visual
or layout or config, I continue to develop ideas using 1.16 sources,
so they can be prototyped before inclusion into 1.17 source base.

I am currently ready, having already successfully added the
requirements, for extra window widgets, compile time layout setting
(the same as Gradients, with C includes), and just need to create a
script to make it easier, combined with the gradient rebuilder

currently I can offer the following for window widgets:
 - title bar layout styles:
	STYLE_NONE			full width, no widget buttons in title bar
	STYLE_DEFAULT		(default) current layout style
	STYLE_WINDOWS		full width, windows layout style
	STYLE_BEOS			beos style title and widgets (including width)
	STYLE_WIERD			a wierd layout
	STYLE_CLEAN			full width, just the close button
	STYLE_ALL_LEFT		all on the left
	STYLE_ALL_RIGHT		all on the right

- title text:
	TITLE_TEXT_NONE		not title text
	TITLE_TEXT_CENTER	(default)
	TITLE_TEXT_LEFT		left aligned text
	TITLE_TEXT_RIGHT		right aligned text
	TITLE_TEXT_OFFSET	a number of pixels combined with above placement
	TITLE_TEXT_TEXTURE	use a texture as background of font renedering
	TITLE_TEXT_SOLID		allows use of a texture, gradient or color as
background of font renedering

 - scrollbar button layout styles:
	STYLE_NONE			no buttons
	STYLE_DEFAULT		current default
	STYLE_WINDOWS		one at each end
	STYLE_BEOS			both by sizer
	STYLE_WIERD			both at other end

I have yet to iron out (with testing):
	TITLE_BAR_WIDTH		height of title bar
	TITLE_BAR_HEIGHT		width of title bar
	TITLE_BAR_VARIABLE	allow variable adjustment according to title text/font
	BUTTON_X_OFFSET	custom offsets for button widgets in titlebar
	BUTTON_Y_OFFSET	
	BUTTON_WIDTH		custom sizes in titlebar
	BUTTON_HEIGHT		
	BUTTON_ALIGN		relative alignment when customized
	BUTTON_VALIGN		
	SCROLLBAR_WIDTH	adjust height of horizontal scrollbar
	VSCROLLBAR_HEIGHT	adjust width of vertical scrollbar
	SB_BUTTON_WIDTH	width of horizontal scrollbar buttons
	SB_BUTTON_HEIGHT	height of horizontal scrollbar buttons
	VSB_BUTTON_WIDTH	width of vertical scrollbar buttons
	VSB_BUTTON_HEIGHT	height of vertical scrollbar buttons

and the ability to turn off 3D draw effects and widget outlines.
Texturing for Alert titles. Alert icons via separate resource.

I have already added the (now) missing MIN widget (as seen on
traditional AES) for FULL'ed windows, and also PIN (the ROLLUP when
right click on title bar), which just needs linking to the current
action

I have also spent a couple of days looking over other OS's and how
they compare to XaAES. Immediately I will be looking at left hand
scroll bar rendering, as a user option in XaAES, including
ScrollList's, and some more widgets like like "scrollwheel" (a static
slider bar), select list dropdowns (including Magic widget support),
transparent text entry boxes, user defined widgets (quicklaunch),
allowing alternate file selectors, allow file browser app as
fileselector (same todo in TeraDesk)

For the file selector, a way to create and delete folders, and user
definable size.

This does not include the ideas of dynamic gradient changes,
gradient/texture/color mixing, reload XaAES, load new XaAES, certain
other dynamic or runtime settings, other OS theme loaders (onto XaAES
allocation slots), or per application themes

Helmut may get to some of this before I do, if so, all the better, as
it can be implement that much quicker.

I dont expect all changes to be available from 1.17 CVS, unless a new
version (v2) is branched after this current push for a stable release,
specifically to support "fluff and stuff". I do however expect that
99% of any options to be declared "out" at compile time for a lite
version if people choose, but it will be targeted at systems that have
the resources (not the same as horse power)

Anyone willing to have a crack at anything like I have mentioned, or
want to test a couple of other possibilities, I highly recommend you
proto-type with 1.16, as the kernel will not change, nor the source
base. It will also mean faster development of more useful features s
well. As a bonus, and changes will be available for systems where the
use of 1.16 will be maintained.

Paul