I'm very confused in the way that a really bad coordination drives us to such unconfortables situations. As a programming illiterate, I feel we are heading to a galaxy complex problem back in the time.As a user I suggest to read fgbugtracker [url]#771 https://code.google.com/p/flightgear-bu ... tone%20%20[/url] Request if maybe you find interesting.As FGFriend I encourage you to find best agreements/decitions in order to accomplish this task.

Well, the main issue here is that different people have different ideas about how to accomplish certain goals, as well as varying degree of influence:

All of us have different backgrounds and skills to bring to the table. And in FlightGear very often, people tend to be interested in similar things at different times - usually, people are only able to express ideas/feature requests. The whole GUI debate is at least 5-8 years old, so it's a long-standing issue.

For instance, back when Canvas was discussed/prototyped, Torsten wasn't around - equally, there's now talks taking place behind the scenes about replacing the Mac launcher with an integrated Qt5-based launcher. Obviously, this is heavily overlapping with anything involving Canvas, but also GUI work in general (including Torsten's effort).

A few years ago, Qt5 wasn't considered an acceptable dependency to add to FlightGear - meanwhile, the most active core developer (Zakalawe) is intimately familiar with Qt5, and can simply add optional dependencies without necessarily having to announce these things on the devel list up-front. Equally, Torsten's work wasn't announced up-front. So people tend to announce developments "after the fact".And with Torsten and Zakalawe, there are two fairly active and influential core developers working on heavily related features, who are generally not shy about either veto'ing new changes, or about simply being very bold when it comes to adding stuff that they developed, or that they at least take an interest in.

What would generally happen under these circumstances is that competing/conflicting efforts would be "killed off" by the lack of support (i.e. being silent, and not being willing to commit related changes-i.e. external contributors not being able to find a core developer to review/commit their changes). In this case however, there are three people involved who already happen to have commit access, so that all three solutions will probably co-exist for quite some time come.

Normally, the degree of manpower available determines what gets implemented in FlightGear - but these days, someone /not/ being around may have just as much influence under certain circumstances, i.e. naysayers veto'ing stuff that they didn't develop themselves.

All of this can take place because -unlike external contributors- core developers are not required to have their commits peer-reviewed, let alone their developments discussed/announced up-front. While some are trying to establish best practices by sharing todo lists on the wiki or by using the issue tracker, many simply don't.

This also is how we arrived at having roughly 20 different GUI launchers for FlightGear, all developed by different people with basically no collaboation/coordination taking place, so this isn't inherent to core development, but it is heavily influenced by core developers responses to such developments (as can be seen by the reset/re-init and AircraftCenter efforts).

Given Torsten's role in the project, and the fact that Curt seems fully supportive of this work (especially in the light of finally having an instructor station for FlightGear), the mongoose/httpd GUI is going to stay around no matter what.

Equally, Canvas is going to remain available for the obvious reason that Canvas is not specific to a single use-case like a GUI or an instructor console.

While it would be possible for Canvas/FGCanvas to satisfy similar use-cases as the mongoose work, there are certain deployment benefits for a platform using html5/ECMAScript.However, Canvas is also going to stay because it can deal with MFDs and other avionics, and because it helps us unify the 2D rendering back-end - none of which are strengths of the mongoose work, which is why it should be considered an alternative, not a replacement.This is supported by Torsten mentioning that he manually ported existing XML dialogs - which obviously doesn't scale in the long-term, especially not if he should have to take a hiatus from FG.

So what is likely going to happen over time is that Torsten's work is going to be most complete from a functionality standpoint, and frankly superior to anything integrated in FG - simply because he can leverage a ton of resources that are unavailable to Canvas - i.e. tons of JavaScript/HTML5 libs for creating a nice UI quickly.

While that would also apply to Qt5, Qt5 has been added as an optional dependency for now - and it isn't clear if other core developers would accept it as a dependency for all platforms, because it's a rather significant dependency - equally, Qt5 brings a ton of awesome APIs with it, that would frankly make FlightGear obsolete in many parts (think I/O, networking, GUI, multi-threading etc). In other words, officially accepting Qt5 into FlightGear wouldn't be unlike piggybacking a Ferrari onto a VW Beetle - so is unlikely to happen for technical reasons.

Canvas will undoubtedly continue to evolve in parallel - even though some momentum may vanish over time given Torsten's progress - that is, unless people arrive at the conclusion that they want to support use-cases that are not easily/efficiently supported by using the HTML5/JavaScript approach (such as rendering MFDs or OSG camera views). For that, Canvas still is -and remains- the best option.

At some point, our UIs will undoubtedly start to diverge rather significantly: Canvas is already much powerful than PUI - however, it isn't yet as feature-rich from a widget standpoint, so we still need to port roughly 15-20 widgets before we can phase out PUI. Equally, the mongoose GUI Torsten is working on can trivially be more powerful than anything we could come up with in FlightGear - simply because, in FlightGear, we tend to re-invent the wheel - while the mongoose UI can simply use existing libraries/UI toolkits (think a tree view for a property browser), whereas we would have to code a tree view in Nasal/Canvas first (which isn't rocket science, but will undoubtedly take way longer than Torsten taking an existing widget and exposing a few more properties/fgcommands).

So our UIs will increasingly start to differ a lot - even just for the simple reason that many of our contributors/aircraft developers are familiar with helping maintain the existing PUI XML GUI (think Thorsten's Advanced Weather/ALS systems), but may very well not be overly interested in manually having to maintain parity with a plethora of 3rd party UI solutions. Which is exactly the reason why manually porting UI dialogs is fragile and tedious in the long-term, which is also why we came to the conclusion NOT to do that in the context of Canvas, but instead write a parser that would map PUI widgets to Canvas widgets, so that there's no manual rewriting/maintenance involved.

However, manpower on the Canvas front is undoubtedly going to be affected/decreased by Torsten's work - even if that just means that people working on similar projects will step back given Torsten's influence (think F-JJTH's integrated Canvas UI effort).

Overall, the increasing interest in addressing the FlightGear GUI debacle is a good thing for FlightGear, but HOW this is happening, is kinda symptomatic of the way how FlightGear lacks any degree of proper coordination/collaboration scheme, which is magnified by people working on overlapping/conflicting features and being in similarly influential positions.

The mongoose/httpd work is a good thing for FlightGear to happen for a number of other reasons, i.e. it helps provide a UI that doesn't depend on Nasal scripting (or Canvas), so it should provide a good baseline for related benchmarks - because the main loop can be significantly cleaned up. Equally, this would be a viable solution for FGViewer, which should also get by without Nasal - i.e .by having a fully async UI, without any significant mainloop overhead.

The new built-in Qt5 launcher is different thing - and it will be interesting to see how this evolves.FlightGear arrived at things like Nasal (and even Canvas), because FlightGear tends to attract "tinkerers" who enjoy developing/re-inventing stuff from scratch.For many years, certain core developers were very outspoken against adding new dependencies - so that FlightGear is not a particularly modern code base and tends to contain lots of "niche" solutions.

This has been changing during the last couple of years, and under different circumstances, accepting Qt5 could very well make the Canvas/Mongoose work entirely obsolete, especially if backed by a long-time core developer. But given that James and Stuart are basically the only core developers to regularly re-evaluate their own contributions and publicly express a willingness to refactor/phase out their own contributions in the light of more recent developments, it is also possible that the Qt5 launcher is going to remain a temporary solution.

However, some of the APIs exposed there are already overlapping with Canvas functionality.So the main contenders seem to be Canvas vs. Mongoose for now, because Torsten also started working on MFDs - which is heavily overlapping with Gijs' work (navdisplay/pfd).For the time being, it isn't foreseeable that there'll be any conscious effort to "join" those efforts by creating a common platform using a subset of JavaScript/Nasal for animating SVG-based instruments.So what's going to happen is that mongoose will likely make fgpanel obsolete. While Canvas will make PUI obsolete over time.

For Torsten's work to literally conflict with the Canvas GUI effort, he would have to find a consensus among core developers to accept WebKit as a dependency into FlightGear (which is available as an OSG plugin), i.e. so that the mongoose GUI would also work as an integrated UI. Equally, rendering internal cameras (MFDs, instruments or scenery) is going to be challenging for anything external, unless you only want to display a "stream".

So yeah, there's /some/ competition in the house - but it's not a bad thing per se, and it also isn't uncommon for FlightGear to have a bunch of incompatible/mutually-exclusive features (think FDMs, scripting solutions, systems modelling blocks, weather systems etc), with different people believing in different approaches.

We're seeing this also heavily in many Nasal/Canvas efforts only supporting a single instrument/aircraft or use-case (c.f. Avidyne Entegra R9) - collaboration is an art, and it is much more difficult in a volunteer-based project where you cannot tell people what to do. Any degree of cooperation we've been able to apply in the context of Canvas was mainly by "mentoring" people, and by documenting best-practices through tutorials on the wiki - but there's still lots of overlapping stuff happening all over the place - no matter if it's fgfs core or fgdata development, the UI issue is just fairly prominent currently because of all the momentum it is gaining.

And with core developers not having to use merge-requests or just peer-review their own contributions, it is fairly easy to arrive at situations like these.

Just for the sake of completeness and to avoid misunderstanding:There is a lot of coordination and communication going on between most "core developers".Just a little bit of this is visible as we sometimes meet face-to-face and much more often voice or video-chat.The parallel development of HTML and Qt based UI happens by intention and is not the result of missing coordination.

Torsten wrote in Sat Jan 10, 2015 12:03 pm:The parallel development of HTML and Qt based UI happens by intention and is not the result of missing coordination.

Great if that's the case and if there really is a holistic plan in place to take overlapping efforts into account, but you may still want to share the consensus/roadmap you've arrived at given that these overlapping developments are creating quite some confusion among people interested in contributing to related efforts, especially given that you're inviting people to contribute to your mongoose/GUI work, too. As can be seen by Michat's message: There are probably quite a few people familiar with both, JavaScript/HTML and Nasal/Canvas (or even just Inkscape) - who are feeling "out of the loop" despite their involvement in related efforts (for instance, Michat literally spent hours creating SVG artwork to be used by FlightGear).

Equally, I am quite aware of just how powerful Qt is, and that it can just as well deal with HTML5/JavaScript (which is why I hinted at supporting the HTML5 GUI directly inside FG) - but even if that should be part of your "coordination", it would still be overlapping with many things related to Canvas, which some of us have been quite heavily involved in - also including literally hundreds of "behind-the-scenes" discussions on how to proceed with related/overlapping things.

If you're serious about finding more contributors wanting to help with the mongoose/Qt5 efforts, but don' feel comfortable announcing things on the devel list, I'd suggest to share your plans via the wiki - which is what Zakalawe and Stuart have been doing for quite a few years, and it's helped avoid redundant efforts in the past. In fact, Canvas is quite "public" on the wiki - including most devel/roadmap related discussion.

In summary, please don't expect people to join a new effort just because it is obviously cool - even as non core developers, people want to ensure that there time spent contributing isn't wasted - and if there's a clear direction with regards on how the HTML5 and Qt5 GUIs are intended to evolve, better share it or be prepared that there'll be even more conflicting efforts down the line (for instance, I am aware of one developer working on a HLA based remote control for fgviewer, which would be overlapping with an instructor console -even according to Mathias' public comments on the devel list).

Thank you very much for the "constructive" response, but I think you misunderstand: The point was that certain developments tend to be discussed up-front, while others tend to be RFCs on the wiki for a while before they get prototyped/implemented - in this case however (mongoose/Qt5), it is obvious that "announcements" took place well "after the fact" (i.e. commit).

Torsten wrote:We have a long tradition of discussing major structural changes like this one one the mailing list. I can't find any evidence of this in the archives. Unless this patch gets reviewed by and unless there is a consense among the core developers, I strongly object against applying it.

Torsten

You clearly stated that there's coordination taking place behind the scenes which isn't necessarily "visible" - however, there's a whole number of contributors involved in related efforts who've made sure that their work is indeed very visible. Thus, any core developments overlapping/conflicting with such contributions should ideally be sorted sooner than later, or we're -once again- alienating even more contributors by deprecating contributions through changes that were never discussed with people who've been working on related features, for months (or even years).

Given the influence -and veto power- that core developers, like yourself and Zakalawe have, it makes absolutely sense to state what your intentions are - or people are going to feel lost at some point.In the context of FlightGear and core development, this very often meant that people would continue working on inferior solutions using fgdata space workarounds due to lack of consensus among core developers (e.g. think autopilots/route-manager/FDM/weather functionality entirely re-implemented in scripting space from scratch, despite there being better solutions available in SG/FG C++ space, due to those not being exposed to/accessible from Nasal).Some of the most senior core developers have repeatedly expressed dissatisfaction with these developments - but unless someone is doing something about this, this is going to continue - simply because of the lack of mutual coordination (not just among core developers, but also among core/fgdata contributors - with Nasal/Canvas being primarily a fgdata technology these days).

It is obviously great to hear from core developers coming here and announcing that coordination is simply not as visible, but still taking place - but the fact is that this is the Canvas sub-forum, where we're now discussing mongoose/httpd and Qt5 launcher developments (=core development), all of which are very likely to have an impact on the Canvas GUI.

Personally, I am definitely going to prioritize my own involvement according to what active core developers state in public - and I guess that applies just as well to other people interested in a more modern GUI. In other words, if there are plans to continue having a Qt5 GUI -possibly involving your mongoose GUI work- I would very much appreciate knowing that up-front, before I might spend another year contributing to an effort that core developers are working against.

In all seriousness, please let this not be another "radio propagation code"-like incident, but let's work out a way to coordinate things here - while accepting and appreciating that FlightGear doesn't just consist of core development or private discussions taking place behind the scenes, of which the majority of fgdata developers are never made aware of.

Torsten: There is a lot of coordination and communication going on between most "core developers".

Michat: I hope most means, all, or almost a representation when someone absence of the technical board, if exists.

Torsten: Just a little bit of this is visible as we sometimes meet face-to-face and much more often voice or video-chat.

Michat: A good reason to understand that lack of coordination regarding that situation around gui canvas.

Torsten: The parallel development of HTML and Qt based UI happens by intention and is not the result of missing coordination.

Parallel should means wingsider.. while I begin to understand that in freesotfware usually means Fork-Deviation-Duplicity, anyway researching for new functionalities advantages is a good intention.

Been my work a tiny contribution, I felt bad about you the programmers typing code for a dream over dream, over dream. You dream fast Torsten.End of Torsten part.

Start loud thinking.

Why so smart people repeat same structure, why all freesoftware structures replicate the same fork-pararell pattern ? is a social pattern behavior? it is a free radical ramdomness? it is the time-line, or our communication system that can't guarantee nuclear success and best results/efforts?

Last week I did contact with some Extra-500 developers who didn't know about my svg work, and they liked. And I felt bad.

Then I found that there are several pararell starting projects for the MD. And I felt bad. So using the forum I was trying to make certain that people share information and knowledge both together on what's happens at same time-line on mD's. Something is wrong in the communication system.

We should be monoids our funcion is to share info and colaborate in a nuclear way to our monads, each monoid can do what is capable off around some possibilities skills offered.

Each monad are interconected, and their function is coordinate between others monads and to coordinate their monoids groups in order to reach common desired objetives.

If someone with hi skill wants to create his own monad, that monoid will be subject to the general monad function in order to find the common desired objetive.

There are a lot of possibilities in order to create a monad. You can create a R+D monad, but you can only be a monoid representative of that monad, the result will be total of the cooperations decisions to reach the common desired objetive (monad creation statement (member of the common desired objetives)). As a FG's monoid you can be member of the monads you are more interested based on your skill and some options offerted.

I don't find a better way to do it, growing organicaly from core, so when I see you in pararell wing by wing buzzing me at light speed I can be certain that at least a little of thrust are my two cents. You developers don't know the lot of WOW's we share watching your skill - developments - projects going on. But also you should know that sometimes we feel bad when those things happens, loosing valuable projects - people, same time we see the big efforts you are doing such in communications as well programming, writting, etc, etc.

Appart of gui topic I wonder/ thinking in methods on how the qt5/html5 css3 could be used to implement such a organic structure, in the way that monads could offers different lists (proposals) with assorted skill funtions activities to new monoids, improving coordination/communications/states of devs, flying center , fgvirtual airlines and more. The world that in my oppinion should populated the web page (nice design effort now, thank you a lot). The world I tried to explain with these lines, because I'm reading a book entitled Pure Theory Of the Republic ( taking Republic like a public things, common objetives, agreements, solutions, but not in the usual gov political way ) been this book the most modern policy theory nowadays. It just the starting point to grow with the discover of the Political monads theory, very surprised to me that the most advance political researcher, still has not discovered the monoids, instead off he declares the monads like the minimun unit with significance discovered, beeing that and advance in politics.

While I saw that funcional programing really have monoids. I get socked. We can do it !, we are monoids !, lets offers functions to the people.We cannot invert our positions in order to create an especular image of our monoidal world. Sometimes I hope you devs going to MP in order to see how much grattitude can people express about your work, more than feedback is kind of reverse experience, monoid says monoid do hehehee.

Can we do grow like a fractal ? do we have an snapshot of the body morphology or our code. Are we fatty amorphous?

For example in order to invert the funcion I could add some code to those aircraft that lack of <replay my control button> in case will be easy task for non programmer, same task could be offered to others that can match the objetive. A lot of silly thing can be offered by a funtional system. Where a little mind could grow in a non facebookish social cross-transversal fashion.

My country is lacking of researchers due to crisis and salary, I know one that is goig to move to swiss where he is going to work in his a laureatus investigation, animal facebookish inter social networks. As a good Darwinism member he is well payed to say that the man destination is extintion, because Man don't cooperate together.

I wish also to be well payed to say that the only way is contributing in the right way, even so if whe have nothing sure, is the coordinated work that can give us a change.

Thanks you guys to take time reading this combo.What do you think guys?.

Last edited by Michat on Sun Jan 11, 2015 9:30 pm, edited 1 time in total.

Why so smart people repeat same structure, why all freesoftware structures replicate the same fork-pararell pattern ? is a social pattern behavior? it is a free radical ramdomness? it is the time-line, or our communication system that can't guarantee nuclear success and best results/efforts?

Because There is more than one way to do it.. How many FDM do we have in FlightGear? How many weather systems do we have?How many web browsers, e-mail clients, operating systems are on the market?How many different types of chocolate can you coose from in an average supermarket?And why is this so? Because sometimes it's a matter of taste, sometimes it's because people learn and products evolve over time.

So why did I start with a HTML based user interface?Because I wanted to control FlightGear from my iPad and my Android tablet. And from my old Netbook PC. And without building or installing software on it. And because I believe it's much more efficient to build on an existing, well established, tested, maintained and documented code base instead of creating from scratch what is already there.And because I am convinced that building a user interface based on Canvas/Nasal is a dead-end development.

For me, the freedom of choice is heaven, not hell. Not only when looking for chocolate in a supermarket.

I entirely agree with your other points, but you may want (or not ...) to elaborate on this a bit, especially if other (active) core developers are pursuing alternate GUI strategies for the same reason:

Torsten wrote in Sun Jan 11, 2015 2:54 pm:And because I am convinced that building a user interface based on Canvas/Nasal is a dead-end development.

Is this because of Nasal, is it because of Canvas - or is it because of NOT using existing technologies (no matter if it's HTML5/JavaScript or Qt) ?I happen to agree with the latter - but the FlightGear project has a long history of coming up with custom niche solutions instead of adopting existing industry standards.

And basically the same thing has been said about coding a complete weather system from scratch - and we all know how Thorsten proved all of us wrong.

I will admit that Nasal has its issues - but they're fairly straightforward to overcome in comparison to other shortcomings running in the fgfs main loop - i.e. the GC is a single file that can be adapted or re-implemented, and we already have at least one generational GC scheme - including one threaded GC implementation contributed by AndersG a long time ago (which for some reason has apparently never been committed by any core developers).

I'll be the first to say that we should have never used PUI and never come up with a Canvas GUI (or even Canvas), had Qt been accepted as a dependency a few years ago - but the truth is that some of the most senior core developers were very outspoken against Qt as a dependency, including Mathias, Tim, Fred and Stuart - with most of them now being inactive/active elsewhere, the project now seems in "your" hands admittedly - but I'm still not sure if we should simply throw all concerns over board here ?

Equally, we have professional users wanting to support A661 scenarios, where you simply must be able to render fully hardware-accelerated MFDs including MFDs having their own GUI, right inside the FlightGear main view (main loop for now).

Accepting Qt5 as a dependency into FlightGear is a huge shift in thinking, and a good one I'd say - in fact, I'd applaud the people pushing this forward. But there's so much more being made obsolete by allowing Qt5 than just the GUI, there's tons of legacy code that could be phased out over time, i.e. FlightGear could be increasingly modernized. So I am not at all opposed to the idea, and I fully appreciate all the GUI efforts - including the HTML5/Qt work, but also the Canvas work.

However, it simply isn't fair to just go about with these kinds of changes without also getting people involved who've been working towards related features for months and years, without also looking at the consensus that core developers arrived at 2+ years ago - while also stating in merge requests that such things tend to be discussed up-front. Double standards, I guess ?

I think there are some very real opportunities now for us to have our way without stepping on someone's toes - but for that to happen, we need to be proactive and actually work out a way to find a compromise, and communicate our plans/roadmaps and see if/where and how it might make sense to align these developments to a certain degree - e.g. by seeing if we can have a common service layer for UI needs.

But let me repeat, accepting more modern dependencies (think OSG, boost, python/lua, Qt) is a generally a good thing for FlightGear and helps us move away from unmaintained niche solutions - but for that to happen, there needs to be some consensus first, even if that's just a consensus among active core developers, this should be communicated up-front, because it affects heavily how fgdata contributors are spending their spare time - many of whom having spent 100+ hours contributing to what at least one core developer is now referring to as a "dead-end".

Equally, I am seeing others referring to browser-based MFDs as a "dead-end" for technical reasons (Canvas being OSG/scene-graph driven and fully hardware-accelerated).

Here's some context from the devel list archives, i.e. statements made by some of the more senior contributors involved in the rendering core of SG/FG:

James Turner wrote:the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases).

Curtis Olson wrote:If you know something about gui systems,something about portability of code across all our supported platforms, andsomething about flightgear. Then post a proposal for a change. Better yet,post patches with a new gui system that doesn't suck, runs efficiently,supports all platforms, integrates cleanly with FlightGear, doesn't add anightmare of new library dependencies, isn't chock full of bugs, doeseverything the current system does, and does everything you think a guisystem should do, etc. etc.

Tim Moore wrote:Qt widgetscan be drawn into OpenGL buffers. That doesn't change the fact that it wouldbe a great deal of work to port our GUI to Qt, and it would introduce avery large external dependency. Having seen the fit pitched when I startedusing boost...

Now, big projects can get done, and motivated individuals with time on theirhands can work wonders. We should keep in mind the relative importance ofthe GUI system to the whole flying experience and judge whether it would beworth the effort to do a huge rewrite in this area.

Stuart Buchanan wrote:We are to some extent hamstrung by the rather old GUI toolkit we use. However,replacing that is going to be non-trivial, and it would affect not just the core GUI butalso all the dialog boxes that have been set up for particular aircraft.

If these concerns were recently addressed/discussed behind the scenes, without fgdata contributors (forum users) having been involved, this should be made much more prominent - ideally by using the wiki to announce your plans/roadmap - even if just to set the record straight and tell us to stop wasting our time contributing to stuff that some of the most senior, and most active, core developers are working against.

Huh? I don't "hold the project in my hands" - that's a bit too much of honor for me. And it's plain wrong.Remember our slogan? Free and Open. Let's keep it that way.

Regarding the Nasal/Canvas GUI deadend: you found out my major concerns by yourself. You might weigh the facts differently than I do and because of that come to another conclusion than I do. You are free to prove me wrong, Please excuse me if in the mean time, I don't want to wast my time with something _I_ believe has no future.

Related to Qt, I can say that up to now - as far as I can tell - only a simple replacement for the Mac Launcher has been introduced. This is not related to the internal user interface of FlightGear, at least for now. If, how and when the internal gui can leverage Qt is under investigation and in such an early state that those responsible preferred to not announce anything yet. If this ever happens, this will be discussed on the mailing list (please refer to the top of this very page).

In order to maintain freedom (open for me is nothing, open source is a perversion of language), the best way is doing together. Adding dependencies to a software in order to get some practical advantages is a well know topic discussion in the free software world, usually caused by privative soft, now in the open source gradient side, signing as gpl. With a plethora of illuminati entrerprises list adopting it, mixed by some other opensource famous names as I saw on wikipedia. (that's new to me)

Being big technical decision an element that could concern the future of FG and the current state of development, I could consider that :

There must be a technical monad that evaluates pros and cons regarding the adoption of technologies. Even adopting bad technology by mistake-wrong decision , it should be a basic compromise. Also the technical monad can control de best way to reach the common objetives, coordinating changes, decisions and alternatives, R+D, etc. But must important thing the technical monad have to resolve coordination problems with a function estructure that can assure the coordination circuit.

It's up to you to find a system to improve coordination and to avoid this uncorfortable situation. If the current communication system do not grants equal levels of communication/coordination access (core), then must be debated and resolve.

Sure that there are some other people that can think that you both are wrong. How we can debated and resolve our future technical decisions for freedom without to crash each other ?

I bet it's not gonna be popular in this community, but how about Gtk? It's not a complete religion like Qt, just a library, and it looks nice on Linux and OS X. On Windows it will probably look like PUI and 90% of third-party applications on Windows; out of place. Qt looks like Windows here on Linux and has a habit of segfaulting quite often.

I wasn't going to respond to this for the sake of keeping things constructive (needless to say that I don't agree on all counts with Torsten here, especially not the polemics...)

Actually, there used to be a wiki article comparing different GUI options (including Qt, Gtk, wxWdigets, Nui etc) - however, the main consensus used to be that the degree of dependencies added to FG would not be acceptable. Things have changed a bit since then - not so much because these dependencies have suddenly become more lightweight, but because a few core developers are more familiar with certain technologies (while many others are simply inactive or don't bother). For instance, Zakalawe mentioned a few times on the forum that he's working for some Qt-affiliated (Trolltech/Nokia) company.

So it's not so much about finding viable alternatives, it's more about finding a contributor familiar with the corresponding GUI solution, as well as FG internals. Among all active FlightGear core developers, it is probably safe to say that Zakalawe is the only one to be familiar with most subsystems (especially given his reset/re-init work). In other words, it is way easier for someone to work on a Qt-based FlightGear GUI with that background for understandable reasons. So I wouldn't hold my breath suggesting any alternatives.

Even the Canvas GUI is mainly based on momentum, i.e. people willing towards this - equally, Torsten's work is heavily reliant on his own involvement, too.

FlightGear is a fairly unsteady project, so people need to continuously re-evaluate their involvement given the current context/activities of other contributors.What Torsten is trying to do is the right thing from an architecture (i.e. technical) standpoint - it isn't feasible for FlightGear to keep on re-inventing the wheel, no matter if it's UI solutions, scripting or threading architectures. There are well-understood "standards" that provide solutions for most problems FlightGear is facing, but the number of people willing to adopt standards is fairly low.

Again, I am not at all opposed to Qt - FlightGear would be in a great shape if more dependencies like these had been accepted years ago - we wouldn't be facing being locked-in by contributions made years ago, without having any active contributors able/willing to maintain such niche solutions.

However, it is definitely true that such things should be discussed and made much more prominent - we've had people discussing behind the scenes to phase out Nasal and other features at some point.It is far too easy to always look at Nasal once FlightGear issues are examined - but even without Nasal, there would be some very real issues in the architecture of FlightGear, including bugs that affect frame-rate and frame spacing, as could be seen by Torsten's recent bug fix to the effects subsystem (which was completely unrelated to Nasal).

Basically, the OSG port in early 2006 also was a very controversial thing, and some of the more senior core developers were also reluctant about the degree of regressions introduced back then - these days, it is obvious that we're better off thanks to adopting a modern, and well-maintained, scene-graph - however, we have roughly 15-20 contributors working on several GUI related efforts, including core developers and fgdata committers who are understandably feeling left out of the loop right now, so this is much more about coordination and collaboration (=project management) than Qt or HTML5 in particular. Those developments are fortunate for FG, especially if Torsten and Zakalawe can convince fellow contributors to collaborate properly.

Having >= 12 different GUI front-ends is ridiculous, and not being able to reset/re-init the simulator correctly is very unfortunate, too - these are long-standing issues, affecting how FlightGear evolves - i.e. not being able so save and load/resume flights is not just an inconvenience, and not being able to switch aircraft at run-time demonstrates that there are pretty serious design issues in the way FlightGear is structured - so whatever is done to address these issues is a good thing, especially if it helps clean up FlightGear by getting rid of custom niche solutions and adopting "standards", i.e. well maintained external solutions (like OSG, boost, gdal/cgal etc)

If Torsten and Zakalawe want to replace PUI with Qt, then go for it. (As long as I can use VBoxes and HBoxes like in Gtk instead of having to manually position widgets to precise x,y coordinates (which is what screenshots of QtDesigner always suggest you have to do)