Re: Bringing the love back together (for the UI and platform).



Jeff Waugh wrote:

<'bout trees>
 
> Currently we have:
> 
>  - file list views in our open/save windows
>  - file icon view in Nautilus
>  - file list view in Nautilus
>  - music file list view in Nautilus (I filed a bug on this one, aye)
>  - file/folder tree view in Nautilus
>  - desktop icon view in Nautilus (which is a hack on the icon view, ja)
>  - email list in Evolution
>  - folder tree view in Evolution
>  - come to think of it, the wacky number of ETable views in Evolution (some
>    aren't really relevant to this though, like the contact card view)
>  - the, ah, annoying tree and list widgets in GTK+ 1.x (well!)
> 
> Standardising all of this for 2.0 would be cool for the UI and the platform.
> 
> - Jeff

And we have deprecated list and tree views that apps are using and
deriving from...

Trying to support a reasonable subset of these many tree/list widgets
for accessibility is a big worry, tree/table views are one of the
hardest accessibility interfaces to support (due to its relative
richness).

One thing that would be really wonderfully cool would be
re-engineering of some of these widgets so that they derived from
GtkTreeView... one the one hand I realize that it's not usual to do
additional engineering on deprecated widgets, but so many apps will be
relying on them that accessibility will be broken until the apps port
to the new widgets, as it now stands. Given that the apps will find it
hard to port before July 32 ;-) , we have the prospect of both
deprecated widgets and this laundry list of custom/workaround widgets
being heavily used on the GNOME 2.0 desktop.  

So... is there any value in asking the question of each of these
heterogeneous widgets, "can this widget be refactored to derive from
GtkTreeView" ?  For widgets where the answer is "yes", it means that
they might not need to be deprecated (in cases where they are) and
also they would have builtin accessibility support (from our pending
implementation in GTK+/ATK/"libgael"), which for some deprecated
widgets could be unfeasible otherwise. 

I know that most "nice to have" stuff has to be punted to >2.0 at this
point.  But we have this accessibility requirement on major apps that
puts a lot of pressure on the non-standard widgets.

Thoughts on this very open-ended question are appreciated, I hope that
despite my vagueness in a few descriptions, everyone can figure out
what I am getting at.

Best regards,

Bill

P.S. - it was really cool meeting folks at GUADEC, I'm stoked now :-)
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland




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