[FFmpeg-devel] GSoC with FFMpeg waht a combination!

[Michael Niedermayer]

On Sat, Mar 22, 2008 at 10:28:58AM +0000, Robert Swain wrote:
> On 22/03/2008, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Mar 22, 2008 at 05:49:08AM +0200, Jason (spot) Brower wrote:
> >  > On Fri, Mar 21, 2008 at 10:49 PM, Mike Melanson <mike at multimedia.cx> wrote:
> >  > > Jason (spot) Brower wrote:
> >  > Additionally, people mock how slow these took
> >  > kits are but ignore all the accessability,
> >
> > I must addmit i dont know much about "accessability" but i suspect that
> >  random applications are not too accessible as such, toolkit or not.
> 
> Accessibility benefits from 'integration' as global settings for large
> fonts, high contrast or maybe APIs for reading out buttons and menus
> or whatever can be set once and work for every program that uses that
> API. At least, that's my guess.

The lack of a standard way on linux to configure fonts and their sizes suck.
That though does not mean that the solution would be to use a toolkit which
does not strictly solve that either. It just reduces the number of places
where one has to configure the fonts.
And in practice not even that works properly, there were uncountable times
when my system suddenly had different looking fonts after installing a new
libfreetype. Also even with toolkits i really dont know how to configure all
my libgtk* based apps to use a specific font, short of configuring them one
by one when they do have such a configuration option at all.

So IMO this is alot of the silly belive that complex systems would magically
solve problems and always work ...


> 
> >  Also a hearing impaired person should not have any problem using any
> >  GUI (no relation to the toolkit here)
> >  And a visually impaired person likely would use the command line tool,
> >  at least that seems logic to me, GUI and not being able to see it is a little
> >  contradictionary, even with a speech synthesizer reading it. But again
> >  iam no "accessability" expert iam just taking educated guesses.
> 
> Visually impaired need not mean completely blind. A person might have
> difficulty seeing a skinned interface (depending on the skin) but if a
> particular toolkit is used that uses global accessibility settings for
> font and theme and so on, the user doesn't need to do anything with
> the program to be able to see it as well as possible, it will already
> be set up.

3 mouse clicks to select a different skin is a pretty weak argument in
favor of using bloated toolkits.



> 
> >  > usability, and
> >
> >  slow -> not really useable
> 
> Ubuntu isn't that slow. I certainly wouldn't consider it unusable.
> Bloated, yes. Unusable, definitely not, far from it.

This depends on the hardware and what you do with it.


> 
> >  > internationalization of the program.
> >
> >  Why do you think there would be a problem here?
> 
> Are there automatic internationalisation things in toolkits?

Very good question. I doubt it ...


[...]
> Anyway, I think (unfortunately?) that Mike and Reimar are right. A
> mainstream (Windows/OS X/Gnome/KDE) GUI for easing conversion probably
> isn't something that we're able to mentor for GSoC because probably
> none of us will use and maintain it. Even if it is a good idea and
> would be welcome by users.

sad but probably true.


> 
> Per codec defaults and presets would help in the mean time though! :D

Yes and that is independant of the GUI anyway, implementing them in the
GUI is very silly design.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080322/045e613c/attachment.pgp>