Discussion :

[dourouc05]

Une API de widgets natifs pour Qt : elle ne devrait arriver qu'avec Qt 6
et une rationalisation des possibilités pour créer des interfaces

Un utilisateur préfère très souvent une application qui s’intègre parfaitement à son environnement : des boutons dans le bon ordre, des raccourcis communs… mais aussi une apparence similaire. Évidemment, le plus simple, pour y arriver, est d’utiliser les API spécifiques à chaque plateforme — mais cela complexifie énormément le développement d’une bibliothèque multiplateforme comme Qt. Il vaut mieux alors réimplémenter complètement chaque composant (par exemple, avec OpenGL pour l’affichage) en se rapprochant de l’apparence des composants natifs, y compris pour les animations. Cependant, l’apparence et les animations peuvent changer d’une mise à jour à l’autre : difficile de se tenir à la page.

Quelques développeurs de Qt commencent donc à explorer l’autre piste : donner accès directement aux composants natifs à travers Qt. L’idée n’est pas neuve (wxWidgets l’implémente, par exemple), mais elle présente toute une série de défis — pas tellement pour les composants les plus simples, mais surtout les plus complexes, comme les onglets — : selon les systèmes, les composants natifs ont plus ou moins de fonctionnalités, une variété difficile à unifier.

Les développements actuels donnent un prototype d’ensemble de composants, avec une architecture à base d’extensions (une par plateforme). L’API (tant C++ que Qt Quick) est très réduite et fonctionne comme une boîte noire : les fonctionnalités exposées doivent être disponibles sur toutes les plateformes actuellement gérées… et celles du futur. Cette restriction signifie que cette solution n’est pas prévue pour ceux qui souhaitent personnaliser leur interface. À terme, l’objectif est de laisser l’utilisateur accéder directement aux composants natifs pour implémenter les fonctionnalités non disponibles lui-même.

Par exemple, voici une petite application Qt Quick qui mélange l’API commune (module Qt.CommonControls — le nom n’est pas définitif) et des composants natifs spécifiques à macOS (AppKit, module Qt.AppKitControls) :

Code qml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
import QtQml 2.0
import Qt.CommonControls 1.0 as Common
import Qt.AppKitControls 1.0 as AppKit
 
Window {
  id: window
  visible: true
 
  Common.Button {
    id: button
    x: 20
    y: 20
    text: "Click me"
    onClicked: text ="You clicked me!"
  }
 
  Common.TextField {
    id: textField
    placeholderText: "TextField"
    x: 20
    y: button.bottom + 8
  }
 
  AppKit.SearchField {
    placeholderText: "Search"
    x: 20
    y: textField.bottom + 8
  }
}

La même en C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
int main(int argc, char *argv[])
{
  QGuiApplication app(argc, argv);
  QCommonWindow window;
 
  QCommonButton commonButton(QStringLiteral("Click me"), &window);
  commonButton.move(20, 20);
  QObject::connect(&commonButton, &QCommonButton::clicked, [&commonButton](){
    commonButton.setText(QStringLiteral("Clicked!"));
  });
 
  QCommonTextField textField(&window);
  textField.setPlaceholderText(QStringLiteral("TextField"));
  textField.move(20, commonButton.bottom() + 8);
 
#if defined(Q_OS_MACOS)
  QAppKitSearchField searchField;
  searchField.setParent(&window);
  searchField.move(20, textField.bottom() + 8);
  NSSearchField *nsSearchField = searchField.nsSearchFieldHandle();
  nsSearchField.placeholderString = @"Search...";
#endif
 
  window.showFullScreen();
  return app.exec();
}

Des mécanismes de type préprocesseur devraient donc se retrouver dans Qt Quick, à un moment ou à un autre, pour gérer le code à utiliser selon la plateforme — exactement comme en C++.

Ces développements ne devraient pas arriver avant Qt 6. En effet, avec Qt 5, on compte déjà un certain nombre de manières de créer des interfaces graphiques :

• Qt Widgets ;
• Qt Quick et ses composants de base (de très bas niveau) ;
• Qt Quick Controls 1 ;
• Qt Quick Controls 2.

La situation est déjà complexe ; ajouter ces composants natifs ne ferait qu’embrouiller largement plus toute personne débutant avec Qt. Les plans sont donc de réduire le nombre d’options : soit Qt Widgets (pour la compatibilité avec les applications existantes), soit Qt Quick Controls 2 (pour l’embarqué et le mobile), soit cette nouvelle voie de composants entièrement natifs (pour les autres besoins).

Source : Native look and feel.

[Aiekick]

si ca peut alleger le core avec qt c'est pas plus mal. j'ai préféré wxwidgets pour cette raison. qt sait faire plien de chose, mais trop de chose et du coup il est tres lourd.

tout depend du besoin evidemment

[Markand]

Qt est modulaire, si tu veux juste faire une fenêtre avec des widgets, tu te lie à Qt5Widgets et Qt5Core. C'est pas lourd. Le reste est finement découpé (bluetooth, 3d, web, etc).

[ovh]

Autant utiliser wxWidgets directement non ? Utiliser au maxium les composants natifs est justement leur principe de base. Et comme Qt ils ont d'autres composants non visuels pour le réseau, la base de données etc.

[LittleWhite]

Bonjour,

Je ne suis pas convaincu par cette approche "native". Cela me donne l'impression que je dois construire une couche intermédiaire, entre Qt et mon application, pour refaire l'uniformisation que Qt 5 faisait.
Alors, oui, ce sera natif et intégré au reste de l'écosystème, mais du coup, ce ne sera que pour les applications non multiplateforme ? J'ai beaucoup de mal à voir l'intérêt.

[dourouc05]

L'intérêt est principalement de proposer des interfaces vraiment natives, utiliser tous les composants natifs de la plateforme, surtout quand ceux-ci n'existent pas vraiment ailleurs (même dans Qt). Par exemple, le composant de recherche textuelle côté macOS (https://developer.apple.com/referenc.../nssearchfield), qui n'a pas vraiment d'équivalent pour Qt (à ma connaissance, du moins).

[LittleWhite]

Mais du coup, si je veux une application "look & feel" native et portable, je vais avoir plein de #ifdef pour gérer toutes les plateformes. C'est pour moi, loin du "Code once, deploy anywhere".

[Aurelien.Regat-Barrel]

Je ne suis pas convaincu par cette approche "native". Cela me donne l'impression que je dois construire une couche intermédiaire, entre Qt et mon application, pour refaire l'uniformisation que Qt 5 faisait.

Qt5 fournit déjà des modules dans le même genre destinés à améliorer l'intégration à une plateforme cible:
http://doc.qt.io/qt-5/qtwinextras-overview.html

Portabilité vs fonctionnalités, l'éternel dilemme...

Mais du coup, si je veux une application "look & feel" native et portable, je vais avoir plein de #ifdef pour gérer toutes les plateformes.

Je pense que c'est un code d'exemple. Dans la pratique ça se peut se gérer au niveau du build system (qmake) pour isoler et compiler des fichiers spécifiques à chaque cible.

[dourouc05]

Mais du coup, si je veux une application "look & feel" native et portable, je vais avoir plein de #ifdef pour gérer toutes les plateformes. C'est pour moi, loin du "Code once, deploy anywhere".

Dans tous les cas, si tu veux que l'utilisateur ait l'impression que c'est du natif (à 100 %, au dernier epsilon près), tu devras avoir une implémentation pour chaque plateforme.