All,
I have been through the kcontrol settings looking at default setting that could be changed in 3.5.13 to reduce the number of settings that would need to be changed on each new install (at least for me). The idea is to make Trinity better right out-of-the-box.
I know everybody has different 'preferences' and this isn't intended to try and dictate default settings by any stretch, but after numerous installs, it is clear that the current defaults would benefit from a few changes. The goal is the come up with a default set that minimizes the number of changes that the average user would normally make and to give Trinity the good clean default looks and behavior
I have taken the time to create a web page to collect input and give the developers a handy reference to look at the next time they are in the defaults section of the code. Check it out and add your comments here:
http://trinity.pearsoncomputing.net/wiki/bin/view/Specifications/Development...
I've taken a first cut and coming up with foswiki formatting that makes it readable (I'm not sure I succeeded). If you have a better idea for distinguishing kcontrol -> entry -> tab (1,2..) and making it more readable, feel free to have at it.
On Mon, Feb 28, 2011 at 22:30, David C. Rankin drankinatty@suddenlinkmail.com wrote:
All,
I have been through the kcontrol settings looking at default setting that could be changed in 3.5.13 to reduce the number of settings that would need to be changed on each new install (at least for me). The idea is to make Trinity better right out-of-the-box.
I know everybody has different 'preferences' and this isn't intended to try and dictate default settings by any stretch, but after numerous installs, it is clear that the current defaults would benefit from a few changes. The goal is the come up with a default set that minimizes the number of changes that the average user would normally make and to give Trinity the good clean default looks and behavior
I have taken the time to create a web page to collect input and give the developers a handy reference to look at the next time they are in the defaults section of the code. Check it out and add your comments here:
http://trinity.pearsoncomputing.net/wiki/bin/view/Specifications/Development...
I've taken a first cut and coming up with foswiki formatting that makes it readable (I'm not sure I succeeded). If you have a better idea for distinguishing kcontrol -> entry -> tab (1,2..) and making it more readable, feel free to have at it.
Hmm..
I think it's a bit too much right now. We should just aim for 3.5.13 with cmake and udev migrations. Adding new features or changing current ones aren't really a priority. Especially, since we may have to postpone the 3.5.13 release.
On 02/28/2011 09:35 PM, Robert Xu wrote:
Hmm..
I think it's a bit too much right now. We should just aim for 3.5.13 with cmake and udev migrations. Adding new features or changing current ones aren't really a priority. Especially, since we may have to postpone the 3.5.13 release.
Yep,
I agree, not huge priority, but if a quick reference exists, maybe the next time one of the devs is in or around the defaults section of kdebase, etc, they can have a look. Also, putting it up early gives time for everybody to weigh in and add comments.
What's the next module moving to cmake?
On Mon, Feb 28, 2011 at 23:46, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/28/2011 09:35 PM, Robert Xu wrote:
Hmm..
I think it's a bit too much right now. We should just aim for 3.5.13 with cmake and udev migrations. Adding new features or changing current ones aren't really a priority. Especially, since we may have to postpone the 3.5.13 release.
Yep,
I agree, not huge priority, but if a quick reference exists, maybe the next time one of the devs is in or around the defaults section of kdebase, etc, they can have a look. Also, putting it up early gives time for everybody to weigh in and add comments.
What's the next module moving to cmake?
Check with samelian on IRC; he just helped MutantTurkey port another module to cmake.