next, though space does that too, in f-spot at least) image using the
keyboard even when zoomed, which otherwise they would not be able to do.
In the event that users expected the page up/down keys to pan, they'll
quickly learn they don't and th
osition if the user has never
opened that particular window though."
Sincerely,
Gabriel Burt
___
Usability mailing list
Usability@gnome.org
http://mail.gnome.org/mailman/listinfo/usability
avior, and if so can it get added to the HIG?
Thanks,
Gabriel Burt
___
Usability mailing list
Usability@gnome.org
http://mail.gnome.org/mailman/listinfo/usability
On 5/10/06, Calum Benson <[EMAIL PROTECTED]> wrote:
I filed a bug about this years ago:
http://bugzilla.gnome.org/show_bug.cgi?id=75484
I'm not sure it's really a HIG issue; the toolkit should just make
sure it works like that everywhere, unless we can think of any common
exceptions.
I think
[Sorry for the out-of-thread reply, just joined]
Quote Calum:
"In summary, now that you're a core desktop application and there are
no other core applications with a similar function, your menu entry
should not include the word "Cheese". It should be something like
"Webcam Snapshot" (I'm sure we
Hey all,
GtkRadioButtons have an embedded label which activates them. But
TreeViews with a GtkCellRendererToggle column followed by a text
column are pretty common, yet selecting them or clicking their label
don't activate them. I'd like to propose that the HIG specify that
when TreeViews are us
Additional things beyond GNOME HIG compliance to test/report:
- a11y support
- i18n support
- infrastructure (mailing list, issue tracker, website)
- license / copyright-assignment requirement
- release schedule and adherence
This is basically the criteria that I assume are used to judge apps
for
