kicad-developers team mailing list archive
Mailing list archive
Re: About quality of discussion
Wayne Stambaugh <stambaughw@...>
Fri, 06 Feb 2009 16:36:30 -0500
Thunderbird 18.104.22.168 (Windows/20081209)
Dick Hollenbeck wrote:
> Among people, it is not unusual to disagree. Just ask my wife. When
> that happens a discussion can ensue. This has happened. Those with
> the largest investment in the project tend to get the most respect and
> I find the list quite respectful in that regard. Wayne, Jean-Pierre
> and I all agreed there would be a temporary solution for this release
> followed by a long term solution which pushes the scaling down into wxDC.
> The ensuing discussion about the temporary solution has gone beyond
> practical now.
> As a person contributes more, the amount of respect and consideration
> that a person should expect here will escalate. Realize this is not a
> democracy, nor is any open source project. Most use limited write
> access to the repository to maintain control. It is my theory that
> Linus is in control of linux only because he controls his tree, and that
> his tree is recognized as the authentic linux source. It would be a
> mistake to think this is a democracy.
> But folks do listen to input.
> Until you contribute more than 10 lines of code, please don't feel that
> your (dare I say) "vote" is equal to those having spent years
> contributing. I think you may have detected that Jean-Pierre is well
> respected here, and that supports what I am saying about respect being a
> weighting factor on opinions offered.
> If after the release, you want to take up and be involved in the design
> of a permanent solution to the zoom issue, then you are welcomed. But
> realize that people will disagree, and there needs to be a way to
> resolve those disagreements. On this list it is respect for those with
> greater ownership in the code.
> If and when that stops working, then something else may have to replace
> it. For now, it is working reasonably well as a resolution to
Eloquently stated Dick and I concur.
I was only attempting to create a more flexible zoom system to allow for
non integer zoom levels. I have since figured out why the "jumping"
occurs. Because Kicad calculates all of it's scaling outside of
wxWidgets, the scroll bars don't have any idea of scaling in Kicad so
they always move the scalar size which is currently 10 pixels.
Actually, depending on the integer truncation when adjusting the
scrollbars it could end up being 20 pixels but I already fixed this and
will commit it after I take a look at a few other minor issues. The
pixels per unit had to be set to 10 so that CalcSrolledPosition and
CalcUnscrolledPosition function correctly. What you are seeing is the
scrollbar increment of 10 pixels. I haven't figured out a way to
prevent this from happening. One simple solution would be to reduce the
zoom scalar thus reducing the scroll step size. A zoom scalar size of 2
or 3 would make the jumping barely perceptible ( 2 or 3 pixels ) but you
would loose some finer zoom settings.
I hacked one of the wxPython drawing samples to zoom around the cursor
position and it scrolls and zooms without any having to manipulate
anything but the user scale and the logical origin. This is why I want
to push as much of Kicad's drawing code pushed down into wxWidgets as
possible. This is also the reason I didn't try to make the new zoom
implementation a perfect solution. wxWidgets appears to handle this
better internally than Kicad does. One thing for sure, I have learned
way more about how wxWidgets works than I really wanted to know.
Although, that is the beauty of having the source code. There are no
excuses for not understanding how something works.
I believe this is the last time I am going to comment on this subject.
>> /* RANT
>> Past few days show a rather interesting phenomena on the list.
>> First there is no discussion what so ever about new zoom factor even
>> though the code was there a good time before. I go rummaging code around
>> for a while as the lack of feature busg me. Codebase quite unknown to me
>> ans not too much skills doing C++ brings nothing, but urge to ask.
>> I go and ask for adding intermediates with 1.5 factor to existing ones,
>> but realize soon that alternating 1.5 and 1.33 (15/10 and 20/15) makes a
>> jumpy zoom.
>> I go and device a way to get non jumpy zoom _and_ using existing factors
>> to make people used to them happy, but implementation has a bit too much
>> granularity that is easily corrected. The working solution is presented
>> and some background (theory) explained.
>> Other, almost as good solution is presented. It scraps the old factors as
>> we are "coming from" there, so no need to preserve them. No other
>> reasoning why. Good pushing that tries to prove all reasoning for the
>> other solution redundant and unneeded. No facts, just feelings.
>> More through reasoning towars a general solution. Just because it was
>> somewhat fun to present examples from other fields of use.
>> The almost as good solution gets pushed without any real discussion, with
>> 'Just because I say so' attitude.
>> Some very general comments here and there aroud the subject.
>> Finally the _first_, hastily proposed system gets pushed forward, because
>> there is nothing better yet. As if there isn't...
>> What's the ROI (return of investment)? Everyone will have to calculate
>> that oneself. But costs were at least some bad publicity, bad discussion
>> that turned to a case of prestige without any factual arguments, wasted
>> bytes and some bad mood, verb for that particular is 'vituttaa' in
>> finnish. Oh, and everyone ends patching ones own compile and distro users
>> think it's just bad.
>> What we got as return? Jumping zoom.
>> END RANT */
>> The above may be part of the reasons some have said (in personal mail)
>> that they rather not discuss on kicad-devel or take any other activity
>> regarding Kicad.
>> Look on the bright side, I'm not that easy to scare off.
>> Yahoo! Groups Links
> Yahoo! Groups Links