Ok so we've got the red and blue to identify the two proteins. But when you compare the image with the sidechains and the accepted image (with no sidechains) it is not always clear how they relate.

Would it be possible to add a button to the graphic to allow you to turn off the viewing of the sidechains?

Or perhaps show the sidechains in a different shade (or perhaps slightly transparent) of blue and red so the backbone is more clearly related to the accepted image?

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Is this the kind of image you are talking about?



I thought this was really messy and hard to follow.

---

Well, yes, it seems they were trying to make it black and white as to which protein was which. But once you twist the image around a little (left click and hold on the image, then drag to spin it around) I found it hard to orient the next image box in a way to align with the first. The main problem is that the first image has become so "busy" that it's hard to decern the backbone in it.

That's why I thought translucent sidechains would be pretty cool. Then it would still be clear which protein is which, and yet the backbone will be more clearly visible in that first image box.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Transparent sidechains are ok, but please no button.

Agreed the default graphics should not be cluttered with buttons etc.

Use of the Screensaver prefrences should used if this wish to add more complicated features so 'power users' can enable features like no side chains or buttons etc. If they want. Don't forget the main part of the graphics is as a ScreenSaver/Something pretty to look and an see an overview of what is happening.

---

Team mauisun.org

Agreed the default graphics should not be cluttered with buttons etc.

Use of the Screensaver prefrences should used if this wish to add more complicated features so 'power users' can enable features like no side chains or buttons etc. If they want. Don't forget the main part of the graphics is as a ScreenSaver/Something pretty to look and an see an overview of what is happening.

In my view it is time to consider whether the screensaver should be the same graphic as that displayed on demand from the manager.

A screensaver should be pretty but use very little code. Most of the time it will be running it will not be being looked at, and if it uses a lot of crunch time that will only hurt the project. It should not need user input because that conflicts with the fact that user input is supposed to interrupt the s/s completely and drop the user back into Word or whatever. A s/s should not use much memory either, as this makes it all the more likely that the user will experience a page-fault delay when they want to get back to Word.

In contrast, when the user is hands-on, they want to look inside the model, see what it is doing now, rotate the protein, etc etc, all of which takes a fair amount of cpu time and all of which are much more entertaining if interactive and all of which typically gobble up more memory than the actual crunching.

And a user who has being doing that will be less likely to even notice if there is a page file delay afterwards.

There would be two ways to engineer this, depending whter BOINC or a project takes it up first.

If BOINC then a future release of BOINC should be able to cope with there being different programs loaded as the s/s and as the "show graphics" response. Projects which still offer the same would simply provide the same program in both cases.

If a project then the graphics part of the app should iteself have a test for "am I a s/s" early in the code and before the big chunky stuff is loaded.

As a concession to those liking interactive s/s, there could be a cross-project standard that (say) ctrl-G during the s/s switched into advanced graphics mode. Perhaps this could even be the only key/mouse stroke responded to while acting as a s/s.

After the usual s/s delay, the advanced graphics would lapse back to s/s mode, speeding up the crunching.

Just an idea for the future - clearly this is not on the urgent list but I do suggest it is worth thinking about in the longer term. I wonder how many decoys go uncrunched, how many et's fail to phone home, how long Einstein goes without waves in his gravy, and so on while the s/s is playing to an absent user?

River~~

---

Agreed the default graphics should not be cluttered with buttons etc.

Use of the Screensaver prefrences should used if this wish to add more complicated features so 'power users' can enable features like no side chains or buttons etc. If they want. Don't forget the main part of the graphics is as a ScreenSaver/Something pretty to look and an see an overview of what is happening.

In my view it is time to consider whether the screensaver should be the same graphic as that displayed on demand from the manager.

A screensaver should be pretty but use very little code. Most of the time it will be running it will not be being looked at, and if it uses a lot of crunch time that will only hurt the project. It should not need user input because that conflicts with the fact that user input is supposed to interrupt the s/s completely and drop the user back into Word or whatever. A s/s should not use much memory either, as this makes it all the more likely that the user will experience a page-fault delay when they want to get back to Word.

In contrast, when the user is hands-on, they want to look inside the model, see what it is doing now, rotate the protein, etc etc, all of which takes a fair amount of cpu time and all of which are much more entertaining if interactive and all of which typically gobble up more memory than the actual crunching.

And a user who has being doing that will be less likely to even notice if there is a page file delay afterwards.

There would be two ways to engineer this, depending whter BOINC or a project takes it up first.

If BOINC then a future release of BOINC should be able to cope with there being different programs loaded as the s/s and as the "show graphics" response. Projects which still offer the same would simply provide the same program in both cases.

If a project then the graphics part of the app should iteself have a test for "am I a s/s" early in the code and before the big chunky stuff is loaded.

As a concession to those liking interactive s/s, there could be a cross-project standard that (say) ctrl-G during the s/s switched into advanced graphics mode. Perhaps this could even be the only key/mouse stroke responded to while acting as a s/s.

After the usual s/s delay, the advanced graphics would lapse back to s/s mode, speeding up the crunching.

Just an idea for the future - clearly this is not on the urgent list but I do suggest it is worth thinking about in the longer term. I wonder how many decoys go uncrunched, how many et's fail to phone home, how long Einstein goes without waves in his gravy, and so on while the s/s is playing to an absent user?

River~~

Maybe we should use the feedback area in the Ralph forums to list the ideas, so we don't forget them. I'm not saying debate and talk (but hey we still can) just use it to list some ideas. Since things get lost in the Rosetta forum quickly as they've still not implemented the proposed forum changes like at Ralph and the feedback is not used much over there (it is only there to test the idea of having a seperate one out, each test has it's own thread elsewhere).

---

Team mauisun.org

...

In my view it is time to consider whether the screensaver should be the same graphic as that displayed on demand from the manager....

Maybe we should use the feedback area in the Ralph forums to list the ideas, so we don't forget them. ...

I've now made a very similar posting on Ralph, Einstein, and SETI, each in a new thread with the title Suggestion: separate gfx for s/s and manager.

R~~