It sounds like Ageless's suggestion explains your problem perfectly - Boinc is taking it's font settings from one interface, and you're changing the font settings in another interface. There are many different user interfaces in Linux, and they're all slightly incompatible with each other.

I asked Rom about the font, he doesn't know.
But what is making Boinc Manager ugly in itself is X.

Berkeley has tried for the past couple of years to fight that Linux is using all kinds of interfaces for the X window. Since there's no X that will work across different distros, it is very hard for them to make a Manager that looks nice.

And now they have given up and opted for compatibility, not looks.

Sorry.

Edit: I just managed to change the look of Boinc Manager by adjusting the font size that my Linux is using.

I'm using Mepis, based partially on Ubuntu.
I went to my Mepis X Windows Assistant, General, Set relative size of text to 75dpi, Applied and restarted X (CTRL+ALT+Backspace).

BOINC Manager looks a whole lot nicer now!

BOINC Manager Linux should use desktop themes. It looks really awful, the fonts are badly aliased, dull grey GUI components. It looks like from an old windows toolkit.

v5.8.16 changes its look with the current GNOME desktop theme. I guess they added it. :)

"Force" Task.

Equivalent to "Resume" suspended tasks, tasks in state "Waiting to run" should be able to be "forced" to continue. Reason: almost finished work units can be finished faster when the user tells.

Wrong. They will crunch at the same speed, not faster. I think you mean sooner. When you think about it, if task A finishes sooner then task B has to wait until later. Over the long run the work gets returned at the same rate. The only purpose it serves is to reduce the number of waiting tasks on the list. Does that serve any useful purpose? Is there any real need for it? None whatsoever. You can avoid having to look at all those messy unfinished tasks cluttering up your list of tasks by simply going out for a nice long walk. If the tasks get returned before the deadline then that's soon enough. If that is not soon enough then the projects have the option of shortening the deadline.

My workaround so far: suspending all other running tasks until the specific task continues - and when it's finished resuming the suspended tasks. But this requires the user to resume the other tasks. A single function "Force" would do this without any further intervention.

Your workaround serves no purpose. It's not a workaround, it's just a make work project to solve a problem that does not exist. To automate the needless work you're doing would be a bad waste of some programmer's valuable time.

1. Progress of the scheduled time (e.g. if each of the tasks can calculate for 1 hour, the progress should start at 0% on each task switch end end with 100% when the hour is over (and the task gets to "Waitung to run").

As a separate column or replacing the current progress bar? I think if it replaced the current progress bar it would be extremely confusing. End users may think that the task is continuely restarting.

Is possible to get project switching delay when project running is over 99% complete AND less than 10 minutes to completion.

Fed up of present situation where I have: 02:49:38 | 99.468% | 00:00:47 | Waiting to run.

Or more advanced version: a possibility to mark (e.g. per RPC) few single WUs to be prioritized for crunching (unless some other project/WU have deadline miss).

This would mean adding priority property to each WU (or result). Currently all WUs sort of share the same priority, WUs with deadline miss can be considered as having higher priority.

Peter