PureBasic

Moi je vois ce que tu veux dire G-Rom, mais dans le principe, rien ne nous empêche de développer des libs OpenSource pour purebasic, même si ce n'est pas des libs officiels, je trouverais sa sympa d'ailleurs une communauté de codeur de lib purebasic. Ce qu'on ne peut pas faire ce sont les suggestions qui visent la syntaxe et fonctionnalités de base de purebasic (je pense notamment au type boolean). Je suis ta logique G-Rom ; Fred, seul tu vas avoir du mal à tourner la tête de tout les côtés, on peut d'hors et déjà avoir pleins d'utilisations de Purebasic, les suggestions suivent les besoins (qui se créer en fonction des possibilités offert par le logiciel), et les besoins pour un logiciel bureautique ne sont pas les mêmes pour un jeux vidéo, et là, on arrive à un moment où tu n'incluras pas beaucoup de suggestions (et c'est normal), mais pour moi c'est dommage, car rien que sur la TODO List présente en première page, il n'y a pas beaucoup de suggestions a 'jeté' (je dis sa pas méchamment, je penses au suggestion que l'on peut déjà faire facilement en magouillant un peu) et donc sa fait beaucoup de boulot.

@ G-Rom, strombretrooper

+1

L'idée serait de produire en open source des libs ou des gadget nouveaux.
une syntaxe de base serait obligatoire. Le canevas de cette syntaxe serait fournie par les créateurs de PB.
dans les forums deux rubriques de plus lib et gadget.
L'auteur des softs s'engagerait automatiquement a accepter qu'a la demande de Fred sont travail devienne produit officiel PB.
Il me semble qu'avec une telle ouverture, notre logiciel fétiche y gagnerait grandement.

salut

Quand vous parlez de lib open sources, on ne peut pas déjà le faire ?
Par exemple, la droopy lib ?

Quelles seraient la différence avec les lib dont vous parlez ?
Certaines fonctions de PB seraient ouvertes et on pourrait faire plus de choses, c'est ça ?

Si oui, ces idées de lib open-source et de possibilités d'ajout de gadgets sont d'excellentes idées je pense, mais il faudrait voir comment cela pourrait fonctionner .

Ca me fait un peu penser aux systèmes de scripts de Blender :
- ce qu'ils font à la blender foundation (BF), c'est que lorsqu'un script développé par un dev externe leur semble très intéressant (ici, ce serait une lib ou un gadget), ils décident de l'intégrer dans la version officielle.
Le script fait alors partie de la release officielle et c'est la BF qui le met à jour à ce moment-là (ou le dev s'il veut bien continuer). Si à un moment, elle le décide, elle peut aussi arrêter de le mettre à jour. Par exemple, parce qu'elle a conçu un nouvel outil plus intéressant.

Je vois à cette méthode plusieurs avantages :
- on voit très régulièrement beaucoup de nouvelles fonctions (grâce aux scripts) intégrées à blender.
- les devs du programme principal (blender) gagnent du temps sur certaines fonctions car d'autres développeurs les développent à coté (sous forme de scripts). Mais cela ne les empêchent pas par la suite d'ajouter cette fonction directement dans blender, le script pouvant leur donner des idées ou servir de "base" de réflexion.
- la mise à jour des scripts intégrés dans la release se fait ensuite soit par le dev officiel du script, soit par un autre dev qui le veut bien, soit par un dev de la BF.

Imaginons un système de plug ins pour gadgets ou lib fourni par Fred :
- un dév intéressé développe par exemple une lib ou un nouveau gadget.
- beaucoup d'utilisateurs trouvent que c'est génial
- Fred (ou la pb team) le teste, le trouve super aussi, et décide d'intégrer cette lib ou ce gadget à la version officielle : cette lib devient donc propriété de purebasic. Et voilà, il a plein de nouvelles fonctions assez rapidement. Maintenant, cette lib/ce gadget sera mis à jour soit par le dev de la lib d'origine, soit par un nouveau dev qui veut le faire, soit par la pb team qui de toutes façons s'ils l'avaient ajouté à purebasic l'auraient mis à jour . De plus, ils peuvent aussi décider à un moment d'arrêter de mettre à jour cette lib ou ce gadget, pour diverses raisons, comme ils le feraient avec d'autres fonctions.

Donc, tout le monde est gagnant au final .

Sinon, pour rebondir sur ce qu'a dit Fred :

PureBasic est avant tout un outil pour débutants, que je vois comme une passerelle vers un monde plus compliqué comme le C/C++.

ah mais non, le pure est un vrai langage en soi, avec des possibilités très professionnelles .
Purebasic ne s'adresse pas uniquement aux débutants, il est facile d'accès pour eux, c'est différent .
Je veux dire par là que Purebasic est un langage qui s'adresse autant aux débutants qu'aux professionnels, car ses performances sont excellentes, ses fonctions sont nombreuses, et le temps de développement est très réduit comparé à d'autres langages.

Et puis, on n'a pas forcément envie de se mettre au c/c++ (surtout moi), mais on veut continuer à développer avec purebasic, même en progressant et en devenant hyper balèze .

(oui, un jour, je serai hyper balèze en dev )

blendman
+1
C'est exactement ce que j'ai voulu dire.
Exemple: CheckBoxGadget, et OptionGadget dont la couleur de fond n'est pas changeable dans les gadgets d'origine, mais ou il est facile de le faire grace a une api. Certainement que la Team n'a pas eu le temps de faire ces changements, qui pourrait être proposé par d'autres et intégré a PB.

Michel

MLD a écrit :Exemple: CheckBoxGadget, et OptionGadget dont la couleur de fond n'est pas changeable dans les gadgets d'origine, mais ou il est facile de le faire grace a une api. Certainement que la Team n'a pas eu le temps de faire ces changements, qui pourrait être proposé par d'autres et intégré a PB.

heureusement, Gnozal est là et c'est possible avec l'excellente lib purecolor .

Par contre, je ne sais pas si c'est multi-os cette lib.

L'intérêt des libs serait aussi dans l'ajout de fonction comme :
- zoom_image(image, zoom_x,zoom_y,[flag]) (flag = les mêmes que resize)
- zoom_canvas(image, zoom_x,zoom_y,[flag]) (flag = les mêmes que resize)
- set_canvas_color(#gadget, color, alpha, imageID(#image)) ; alpha permet de régler la transparence du fond (canvas avec alpha donc), imageID(#mage) serait le fond qu'on pourrait mettre, par exemple un checker comme dans photoshop
etc ...

Bien sûr, on pourrait trouver de nombreuses choses intéressantes pour ces libs et autres ajouts de gadgets .

Je post içi pour la TODO list même si c'est très en retard, c'est toujours d'actualité.

Je suis en train de rendre un de mes projet multilangage, et paf d'un coup je tombe sur un problème.
Je ne crois pas qu'il est possible de lister les gadgets créés, et pourtant ça autoriserais bien des possibilités, de plus à mon avis ça doit être fait en interne avec les gadgetlist.

Donc : les mêmes fonctions que pour les GadgetItems :
avec en plus : voila, ces ajouts permettrais à mon avis une souplesse dans le code inégalée, et ne demande pas énormément de boulot (non, pas taper, Fred )
faudrait juste rendre l'accès possible à la gadgetlist

Je ne comprend vraiment pas pourquoi il manque ces 2 commandes (EnumerateGadget() est possiblement remplaçable par OpenGadgetList())
Alors que GadgetType() existe ?????

@KKC : fait une maj de ta liste de miracle ^^, il me semble que certain ont été réalisé depuis le temps ^^

graph100 a écrit :@KKC : fait une maj de ta liste de miracle ^^, il me semble que certain ont été réalisé depuis le temps ^^

Je confirme, il me semble que ce qui suit est opérationnel :
38/ Pouvoir enfin ajouter une liste chainée/Map/tableau dans une structure

Ceci est réalisable via une lib :
59/ Un designer plus élaboré >> Pureform
3/ Bouton pouvoir lui donner des couleurs, comme les autres gadgets >> purecolor

Sinon, je suis d'accord avec ces souhaits, je trouve que ces ajouts seraient très appréciables :

Par ordre d'importance en ce qui me concerne :
- Important :
35/ Plus d'événements sur les gadgets du type #PB_EventType_RightClick_Up ,#PB_EventType_RightClick_Down au lieu d'un #PB_EventType_RightClick, idem pour les double click, etc.
NOTE blendman : j'ajouterai même avoir des event généraux comme le #WM_LBUTTONUP et #WM_LBUTTONDOWN (et right et middle). pour pouvoir faire des applications multi-plateformes plus facilement
36/ Il faudrait aussi des événements claviers (Pas des raccourcis et pas du mode console).
62/ Un type boolean
82/ Des FLAGS de MessageRequester parametrables, comme dans GfaBasic
70/ Des déclarations de procedure à l'intérieur de procedure comme le pascal, c le fait aussi il me semble
75/ Des fonctions sur les sprites/sprites3D et les images beaucoup plus simples

- Moyen :
67/ un gadget 'grille' (ou createtableau())
69/ Les doubles inégalités : " 2 < x < 5" au lieu de "x > 2 And x < 5"
1/ Fonction de gestion des GIFS (UseGIFImageDecoder) : gifs et gifs animés >> réalisable avec une lib, mais en natif ce serait pas mal


- peu important (pour moi), mais très utile quand même :
2/ Retour à la ligne possible pour une instruction longue dans l'ide
19/ Connaître et fixer (Get/Set) le nom de la police, la taille, le style et la couleur d'une
police (par défaut, ou d'un gadget), sans passer par la boite de dialogue : FontRequester(...).

Voici quelques ajouts qu'on pourrait faire sur cette liste :

->Images et canvas :
97/ Ajouter un zoom sur les images gadgets : zoom_Image(#imageGadgets,zoomX, zoomY[,flags]) > les mêmes flag que resize

98/ ajouter un zoom sur le canvas : zoom_canvas(#canvas,zoomX, zoomY[,flags]) > les mêmes flag que resize
Je tiens à préciser qu'un zoom ce n'est pas un resize .
ResizeImage() agrandit l'image, et donc on augmente tout : le nombre de pixel de l'image, et donc le poids de l'image, et le cpu, la ram nécessaire, etc..

99/ pouvoir définir la couleur ou le fond du canvas ainsi que sa transparence : set_canvas_color(#gadget, color, alpha, imageID(#image)) ; alpha permet de régler la transparence du fond (canvas avec alpha donc), imageID(#mage) serait le fond qu'on pourrait mettre, par exemple un checker comme dans photoshop

100/ avoir une fonction drawAlphaImage(#image, x,y,width,height,alpha) avec le choix de la taille, comme drawImage(#image, x,y,width,height)

-> sprites/sprites3D
101/ Sprite3D et sprite : pouvoir définir le hotspot (ou point chaud, ou centre) du sprite. Il est par défaut en (0,0), ce qui est embétant pour certaines transformations de sprites/sprites3D (je sais qu'on peut le faire manuellement avec diverses procédures, mais en natif, ce serait mieux).

-> Remarque : Screen et tablette graphique
Il y a un bug lorsque l'on utilise le screen et une tablette graphique : la souris part dans tous les sens. Je crois que ce serait assez compliqué à régler à mon avis, mais bon, je poste juste cette remarque au cas où .
C'est dommage, cela empéche d'utiliser un screen pour une application de dessin par exemple et du coup, on passe à coté des srpite et sprite3D.

Voilà pour mes quelques souhaits .

Ah oui, sinon, j'ajouterai bien :
- intégrer Gnozal dans la PB team .

@Graph100
C'est fait

Je confirme, il me semble que ce qui suit est opérationnel :
38/ Pouvoir enfin ajouter une liste chainée/Map/tableau dans une structure

Tu es sur ou il te semble ???
Car ça je n'ai jamais essayé ...

Ceci est réalisable via une lib :

Ce sont des souhaits, pour PB natif.
C'est sur que si on rajoute les libs entre celles que l'on connait et celle qu'on connait pas, on pourrait en virer pas mal
On pourrait même en rajouter, comme la gestion des objets COM grace a SROD et TsSOFT etc .......

@BLENDMAN
C'est fait aussi
Au passage merci de m'avoir mâché le travail

Pour le souhait 38, c'est sur :
[edit] (précise dans ma partie que c'est les fonctions pour lister les gadgets d'une gadgetlist, je ne crois pas avoir été clair avec l'histoire des gadgetitems )

Ayaaaaii !!!

71/ Pouvoir annuler un DL/Upload

Cette fonctionnalitée a été ajoutée

tu as un exemple ? j'ai peut-être pas la bonne version de la doc et je trouve pas

AbortFTPFile(#Ftp) de la lib FTP.

KCC : tu devrais mettre :
- en rouge : ce qui n'est pas encore intégré
- en vert ce que l'on peut faire avec une lib, mais n'est pas en natif
- en noir ce qui intégré à Purebasic

Ce serait tiptop pour mieux voir l'évolution des souhaits .

EDIT :
pour mon souhait N°100, tu peux ajouter ce flag que j'ai oublié :

100/ avoir une fonction drawAlphaImage(#image, x,y,width,height[[,alpha][,Flags]) avec le choix de la taille, comme drawImage(#image, x,y,width,height). Le flag serait le même que celui de resizeImage()

Hello Kcc,

Tu peux supprimer la 66/ sachant qu'il y a les modules.

66/ Le midi en natif, comme ça, dans les jeux, on utilise le format wave pour les bruitages et le midi pour la musique !

Hasta la vista !