Yes, that’s what we are discussing, the definition used for the native flag in HaikuDepot is:
So, this definition chose to include two items:
- The application follows the guidelines
- The application is implemented using the Be API and not, for example, Qt or GTK
These two things are somewhat independant, but the definition of the native flag currently includes both. That excludes applications implemented using Qt, even if they are designed specifically for Haiku (for example, HiQDock) and/or fit very well in the look and feel. That also excludes applications that use the native API in unexpected ways (I can think of CL-Amp, which is a Winamp clone for BeOS that uses the native API, but does its own drawing to implement WinAmp skins on its main window). But on the other hand it includes WebPositive (despite using curl), Renga (despite using gloox), and possibly ACE (despite really being a port of a MorphOS application - but you could debate on some of the non-standard UI widgets used in it).
And then, there can be a wider debate about wether the lightweight-ness and use of few 3rd party libraries is part of the Haiku “look and feel”. Either in a direct way (just using Qt outright disqualifies apps), or in an indirect way (longer startup times, slightly different behavior or rendering of UI controls, not using translators for file formats management, …). In the latter case, it would be possible in theory for someone to build a fully “native” app using Qt, if they solve all of these problems. I would say no such app exists currently, but it really depends on what each person considers “good enough”, and we surely will all have a different subset of expectations. So, the “use Haiku native API” has the advantage of being clear cut, at least.