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

Le 2017-03-05 22:01:44, par dourouc05, Responsable Qt & Livres

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 :

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 :

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.

Discussion forum

8 commentaires

Markand
Membre éclairé

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).

le 06/03/2017 à 8:48
LittleWhite
Responsable 2D/3D/Jeux

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".

le 06/03/2017 à 14:43
LittleWhite
Responsable 2D/3D/Jeux

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.

le 06/03/2017 à 13:45
dourouc05
Responsable Qt & Livres

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).

le 06/03/2017 à 13:55
Aurelien.Regat-Barrel
Expert éminent sénior

Envoyé par LittleWhite

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...

Envoyé par 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.

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.

le 06/03/2017 à 14:47
dourouc05
Responsable Qt & Livres

Envoyé par 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".

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.

le 06/03/2017 à 16:00
Aiekick
Membre extrêmement actif

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

le 06/03/2017 à 2:57
ovh
Rédacteur

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.

le 06/03/2017 à 13:33

Poster une réponse