+1 to Greg's points. The use case of low-end systems seems hypothetical. Thus far, we've prioritized features based on real-world use cases as pointed out by our users (either on the user list or ourselves in building real Pivot apps), and I haven't heard any users complaining about the gradients or transitions. When coupled with this being a very de-stabilizing change, it makes me think that we should wait until we build a new theme to think about this functionality. Thus, I vote to push this feature to 2.0.
-T On Thu, Oct 1, 2009 at 10:40 AM, Greg Brown <[email protected]> wrote: > To me, this sounds a bit too comprehensive for Pivot 1.x. It would touch a > lot of code that currently works very well, and I'm not sure that there is a > strong enough use case to justify the risk of introducing bugs into that > code. Is poor graphics hardware really a concern for our target users? Even > if it is, have we actually verified that Pivot runs poorly on such hardware? > > The question in my mind is - why might we want to invest time in this, as > opposed to some of the other issues we have on our to-do list? Personally, I > see a lot of other features on the road map that would offer a lot more > value to me than this. I could see potentially considering something like > this for Pivot 2.0, when we start building out the new theme classes, but it > seems like a very low priority item right now. > > Honestly, I don't think we should consider taking any action on this item > until we learn more about how our users are using Pivot, and what their pain > points are. If this isn't one of them, we definitely shouldn't spend any > time on it. If it is, then we can discuss whether this is the right solution > or if another approach would be better (maybe for Pivot 2.0, when we start > working on the new theme classes). > > G > > On Thursday, October 01, 2009, at 10:12AM, "Sandro Martini" < > [email protected]> wrote: > >Ok, I'll try to explain the idea in short terms (some point is already > >explained in the JIRA ticket): > > > >The default behavior will be full effects ON, like currently. > > > >This proposal is to disable groups of effects by switching them OFF, > >depending on what is (not) wanted. > >We have to see if providing an enum with some common levels (like ALL, > >MEDIUM, LOW, NONE) but in this case we have to see in what category an > >effect is ... but this is a detail. > > > >The main use case for this is to exclude unwanted graphics effects, to > >speedup execution of Pivot Applications / Applets, think for example > >at Corporate (Intranet) Applications where usually the Graphics aspect > >if less relevant, and usually there are many PCs (old, or at least > >some year old) with not-so-good Graphics Boards ... like many Intel > >boards, or with poor drivers. > >GNome desktop has a feature like this, in the Graphic Configuration, > >but this is based on the Graphics Board hardware functions ... > > > >So, if i could let developers customize (by code and/or in wtkx files) > >what effects exclude (and maybe disable and re-enable later) to > >speedup all. > > > >With "effects" here I'm thinking on: > >- media > >- transitions > >- transparencies > >- gradients > >- backgrounds > >- watermarks > >- drawings > >- maybe others ... like background colors, custom styles, etc ... > > > > > >So a refactoring of some parts of graphics generation code should be > >done (and this could be useful, in any case) in common methods, and > >see if make if statements there to see if not process the code to > >draw, ok ? > > > >As a first example, I'd like to try with the gradients part ... > >probably on modern PC with good Graphics Boards the speedup is > >minimal, but i think this is another useful feature to have. > > > >Or for example think on transitions: if i don't want them, i could > >disable all them (skipping the related code in new common methods, > >depending on the related flag), so users doesn't have to wait for > >transitions to complete (also if is can set their duration as little > >as possible, ok). > > > > > >Comments ? > > > >Bye, > >Sandro > > > > >
