IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par dourouc05

23PARTAGES

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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Markand
Membre éclairé https://www.developpez.com
Le 06/03/2017 à 8:48
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).
1  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 06/03/2017 à 14:43
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".
1  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 06/03/2017 à 13:45
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.
0  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 06/03/2017 à 13:55
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).
0  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 06/03/2017 à 14:47
Citation Envoyé par LittleWhite Voir le message
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...

Citation Envoyé par LittleWhite Voir le message
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.
0  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 06/03/2017 à 16:00
Citation Envoyé par LittleWhite Voir le message
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.
0  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 06/03/2017 à 2:57
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
0  1 
Avatar de ovh
Rédacteur https://www.developpez.com
Le 06/03/2017 à 13:33
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.
0  1