Ici on n'a que votre IP, votre pseudo et votre adresse mail que nous ne traitons pas.
Quand vous êtes enregistrés, une seule requête permet de vous afficher les messages que vous n'avez pas lus.
NOUVELLE ADRESSE PERMANENTE DU DÉPÔT: https://mirrors.o2switch.fr/primtux/repo/debs
ATTENTION, MERCI DE NE PAS METTRE À JOUR PRIMTUX7 UBUNTU 20.04 VERS LA 22.04, LES HANDYMENUS NE SONT PAS ENCORE COMPATIBLES!
Merci de cliquer ici si vous souhaitez vous inscrire sur le forum.

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Evolution des Handy-menu
#51
Bon alors tout est ok, si je chipote j'aimerais bien que la fenêtre monter et descendre ne se ferme pas tout de suite quand on a cliqué dessus: qu'on puisse monter et descendre plusieurs fois sans avoir à recliquer sur l'icône à chaque fois.
Répondre
#52
Je suis sur qu'une fois fait, tu chipoteras pour autre chose... :lol:
Mais, j'accepte : ça fait parti du deal.

Bon, c'est la toute petite fonctionnalité qui m'alerte sur un soucis de conception : la fenêtre est reconstruite intégralement à chaque fois qu'on monte ou descend une section.
Je suis partagé par le fait de :
1. juste faire ce qui est demandé : un timer (par exemple 0.5 secondes) sur l'action au clic ou tant qu'on a pas dépassé 0.5 seconde d'inactivité, la section peut être déplaçable.
2. ne déplacer que l'onglet et ne pas tout recharger : sans doute plus long mais bien mieux.

Je vais suivre mon intuition et partir sur la 2ème solution.
Répondre
#53
Eh bien, tu as bien fait de chipoter !!
J'ai lu la doc de GTK et j'ai fait de belles découvertes : il est tout à fait possible de déplacer facilement des onglets sans rafraîchir violemment l'interface au complet.

J'ai donc réalisé ce qui m'a été demandé (le commit de ce soir) et ça résous dans la foulée un bug assez bizarre que j'avais identifié sans trouver de réel solution : quand on faisait un peu trop de manip de déplacement de section, le rafraîchissement de la fenêtre peinais.
Je suppose que ça doit avoir aussi des répercussions sur le cpu et la ram donc vraiment tout bénef.

Je pense que dans un second temps, je vais identifier et éradiquer tous les rafraîchissements de la fenêtre (sans doute, ajout et suppression d'une section) : ça sera forcément plus fluide.

J'ai vu qu'il était également possible de déplacer les sections avec du glissé/déposé (en complément des boutons) : ça serait vraiment bête de s'en priver, non ?
Répondre
#54
Bien sûr, j'allais te le demander, mais une chose à la fois! ^.^
Répondre
#55
Je viens de mettre en place le drag and drop des sections.
Répondre
#56
toujours dans la continuité, la suppression et l'ajout de section se font désormais sans rafraîchir l'app.
Sur les devs à venir, je vais sans doute corriger tous les autres rafraîchissement et je vais commencer à réfléchir à un drag and drop des apps.
Répondre
#57
Oui voilà, c'est ce à quoi je pensais aussi.
Répondre
#58
Qu'est-ce que je dois modifier pour que les handymenus se ferment TOUT LE TEMPS par défaut? Actuellement il faut cocher à chaque fois pour qu'il se ferme quand on lance une application. Il faudrait qu'une fois coché, ça le soit encore quand on rallume les handymenu.
Répondre
#59
Bon, j'ai trouvé en mettant un "True" dans le handymenu.app.
Répondre
#60
Est-ce qu'il y a encore des bugs ou des fonctionnalités à réaliser pour les handymenus ?

J'en vois quelques une comme les le drag and drop des apps mais c'est pas mal de travail pour peut-être pas grand chose.

Je ne dis pas que je n'y reviendrais pas mais le mieux est l'ennemie du bien et ça me semble dans un état acceptable et bien plus convainquant que la solution précédente.

J'aimerais également avancer sur d'autres projets : Grammatrainer (http://forum.primtux.fr/viewtopic.php?id=1219) et le Puissance 4.
Répondre
#61
Non ça va.
Répondre
#62
Bon, j'y vais aussi de mes souhaits sur les handyenus ! Wink

A défaut du drag and drop des applications (qui serait effectivement bien pratique), est-il compliqué de permettre de monter ou descendre une application sans que se ferme la fenêtre de déplacement, comme suggéré déjà par Stephane ?

Serait-il compliqué de permettre l'édition d'une entrée dans la fenêtre de modification, par exemple pour modifier une ligne de commande ? Cela permettrait entre autre d'insérer une entrée sans être contraint de créer un fichier desktop.
Répondre
#63
Pour la 2ème remarque, on peut déjà glisser un document, une vidéo... un fichier comme on le fait pour une application et il sera ouvert en cliquant dessus.
Répondre
#64
Philippe a écrit :A défaut du drag and drop des applications (qui serait effectivement bien pratique), est-il compliqué de permettre de monter ou descendre une application sans que se ferme la fenêtre de déplacement, comme suggéré déjà par Stephane ?

Ca risque d'être plus difficile à réaliser que le drag and drop...
Je me repenche dessus cette semaine.
Répondre
#65
mothsart a écrit :Ca risque d'être plus difficile à réaliser que le drag and drop...
Si on peut placer l'icône où on veut par drag and drop, c'est selon moi beaucoup plus simple et intuitif que de passer par une boîte de dialogue pour monter ou descendre ! Donc pour moi, fais par drag and drop si c'est plus simple !
Répondre
#66
On a aussi fait sans y a pas le feu au lac! On est vraiment dans du peaufinage étant donné que les questions aux RMLL par exemple ont plus porté sur l'ajout de catégories, d'applications, de fichiers... L'ordre des icônes est en réalité très secondaire.
Répondre
#67
Alors, ça avance.

J'ai pris du temps à lire de la doc pour comprendre comment m'y prendre parce que c'est quand même la jungle GTK (QT est pas mieux) dès qu'on veut faire un truc qui sort un peu des sentiers battus.

Ca pose un soucis niveau IHM car le drop va faire appel à l'évènement clic d'édition. (et du coup ouvrir la popup d'édition du lanceur)

Soit :
- je déclenche l'édition du lanceur au double-clic
- je ne passe plus par une popup : le clic sur un lanceur dégrise la zone d'édition qui se trouvera en dessous de la grille des lanceurs

Je préfère vous demander plutôt que de me lancer dans l'un ou l'autre.
Répondre
#68
+1 pour le double-clic, il y en a qui demanderont comment on fait au début mais je trouve ça plus logique.
Répondre
#69
+1 également pour le double-clic, qui me semble plus intuitif car correspondant davantage à ce qui se pratique couramment: en mode édition, un double-clic ouvre un module d'édition.
Répondre
#70
Je viens de commiter le drag and drop.
C'était vraiment pas de la tarte (gtk fourni des outils très bas niveau donc faut se farcir des maths et passer par l'étape papier pour anticiper tous les scénarios) et il n'est pas improbable qu'il y ai des bugs sournois sur cette fonctionnalité.
Je suis pas entièrement satisfait du code produit : c'est assez brouillon à la relecture mais on va s'en satisfaire.

Il reste sans doute un dernier point à améliorer : un indicateur de l'emplacement ou va s'effectuer le drop pendant qu'on drag.
Je fais ça dans les jours qui viennent : le code étant cloisonné dans un event, il ne pourra pas entraîner de régression.

Cqfd : la fourchette de tests peut commencer dès à présent.
Répondre
#71
Je viens de terminer le drag and drop : c'est désormais fonctionnel (tel que je le souhaitais).
Répondre
#72
Je teste dès que je peux.
Répondre
#73
Ça marche!
Répondre
#74
Bon là il va dire "il est chiant là, non?". Mais en fait l'icône d'abuledu aller est énorme, et je sais que les icônes varient de taille, est-ce que tu aurais une petite formule magique pour qu'elles s'affichent en 48x48 par exemple...euh s'te plaît? (A)

Et en fait on peut virer monter et descendre de la fenêtre d'édition, non?
Répondre
#75
Pour le coup, c'était pas trop compliqué.
Les images sont en 64x64 (car sinon, il fallait que je retouche et retest tout mon dev sur le drag and drop).
D'autres besoins ?
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)