Contributor charlieman

On Windows pressing either Ctrl+Alt+Del or Ctrl/Shift/Esc brings up the Task Manager. If apps crash in linux many users will try these key combinations with no reward. Mapping these key combinations, by default, to the the Gnome System Monitor will help a large number of new users.

I know it's just like OS X, but it's very intuitive. Not sure if its possible, but shouldn't realistically be _too_ difficult..

One of the reasons game consoles are so popular is that they provide a uniform runtime environment. Game developers have certain 'givens' that they can assume when they develop a game - system performance, graphics capability, controller availability, etc. This means that the game works the same on everyone's console.

But in the PC gaming world, the game developers must be aware of and test for many different hardware and software configurations. This makes games for PCs less reliable and adds to the expense of development.

I propose developing a sort of test suite for ubuntu (or other distros) that can evaluate system performance to determine if a specific game can work on a users machine. This could be integrated with something similar to valve's steam, but built with open source code. The goal is to make something that eases the pain of testing and distribution for game developers, smoothing the path to more commercial (and open source) games on linux.

From the user side:
- a way to evaluate system capabilities, to determine what games can work.
- a guarantee that games that qualify on their system will actually work.
- a way to install games online, for ubuntu probably just providing a front end for packages.
- a way to buy commercial games online.

From the developer side:
- ability to code to a specific performance level on the users' machine.
- guarantees of a consistent runtime environment, with much of the burden of testing resting on the community developed tools rather than on the individual developer.
- an easy way to distribute commercial or noncommercial games on linux at low/no cost.

[Disclaimer: English isn't my language - please forgive the errors in what follows]

Most of the software is written in English. Then the strings it contains are translated to various target languages, but at release time, some applications are only partially translated.

For example, an app may come with an "Edit" menu containing the following items (in French):

Annuler
-------
Couper
Copy --> still in English
Coller
-------
Tout sélectionner

To solve this problem, I suggest that *every* string in *every* app has an unique ID. When the user sees an untranslated string, she/he should be able to translate it using a special combination (e.g. Ctrl-Alt-Shift-Click or whatever).

The system would then show a popup dialog to type in the translated version of the string, and this translated version (this is the important part):

- is stored locally, so that the item is *immediately* translated locally
- is sent, along with its unique ID, to a central translation database so that other users may benefit trom the translation

Currently you don't finde all of the applications which are available in the Ubunut repositories in the Add/Remove dialog. For some of them you have to use either apt-get or synaptic - which both aren't very newbie friendly.

Ubuntu would greatly benefit if there was an installer for multiple programs.

When rebuilding machines, I always need the same programs installed on every machine.

This could be as simple as a massive apt-get script that downloads a defined set of programs.

There are any number of Brainstorm requests for GUI front ends to Ubuntu commands. Why not have a universal command prompter which can be invoked from the command line or from within scripts. Highlighting the command name and then hitting F4 (say) would invoke the prompter.

This could:
1. Provide combo boxes for limited lists of values and also numeric, date, time validation etc.
2. Options (e.g, ls -aisn) could expand to a list of check boxes with the option chatacter and a brief description).
3. Paths could have a file/directory lookup.
4. Provide Accept or Cancel options. The accept option would replace the existing command line string (i.e this is not a command executer).
5. Help option to access manpage from the prompter.
6. To present existing parameter values, the parser used by the prompter would have to be smart enough to extract single commands from piped commands.

Each command could provide a command description/script to drive the prompter.

The IBM System/38 and AS/400 had a similar system 25 years ago.