RuleEditor
laurris
Membre
RuleEditor est un framework pour OS 10.4 + composé d'une classe principale PSRuleEditor, sous-classe de NSView.
Il s'agit de refaire l'élément d'interface que l'on peut trouver dans la fonction Spotlight du Finder pour filtrer des fichiers. L'idée est de pouvoir l'utiliser dans n'importe quelle application compatible Tiger.
Il y a plusieurs mois, j'avais pondu un truc du même genre (criteriaView) mais qui s'était avéré peu pratique d'utilisation. Dans criteriaView, il y avait un système de chargement de nibs, avec des bindings dedans. Dans RuleEditor, rien de tout celà . Les éléments sont créés et détruits dans le code, et on peut y accéder à l'aide de méthodes dédiées. La création des éléments (criterion) est paramétrable du coté "client" grace à un delegate, ce qui permet une plus grande flexibilité d'utilisation.
Il y a aussi un support pour les prédicates en cours d'élaboration.
Pour l'instant, le framework est en version beta mais déjà assez avancé pour le faire fonctionner dans une appli. Je bosse encore à la mise en place de ce projet et à la création d'une page web et d'une doc, mais en attendant voici un avant goût ici:
EDIT: code dispo ici: http://code.google.com/p/ruleeditor/ >> onglet Source
On peut télécharger une appli test linkée au framework pour avoir une idée du bidule (attention beta= bugs !).
Si certains sont intéressés et souhaitent participer au projet, ils peuvent d'ores et déjà me le faire savoir ici ou par mail. Je crois bien que lorsque j'avais posté CriteriaView (le brouillon précédent), il y avait déjà eu des réponses dans ce sens, donc ça marche toujours pour moi. En particulier s'ils s'y connaisent en drag'n drop de vues ou en Ib palette parce que ce sont des choses que j'aimerais faire à l'avenir.
Dès que j'aurais finalisé le problème de la licence et de la doc je donnerai plus d'infos ici même, avec un lien vers le code source.
A+.
Il s'agit de refaire l'élément d'interface que l'on peut trouver dans la fonction Spotlight du Finder pour filtrer des fichiers. L'idée est de pouvoir l'utiliser dans n'importe quelle application compatible Tiger.
Il y a plusieurs mois, j'avais pondu un truc du même genre (criteriaView) mais qui s'était avéré peu pratique d'utilisation. Dans criteriaView, il y avait un système de chargement de nibs, avec des bindings dedans. Dans RuleEditor, rien de tout celà . Les éléments sont créés et détruits dans le code, et on peut y accéder à l'aide de méthodes dédiées. La création des éléments (criterion) est paramétrable du coté "client" grace à un delegate, ce qui permet une plus grande flexibilité d'utilisation.
Il y a aussi un support pour les prédicates en cours d'élaboration.
Pour l'instant, le framework est en version beta mais déjà assez avancé pour le faire fonctionner dans une appli. Je bosse encore à la mise en place de ce projet et à la création d'une page web et d'une doc, mais en attendant voici un avant goût ici:
EDIT: code dispo ici: http://code.google.com/p/ruleeditor/ >> onglet Source
On peut télécharger une appli test linkée au framework pour avoir une idée du bidule (attention beta= bugs !).
Si certains sont intéressés et souhaitent participer au projet, ils peuvent d'ores et déjà me le faire savoir ici ou par mail. Je crois bien que lorsque j'avais posté CriteriaView (le brouillon précédent), il y avait déjà eu des réponses dans ce sens, donc ça marche toujours pour moi. En particulier s'ils s'y connaisent en drag'n drop de vues ou en Ib palette parce que ce sont des choses que j'aimerais faire à l'avenir.
Dès que j'aurais finalisé le problème de la licence et de la doc je donnerai plus d'infos ici même, avec un lien vers le code source.
A+.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est bizarre parce je l'ai compilé sous macintel mais avec i386 et ppc dans le build setting "achitectures".
Quand je fais "lipo -info <exectutable>" il me dit bien que c'est un universal binary.
Est-ce que la console te dit quelque chose de spécial quand tu essaye de lancer l'appli ?
[Fichier joint supprimé par l'administrateur]
Désolé pour le désagrément.
En dehors des amélioration du framework lui-même (qui reste en beta), le projet et l'appli qui va avec permettent de:
- Filtrer une table en presque live avec RuleEditor et son predicate associé (on peut rafraichir le prédicate avec le boutton ad hoc)
- Ajouter un contrôle perso à RuleEditor en fonction du choix des critères. Ici un NSSlider mais on peut ajouter n'importe quelle NSView en théorie.
- Voir comment fonctionne le delegate qui permet d'afficher les lignes. (3 methodes requises)
- Inclus, une doc des methodes et constantes utilisées.
Si vous avez des bugs à signaler ou juste un commentaire, le mieux est de le faire ici en attendant que je mette en place le système de bug report (trac).
Bon assez parlé, rulez jeunesse.
[/size]
Si ça intéresse du monde je pourrais m'y remettre et bosser sur cette fonctionnalité (bien pratique ).
Le fichier joint contient le projet xcode de l'application test AVEC(*) le source du framework + l'éxécutable seul + une documentation détaillée.
(*) contrairement à la version sur le site web.
A consommer et commenter sans modération. A venir: un plugin pour Interface Builder. Stay tuned.
Merci pour la mise à disposition de votre projet.
Je me permets de vous signaler un problème concernant les architectures : vous avez définit "$(NATIVE_ARCH) ppc" (informations du projet), ce qui marche sous Intel mais pas sous PPC.
La solution serait de définir les architectures "$(NATIVE_ARCH)" en Debug et "ppc i386" en Release.
Cordialement,
Gil.
Cependant je ne comprends pas bien pourquoi un  "$(NATIVE_ARCH) ppc", même inapproprié, ne marcherais pas sur ppc. Normalement ça donnerait ppc & ppc = ppc, non ? Je me demande si le problème ne viendrait pas plutôt du SDK utilisé: 10.4u qui n'est peut-être pas installé sur toutes les versions xCode pour 10.4.
1/ Bonne année à tous, pleine de réussite pour vos objectifs plus ou moins C.
2/ RuleEditor change d'adresse. On peut désormais le trouver chez Googlecode: http://code.google.com/p/ruleeditor/
On peut toujours avoir acces au code grâce à leur dépot subversion (cf l'onglet source). N'hésitez pas à y aller, ça brule pas . C'est un petit projet qui n'est pas encore totalement aboutit mais qui à mon avis se révèlera très utile quand Leopard sera sorti. Les developpeurs verront les nouveaux UI inclus dans 10.5, seront tout contents de les utiliser dans leurs applis mais désespérément déçus de ne pouvoir en faire bénéficier les utilisateurs nombreux qui n'auront pas Leopard. Alors intervient RuleEditor qui rend le concept de NSRuleEditor (10.5) rétro-compatible pour 10.4.
Les contributions sont donc bienvenues d'autant que googlecode comporte une section pour la notification des bugs très facile d'emploi. Ais-je précisé que je donnerai facilement des droits de "commiter" pour subversion ? non ? voilà .
A+.
RuleEditor a désormais atteint une maturité suffisante pour être utilisé dans une application.
Il reste encore quelques fonctionnalités à peaufiner. Notamment l'intégration avec CoreData. Ne serait-il pas enthousiasmant de pouvoir créer des règles à partir des attributs d'une entité CoreData ? Je ne maà®trise pas asez CoreData pour arriver à une solution parfaite. Aussi, je fais appel à des plus expérimentés que moi pour implémenter cette possibilité.
Si vous voulez faire un tour sur http://code.google.com/p/ruleeditor/ et télécharger le code, bien vous en prenne.
Vous noterez dans la classe PSRuleEditorTemplate une méthode: pour, en gros, extraire les NSExpression (sous-parties d'un NSPredicate) à partir d'une entité. Il n'y a plus qu'à remplir avec le code adéquat.
Vos idées ou suggestions sont bienvenues (je rame).
A+. Laurris.
See you.
D'après ce que j'ai compris, chaque critère peut avoir des descendant dans l'arborescence (d'ou les méthodes de delegate et
Ces descendants vont être tous les types de critères possibles et imaginables (en fait les clés pour la racine puis les types et modes de comparaisons pour les différentes clés) De plus, l'appel a la seconde methode va permettre de mettre en place les vues (plus exactement les editeurs) pour chaque critère. Cette vue va être récupérée par la méthode
Enfin, on génére le NSPredicate associé a la vue à partir de la méthode .
En fait, si l'on veut avoir de nouveau critères, il suffit d'éditer le fichier criteria.plist que tu as mis dans l'appli ... (Pour le fonctionnement de la vue elle-meme, je n'ai pas très bien regardé, mais ca a l'air pas mal du tout
Par contre, l'aurais besoin de pouvoir avoir des NSMenu pour les critères (à la place d'un NSTextField). Si je ne me trompe le mieux serait d'implémenter la création de ce NSMenu dans la méthode (2) à partir de nouvelles clés dans le fichier plist. Je vais essayer de faire ca aujourd'hui
Sachant que les 3 premières méthodes sont obligatoires (affichage) et la dernière optionnelle. Concernant le type retourné par la méthode (3), il peut être NSString ou n'importe quoi qui descend de NSView.
NSMenuItem *devrait* être permis ... mais ne l'est pas pour l'instant pour la bonne raison que je ne vois pas ce que ça amènerait en plus par rapport à NSString. Si tu as une opinion là dessus, ça m'intéresse
Sinon, fouf, un doute m'étreint: tu parles de la target TestApp, or le nom actuel est PSRuleEditorTestApp. Est-ce que par hasard tu aurais téléchargé le fichier que j'ai uploadé dans un message plus haut ? Si oui, je te conseille de récupérer plutôt la version actuelle à googlecode et regarder la section "issues" pour voir les priorités de travail (ya aussi une doc !).
A+ Laurris.
J'arrive donc a créer des NSPopUpButton a la place des textFields ou des pickers avec un menu et tout le bazard. Par contre, j'ai un pb au niveau de l'affichage (cf captures d'écran).
Quand j'utilise le code "standard" (cad :
), ca me fait le décalage, et quand je commente la ligne [view setCell:arrowCell];, ca m'enlève le décalage, mais évidemment, je n'ai plus les flèches (y compris quand je commente aussi la ligne pos = NSPopUpNoArrow; ou que je remplace NSPopUpNoArrow par autre chose).
Pourrais-tu me dire comment tu as fait pour les autres popup, pasque en fait, je n'ai pas trouvé dans ton code
PS : si tu pouvais me passer une addresse AIM ou MSN ca serait super
[Fichier joint supprimé par l'administrateur]
Si comme je le suppose tu le crée dans le delegate avec les methodes (2) ou (3) alors je comprends d'où vient le souci de centrage (Criterion.m).
Mais normalement, tu n'as pas besoin de créer toi-même le popup. Il suffit qu'un criterion parent ait plusieurs enfants, c'est à dire que ait une valeur >1 pour que le popup soit créé automatiquement à condition que la méthode (3) renvoie un string.
La création au nveau du delegate n'a d'interêt que dans des cas particulier. Exemple: un popup avec des images dans les menus ou bien un popup avec des inter-menus. Sinon, pour un popup normal, c'est tout cuit.
J'ai mis mon adresse Im dans mon profil. Appelle-moi et je te montrerai comment faire ta règle plus haut en ajoutant juste une entrée dans criteria.plist.
Nota Bene: La raison d'être du code que tu cites c'est qu'il y a un BUG dans le popup "plastic" sous 10.4 qui fout la flèche n'importe où.
Encore 2 truc qui me chagrinent : les + a droite de la vue qui sont "mangés" et un pb avec la NSScrollView (en fait faire un resize automatique qui permet d'avoir une frame dans la scrollview adaptée cad ni trop grande, ni trop petite ...).
Je reposte dès que j'ai terminé
[edit]
Ayez, ai terminé (pour les plus, c'est juste une histoire de taille d'image). Bon, bah je crois que je vais pouvoir retourné à mon programme principal
Merci beaucoup Laurris pour ton travail.