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

[James T. <zak...@ma...>]

> On 22 Jan 2017, at 07:51, Thorsten Renk <tho...@sc...> wrote:
> 
> I hope to keep things more constructive than that at least... I really  
> don't want to argue to end all development or be against changes which  
> break something in general. As I said, I believe in a cost-beneift  
> analysis, and if you can communicate the benefit of a breaking change to  
> the people who are supposed to help implement it, I believe they will  
> support you (more readily than if you break their work and expect them to  
> fix it).
> 
> As I said, unless keeping the 'old' parsing to properties in the code is  
> somehow a great pain, what I would like to see is the parsing to string  
> offered as a new option, and explained on the wiki what it does  
> differently and when it is superior. Add it to the newsletter, make people  
> aware. Yeah, you won't change all aircraft in a short time - but it's safe.
> 
> We're not arguing whether your implementation is a good idea - I  
> unconditionally think it is - we're arguing about the migration path and  
> how conservative that ought to be.
> 
> Please take a step back and read mailing list subject lines for the last  
> months - I've never seen so many 'doesn't compile' and 'segfaults' and  
> 'windows broken' in such a short time period. Please skim through the  
> forum reading posts by jharris1993 who's pretty enthusiastic about FG and  
> been trying to install the software in various ways after a long break,  
> starting from here
> 
> https://forum.flightgear.org/viewtopic.php?f=22&t=31228&p=301170#p301170
> 
> and got a lot of frustration for his trouble.
> 
> Please skim forum subjects - I might be glorifying the past, but I recall  
> being breakage and bug reports a minority of everything that was posted -  
> these days they seem to be at least half. Just not so long ago, you can  
> read a rant how to compile FG on Windows gets more and more miserable.  
> There's the SQLite breakage reports coming in weekly. (I might add that  
> I'm also rather thoroughly frustrated at the moment, to the point that I  
> contemplated creating my own fork just to have a stable development  
> environment and let whoever wants to cherry-pick ALS updates - or not).
> 
> Perhaps a little more conservative strategy for introducing changes would  
> not be a huge mistake right now...

There’s quite a bit to take in, in all that, so apologies for the delay in responding.

Starting with the last part, about stability or breakage of the simulator, my impression is that this is mostly on ‘next’, which is explicitly unstable. If we are to have core development, such as Erik’s SIMD work, or the recent toolchain update on Windows, some breakage is unfortunately part of the process, and people reporting and testing that is another part. It would be a different story with the stable branch of course. I do try to follow up every email here, and also bug report people mention, but it’s a lot to keep track of, and I do also skim the forums, but that adds even more places to track. I don’t read every single forum post but I try to check in once or twice a week and look for relevant topics. Often when I post questions there is no answer or follow-up which is unfortunate, but that is life.

Something like the SQL corruption issue, I am perplexed by, because I saw one report (which you referenced by email), made some code changes, and asked for feedback - both here and on the forum. I’ve received exactly zero emails and messages about it since, so I’m unsure how to proceed - we can only fix things where people provide reports and information. It is the number one bug I would like to fix, but no one is giving me anything to work with, so I am stuck.

I also read the forum post from jharris you mentioned, but I must admit I don’t really understand it, though I will return to it and see if I can assemble the complete narrative. Again if people have issues they aren't presenting them here or to me, so it’s tough to purse them and get things fixed. I would like to help but I need some starting point.

Regarding making changes that affect aircraft, I understand that from your perspective (and many others), every new thing should be opt-in. Unfortunately my experience with the knob / lever animation and tooltip system has rather dissuaded me from such projects - despite the system working well, and giving the very large increase in usability I hoped for, its adoption is basically zero beyond the C172p - which is very demotivating. Of course the system might need improvements and tweaks to work in more aircraft, so what I expected after I published it was a beta-cycle where some aircraft adopted it, people emailed me feedback & comments, and the system matured to become ubiquitous. Indeed I hoped that by now virtually every aircraft would be using it. The same is true for the package meta-data which most aircraft still lack.

Since that didn’t work out very well, I am unfortunately not convinced about getting changes made on such features in a majority of aircraft within a reasonable time-frame (for example, two or three years). I am going to try a different approach to getting more aircraft meta-data contributions once some other changes land, but these are areas I hoped the technical benefit would be sufficient to bring about widespread adoption without further effort.

if I look at the three or four major things I’m current working on - they could all negatively impact some aircraft. (For example migrating 2D panels to use the Canvas, or replacing PUI) I do not wish to cause rifts in the aircraft developer community, but it seems unlikely I can possibly replace the panels or PUI without breaking some obscure aircraft dialogs. So I’m kind of at a loss how to proceed - there isn’t a nice architectural split inside the codebase between things that do and don’t affect aircraft.

(There’s a particular problem that one thing I really would like to work on, improving the frame-rate and modernised 3D rendering, I can’t work on until the PUI code, 2D panels and Shiva are removed, but doing so is a frustrating slow path)

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.

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.

It is quite tough to consider these things, given the amount of effort I’ve invested in them. But obviously it’s most important that people feel able to use and contribute to the project, far more so that whether a particular feature gets implemented or not.

James