--- Begin Message ---
(cc to debconf-video, since there are some stakeholders there)
On Thu, 2007-04-05 at 10:54 +0100, Daniel James wrote:
> Hi Eric,
>
> > Will there be enough people from this list there to warrant setting up a
> > multimedia bof or working group session?
>
> I could give a talk on 64 Studio, as part of the DebianDay user
> conference on the 16th.
>
> > I would like
> > to meet with interested persons to discuss goals for lenny.
>
> Now that's what I call strategic thinking ;-)
>
> I would have thought by the time of the lenny release you're going to
> want solid support for multi-core CPU machines (four cores plus).
Indeed! You would also want painless support for hardware-accelerated
OpenGL, as some video software actually use that now. And surround-
capable sound devices, too.
The BIG challenge though, is to get as much as possible to "just work",
and present it to the user and the applications.
I have a few concerns in that regard:
1) Being GUI agnostic and independent of X...
Should the primary configuration interfaces for video and graphics be
text files and curses? It seems a bit absurd to ask the user several
questions he may not know the answer to, without the opportunity to test
the options immediately.
Should not package maintenance commands like dpkg-reconfigure be exposed
in the Desktop Environment GUIs (I couldn't find it in Synaptic) ?
A video editing workstation used by a person who is a video pro and not
steeped in *nix will never be used in text mode. The user will expect
to find and tweak all the needed settings through a GUI.
Most Linux distros do a lot of their magic at install time, to avoid
presenting the user with incomprehensible options. Unfortunately making
a complete and _usable_ UI to tweak everything after installation is a
lot of work, and hard to do right. Is this completely beyond the scope
of Debian?
2) Tasks and profiles
Debian installer already has tasksel. I propose two new tasks:
a) Audio workstation
b) Video workstation
Tasks allows us to make assumptions. We can lump on sets of packages
that belong together, and create configuration packages that will
initiate services that the naive user would never know he needed.
I refer back to 1) here: Once the bundle of packages is in place, there
must be a good user interface to handle them all!
3) An API to the package manager that applications can hook into
Applications should be able to handle a missing "suggests" dependency
gracefully. That is, when library <foo> is not there, the application
ought to be able to query the package system, find that there is a
package that contains that component/file, and ask the user "do you want
to install <foo> now?".
Most of the information is already there to be mined. It is rather
disappointing with applications failing silently, so that the user has
to use strace to find why it fails, and then grep Contents-(arch).gz to
find the required package.
This would also let applications in main initiate installation of
packages in contrib and non-free, once those repositories are added.
Maybe the apps should be oblivious about the mechanisms required, and
the OS could handle it behind the scenes? Say, with stub files for the
uninstalled packages that would trigger an action once they were
accessed?
--
Herman Robak
--- End Message ---