[Usability] Re: [Fwd: Re: Your final comments on gswitchit in 2.4...]

[Christian Rose <menthos gnome org>]

tis 2003-06-24 klockan 17.31 skrev Sergey V. Oudaltsov:
> > Perhaps a better idea would be to just having different shortcuts fo
> > the different layouts, and not use cycling at all. Or have cycling, but
> > allowing the different layouts to be directly accessed by other
> > shortcuts at the same time. Perhaps this is already possible (I haven't
> > used gswitchit) but if so then I really don't see the problem.
> Actually, having different shortcuts for different groups is highly 
> problematic in xkb (if you solve it in generic way). I tried to play 
> with keyboard grabbing at some point - it gave me no full success so I 
> have up (if anyone is interested, I can give more details but I do not 
> think this is a place to discuss that). So "no cycling" is IMHO better 
> here. And actually that is what "secondary groups" feature does - takes 
> some groups out from cycling.

Ok.


> > instead[1]. The flag customization and the secondary layout feature you
> > describe very much sounds like such workaround functionality to me.
> Well, flag customization issue is already solved here (remove pixmap 
> customization, use layout name label by default). I just have to 
> implement it ASAP:) Though I don't really understand why it is 
> workaround (which problem does it actually workaround?:)

If pixmap customization is currently mainly only used as a solution for
people finding flags inappropriate or offensive, then I consider it a
workaround for that problem, but as with all workarounds a fix that
doesn't really adress the problem itself. The solution you describe
above is much better in that respect.


> Secondary layouts looks like a kind of workaround (in UI terms, no 
> internally:). But it works exactly the way people asked - so I'd say it 
> is just another feature:)

Sometimes people answer with the most crazy ideas in my experience, and
you'll also see that in Havoc's essay. Instead of explaining the basic
problem, they only describe their proposed solution. Sometimes it's not
even clear that there is an underlying problem behind their feature
suggestion, a problem they're not telling anything about. So if you only
implement what users ask for, instead of integrating solutions to the
actual problems you've found out about, you'll often end up with all
kinds of weird workarounds and conflicting behavior.


> BTW, Christian, what would be your opinion on postscript-based preview?

Was that a performerance issue? Then I'm probably not the correct person
to answer that. I don't know how big the performerance impact is.


Christian