Re: [Flightgear-devel] canvas non svg-elements broken

[Thorsten R. <tho...@sc...>]

@James:

My aim here is not to argue FG should be backwards-compatible to infinity  
- it's to create an awareness that there's a social aspect to this as well  
which makes things work (or fail). In a nutshell, I believe you can make  
breaking changes if you can convince others that it's for the best of the  
project, and you can harm the project by making breaking changes which  
nobody understands and everyone feels are just enforced by 'the few'.

Let me start by quoting a promise we make in the FGMembers draft:

"The FGAddon repository is actively supported by the core development  
team, with processes in place to ensure the long term health of the  
repository, and compatibility with any changes to the FlightGear core. The  
core FlightGear team have been working on this project for 20 years and  
has a long track record of ensure the long-term health of the aircraft."

I read this as 'Once I place my aircraft into FGAddon, it becomes part of  
the project, and the core team is committed to keeping it working even in  
my absence.' It's one of the main arguments I see why we shouldn't have a  
patchwork of hangars compatible only with special FG versions (or mutually  
incompatible scenery distributions). Any aircraft creator who wants to be  
on FGAddon has to go some extra way because we review content, ask  
questions about copyright, ask for some minimum cleanliness etc. But we  
offer 'active support' as a return.

Now, 'aircraft maintainers should take up half of the work after  
breakages' doesn't exactly sound like that - it sounds like aircraft  
maintainers have a duty to actively support core changes.

Why should people do that (especially if there's an alternative)?

It's a reasonable principle in an all volunteer project that whoever is  
expected to do most of the work gets to make most of the decision.

Now, a model in which the core team (or part of) decides to push into some  
direction which requires others to do lots of fixing work as a result  
violates this principle - people are asked to pick up work for something  
they didn't decide (and possibly don't even understand) - the result is  
reluctance and ultimately resentment.

Volunteers generally don't just appreciate 'I've decided that we do this,  
so here's what you need to do in response' (my wild guess is you wouldn't  
also start coding orbiting AI objects with spacecraft docking capability  
because I've decided that's what we need...).

So if you believe in the above principle, either the change is agreed-upon  
by all (well, most realistically) of those affected, or those affected are  
not expected to share the workload.


> Regarding making changes that affect aircraft, I understandthat from  
> your perspective (and many others), every new thingshould be opt-in.  
> Unfortunately my experience with the knob /lever animation and tooltip  
> system has rather dissuaded me fromsuch projects - despite the system  
> working well, and giving thevery large increase in usability I hoped  
> for, its adoption isbasically zero beyond the C172p

So here's my question - why do you think that is so?

Here's another experience to the opposite - the ALS interior shadow is  
actually fairly complicated to implement for an aircraft maintainer (so  
complicated that I couldn't readily do it myself beyond a demo). Yet  
people have figured out scripts to let blender do the work, put the  
procedure on the Wiki and there's constantly new aircraft being equipped  
with it.

(No, it doesn't always happen like that... the grain map has a very slow  
adoption rate, despite the fact that I think it's simple to implement and  
brings a lot in visuals)

My guess is that for the interior shadow, people understand the benefit of  
their invested work (and I suspect part of this comes from me not only  
maintaining a decent Wiki documentation, but also from me explaining and  
showcasing things in the forum a few dozen times).

So let me put out the hypothesis that people don't opt into the knob  
animation because unlike you they don't understand why it's better (case  
in point, I couldn't actually offhand tell you myself).

I disagree with your tooltip example, because I have seen the tooltip  
feature used in many of the high-quality aircraft to very good effect. The  
same with the checklist feature Stuart implemented. Once people understand  
why something is useful for them, they start implementing it.

Also, I think the lesson is that giving people a decision might actually  
mean they might not decide how you (or I) would. Some features I think  
very promising just never passed the test of convincing others (my tree  
optimization shader comes to mind).


> Whenever I ask for guidance here on making core changes, the  
> recommendation is invariably ‘try it and see what breaks’, and of course  
> fix it if things do break. I’m trying to follow that rule but your  
> comments make me think it’s causing a lot of harm in the aircraft  
> development community and user-base, but unfortunately not in a way  
> people are communicating to me here. The original issue with the Canvas  
> SVG API being a case in point.

I think the key word is *here* - I don't have the impression most aircraft  
developers read the devel list, and if you would ask in the forum (or even  
various sub-community forums like FGUK) you'd get different feedback.

It feels sometimes like in a split personality - for instance on this list  
the Qt launcher is the way to start FG, in the forum FGRun is the way to  
do it.



> All this leaves me wondering if I’m doing more harm than good if I  
> attempt such changes - for example while most people seem to agree PUI  
> needs to be replaced, it sounds as if the fallout from doing so would be  
> more painful (cumulatively) than the pain its existence causes.

I suppose the problem is that the pain its existence causes is to  
different people than the pain its replacement causes. Which one is  
greater I do not know, but personally, given that with many graphics  
drivers PUI doesn't render correctly when higher shader quality is on, I'm  
also convinced it needs to be replaced.

I can only repeat an earlier suggestion here - minimize the overall pain.


* pui2canvas.nas is a viable replacement - once finished, it will render  
every existing dialog, not pretty but working - 95% of the pain for  
maintainers is gone because no immediate action is required, everything  
still works, PUI can go


* then offer Qt-based widgets as an optional way forward and demonstrate  
how much nicer dialogs can be. Make people understand what goodies they  
get for their trouble, and you'll see them invest their time to make it  
nice. Break their existing dialogs and tell them they have to use the new  
stuff, and you'll get complaints.


@Stuart:

> Perhaps we could increase this window by trying to make changes such that
> the old behaviour is deprecated, before being removed after a notified  
> period, say 12 months?

I think there's no one size fits all procedure, but if there's a good case  
that something needs to go (as for instance Torsten made with the SVN TS  
repo which apparently causes lots of workload) then announcing a 12 months  
window is both fair and reasonable.

Admittedly I don't see in all cases why the old behavior needs to be  
removed at all - perhaps that ought to be communicated better (or just not  
done).


@Gene

> I look at it this way - the current path has FlightGearin the same boat  
> as Microsoft Windows - supporting crap that's upto 20+ years old

It's actually Linux which happily interacts with my ancient digicam  
whereas Windows has long given up supporting it, and it's one of the  
reasons why I really like Linux.


> I would suggest that if you're going to make changes that are  
> "breaking", go all out - don't break a few little tiny things.  Grab  
> some of Grandma's fine china and have at.

Given the fork we've seen, that's probably the most irresponsible  
statement I've read in a while.

In that model of yours, aircraft maintainers just have to 'suck it up'.  
Well - what if they do not? When reviewing the Saab Viggen, I've come  
across the statement that it cost ~2000 working hours. If it gets broken,  
the project loses that. Who is going to replace it? You? I think not.

What happens if aircraft maintainers decide they're not the little coding  
monkeys cleaning up after every breakage someone else decides for them?  
What if there's suddenly a fork on which all aircraft still work (but  
remote canvas does not) and maintainers commit to ensure compatibility   
and in addition terrain is better etc? Where do you think future  
development will chiefly happen?

There's commercial projects which have been tanked by trying to 'break it  
all and do everything from scratch, just more cleanly' - and that's with  
paid coders who have to do what they're told. There's just no reason  
whatsoever this ought to work with a volunteer community.

FG works because there's a community - both people preparing the platform  
and people caring for the aircraft which use it. I think it moves forward  
better if they move together and people understand where the journey goes  
and why it is good for everyone, not if one part moves and expects the  
other to follow.

Whew - long mail...

Best,

* Thorsten