Re: The state of the canvas
- From: Bill Haneman <Bill Haneman Sun COM>
- To: gtk-devel-list gnome org
- Subject: Re: The state of the canvas
- Date: Fri, 18 Nov 2005 14:54:13 +0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]