Purebasic Zukunft

[c4s]

PureBasic-Entwickler Fred hat sich in einem ähnlichem Thread im englischen Forum zu Wort gemeldet:

[...] Back on PureBasic: yes we are hard at work to ship the new release (which will be an LTS one - yes it's 2 years already). We except it to be out for a beta in august and final in september. It already has a quite big list of new stuffs !

... Also keine Sorge: Es geht weiter!

[thinkitsimple]

Was für ein Quark.

Was für eine Ausdrucksweise. Gewöhn dir mal einen anderen Tonfall an. Erweitere deinen Horizont und du wirst feststellen, dass es in anderen Cross-Plattform Entwicklungsumgebungen (z.B. Xojo, ehemals RealBasic und Real Studio, welches sehr viel teuer ist) ebenfalls nicht anders ist. Auch dort gibt es auf den unterschiedlichen Plattformen unterschiedliche Fehler, die es auf den anderen Plattformen nicht gibt. Und auch dort werden diese Fehler teilweise über längere Zeit nicht behoben. Wenn man dann noch den Preis und die Größe des Xojo-Teams im Vergleich zu PureBasic bedenkt, sollte einem klar werden, dass wir mit PureBasic nicht so schlecht dran sind. Meine Erfahrung nach vielen Jahren: Crossplattform-Entwicklung ist eine Illusion, die wenn überhaupt nur mit viel Anpassung, API-Zugriffen etc. zu bewerkstelligen ist.

[Kukulkan]

Wir haben verschiedene Programme in PureBasic entwickelt und liefern die heute für Windows, Linux und MacOS aus. Alle diese nutzen ZIP-Kompression mit zlib, libcurl und anderes. Ja, wir haben verschiedene Includes für die Plattformen und auch einige CompilerIf's. Aber im Großen und Ganzen ging es. Allerdings haben wir viele CompilerIf's nur für Workarounds um PB bugs. Auf die hätte ich schon gerne verzichtet. Welche Bugs das sind, habe ich ja bereits aufgelistet... Da würde ich gerne mal aufräumen können. Alleine die Workarounds um XML Dialog und OptionGadgets sind recht komplex...

[Sven]

Alleine die Workarounds um XML Dialog und OptionGadgets sind recht komplex...

Soweit ich das gesehen hab, gehts da aber um kosmetische Dinge wie mal eine andere Hintergrundfarbe für ein Gadget.

Dazu mußt Du aber nicht Cross-Plattform programmieren. Da reichen schon verschiedene Windows-Versionen.

Oder kann mir einer erklären, warum in XP das ScrollArea-Gadget oder das Container-Gadget eine andere Hintergrundfarbe haben müssen als das Panel-Gadget, auf dem ich sie platziere? Ich bin mir ziemlich sicher, daß das eine Windows-Macke ist. Wenn man das nicht will, muß man sich wohl seine eigene Gadget-DLL basteln. Die hat dann wieder andere Macken.

[Kukulkan]

Nein, es geht darum dass die OptionGadget-Gruppe nicht funktioniert wenn im XML Dialog noch andere Gadgets dazwischen liegen (Beispiel http://www.purebasic.fr/english/viewtop ... 13&t=57212). Fred hat das Problem im Thread bestätigt (Oktober 2013), aber bis heute nicht gefixt.

[NicTheQuick]

Was für ein Quark.

Was für eine Ausdrucksweise. Gewöhn dir mal einen anderen Tonfall an.

Entschuldige. Das war keinesfalls herablassend gemeint.
Ich teile nur nicht deine Meinung in der Hinsicht. Das Argument, dass es anderswo auch nicht gut klappt mit der Plattformunabhängigkeit lasse ich auch nicht gelten.

[Sven]

Nein, es geht darum dass die OptionGadget-Gruppe nicht funktioniert wenn im XML Dialog noch andere Gadgets dazwischen liegen (Beispiel http://www.purebasic.fr/english/viewtop ... 13&t=57212). Fred hat das Problem im Thread bestätigt (Oktober 2013), aber bis heute nicht gefixt.

Möp! Du hast Dich aber schon mal mit OptionGadgets beschäftigt? Es ist IMMER so, daß eine neue Gruppe aufgemacht wird, wenn dazwischen ein anderer Gadgettyp kommt. Das kann man normalerweise umgehen, indem man die OptionGadgets zusammenhängt und die Koordinaten entsprechend setzt. Geht halt bei XML Gadgets nicht, da keine Koordinaten.

Woher soll denn der Compiler wissen, ob Du das in einer Gruppe oder als getrennte Gruppen willst. Der kann ja nicht in Deinen Kopf gucken.

Hat Dir aber Fred auch schon so geschrieben.

[Kukulkan]

Sven,

mir ist total egal wie Fred oder XMLDialog oder das OS das macht. Wie ich Fred vorgeschlagen habe wäre ein zusätzlicher Gruppierungs-Parameter eine gute Lösung. Und Fred schreibt dann auch "But you are right, it should have an option to create easily groups in XML.".

So, Fakt ist also dass PB nicht mal einfachste GUI mit Option-Gadgets schafft. Ich musste das dann mit einer menge Code umschiffen (übrigens für alle drei Plattformen anders). Fred kennt das Problem und fixt es für zwei Jahre nicht. "Das geht halt nicht" ist IMHO keine akzeptable Antwort auf ein grundlegendes Problem. Weitere Lösungsvorschläge oder dazu spezifische Ideen kann man ja gerne in dem Thread diskutieren.

[Sven]

Fakt ist also dass PB nicht mal einfachste GUI mit Option-Gadgets schafft.

Klar geht das. Und genauso wie Du das willst. Nur halt mit den Gadgets aus der Gadget2D-Lib und da sicher auch plattformübergreifend, und nicht mit den XML-Gadgets. Warum auch immer Du stattdessen die XML-Gadgets verwendest - die es vor einiger Zeit noch gar nicht gab -, ist das ein hausgemachtes Problem.

Und ich könnte mir einen ganz einfachen Grund vorstellen, warum Fred das nicht implementiert: Weil es nicht so einfach ist. Die XML-Gadgets sind meinem Verständnis nach nur eine Vereinfachung für den Aufbau. Statt für jedes Gadget die Position und Größe angeben zu müssen, berechnet PB Dir diese anhand der Fenstergröße und der Spalten und Zeilen, in denen die Gadgets liegen. Die Position ist aber im XML klar definiert, da gibts kein "und jetzt mach nochmal 2 Zeilen weiter oben was hin". Und bei den Gadgets gibts keine Info "Du gehörst zu der Option-Gruppe". Eine Option-Gruppe ist mit der Wahl eines anderen Typs beendet, fertig. Für Deine Extrawurst müßte er wahrscheinlich das ganze Gadget-XML-Konzept über den Haufen werfen.

Nimm halt einfach die Gadgets aus der Gadget2D-Lib, wo ist das Problem?

[Shardik]

So, Fakt ist also dass PB nicht mal einfachste GUI mit Option-Gadgets schafft. Ich musste das dann mit einer menge Code umschiffen (übrigens für alle drei Plattformen anders).

Ich verstehe ehrlich gesagt nicht, was an dem Problem so schwierig sein soll und warum man dafür eine Menge Code benötigt, der zudem auf allen drei Plattformen unterschiedlich sein soll. Warum beherzigst Du nicht Freds Vorschlag, dieses Problem mit Code etwa in der folgenden Form zu lösen, die gerade einmal 11 zusätzliche Code-Zeilen benötigt und die zudem in keiner Weise plattformspezifisch ist:

Code: Alles auswählen

CompilerIf #PB_Compiler_Unicode
  #XmlEncoding = #PB_UTF8
CompilerElse
  #XmlEncoding = #PB_Ascii
CompilerEndIf

#Dialog = 0
#Xml = 0

XML$ = "<?xml version='1.0' ?>"+
       " <window id='#PB_Any' name='test' text='Gridbox' minwidth='auto' minheight='auto' flags='#PB_Window_ScreenCentered | #PB_Window_SystemMenu | #PB_Window_SizeGadget'>"+
       "   <gridbox columns='2' colexpand='item:2'>"+
       "     <option name='cboProxy1' colspan='2' text='Keinen Proxy verwenden'/>"+
       "     <option name='cboProxy2' colspan='2' text='Proxy Server verwenden (server:port):'/>"+
       "     <empty width='10'/><string name='strProxyURL' minwidth='250' />"+
       "     <option name='cboProxy3' colspan='2' text='Proxy Autoconfiguration File (PAC) verwenden:'/>"+
       "     <empty/><string name='strProxyPACURL' width='250' />"+
       "     <hbox  colspan='2'>"+
       "                 <button name='btnOK' text='OK' />"+
       "                 <button name='btnCancel' text='Abbruch'/>"+
       "              </hbox>"+
       "   </gridbox>"+
       " </window>"

If CatchXML(#Xml, @XML$, StringByteLength(XML$), 0, #XmlEncoding) And XMLStatus(#Xml) = #PB_XML_Success
 
  If CreateDialog(#Dialog) And OpenXMLDialog(#Dialog, #Xml, "test")
   
    Repeat
      Select WaitWindowEvent()
        Case #PB_Event_CloseWindow
          Break
        Case #PB_Event_Gadget
          Select EventGadget()
            Case DialogGadget(#Dialog, "cboProxy1")
              SetGadgetState(DialogGadget(#Dialog, "cboProxy3"), #False)
            Case DialogGadget(#Dialog, "cboProxy2")
              SetGadgetState(DialogGadget(#Dialog, "cboProxy3"), #False)
            Case DialogGadget(#Dialog, "cboProxy3")
              SetGadgetState(DialogGadget(#Dialog, "cboProxy1"), #False)
              SetGadgetState(DialogGadget(#Dialog, "cboProxy2"), #False)
          EndSelect            
      EndSelect
    ForEver
  Else
    Debug "Dialog error: " + DialogError(#Dialog)
  EndIf
Else
  Debug "XML error: " + XMLError(#Xml) + " (Line: " + XMLErrorLine(#Xml) + ")"
EndIf

Ich vermute einmal, dass Fred eine native Lösung in PureBasic für relativ aufwendig hält und es in seinen Augen wahrscheinlich Probleme in PureBasic gibt, denen er eine größere Priorität einräumt, zumal Dein Problem sich ja anscheinend relativ einfach per Code lösen läßt.