[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: The state of the canvas
From:       Bill Haneman <Bill.Haneman () Sun ! COM>
Date:       2005-11-18 14:54:13
Message-ID: 437DEB15.9070009 () sun ! com
[Download RAW message or body]

Alexander Larsson said...

>In fact, I think its more important to have a simple canvas like that
>than a really powerful flexible thing to be used for diagram editors and
>powerpoint apps for the simple reason that I'm not at all sure such apps
>would use a generic canvas. Each major app is gonna have some
>requirement that makes them do their own canvas widget anyway. The
>canvas is after all an extremely core part of an app like dia,
>illustrator or powerpoint. The question is, is it possible to do a
>canvas that caters to both usecases?
>  
>
I think there's a compelling reason for multiple apps to use a common 
canvas, despite their 'custom' needs: accessibility.  Getting canvas 
accessibility right is not trivial, and it makes sense to try and do it 
in one place, to the extent possible.

>>From your page its very obvious that your target for this design is Dia,
>since you have things like selection and focus handling. This isn't bad
>per-se, but its likely that apps may want slightly different behaviour
>with such things, and maybe the core should just be powerful enough that
>things like that can be implemented in a layer above it.
>  
>
I think not - all canvasses need selection and focus handling for 
accessibility reasons.  Even if the resulting content is "read only", 
selection and focus handling are important for blind users.

>The "Details" section seems a bit weird to me. It sounds like the model
>for that map canvas would be the full data for all of germany in every
>detail, and the canvas would iterate over each street in germany
>checking the details level for it. Thats not very scalable. In fact,
>huge geographic datasets are a pretty special-case thing, and I'm sure
>map apps do map-specific things to get good scalability that a general
>canvas can't. So, the right thing to do here might be to just feed the
>canvas a more limited set of items, based on the zoom level, etc?
>  
>
That would work, perhaps, but I think general-purpose "zoom level" 
pruning would be a useful general feature nonetheless.  I don't think 
it's specific to maps at all.

The distinction being made between "scale factor" and "zoom level" (for 
want of a better set of terms) is very important to accessibility - for 
instance, I may want a large print version of the map, without including 
more detail.  So, taking "scale factor" to mean the relative size of 
onscreen objects, and "zoom level" to mean the viewport size relative to 
the original document,  the text and label sizes would need to scale 
with the "scale factor" but not the "zoom level".

The "zoom level" concept also assists accessibility, since it gives 
explicit "importance" grouping to features.

One thing I really like about the proposal is that all the elements on 
the canvas are hierarchically grouped, and have associated text.  I 
would hope that we would de-couple the "title" concept from the "name" 
concept however, since even objects without onscreen titles will need 
names of some sort, for accessibility reasons.

Keyboard navigation and keyboard access to the canvas is important, and 
I think doing it in the canvas widget itself, to the extent possible, 
will give better consistency and coverage.

Bill
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]