cBasic IDE

worauf werden die GUIs dann basieren ? .Net? WinApi? GTK? QT? oder kann man sogar selbst aussuchen ?

Ich würde GTK empfehlen - es ist weit verbreitet und wird gut unterstützt!

lg Morph

Warum sollte er GTK nehmen? Weil es plattformunabhängig ist? Hm, dann sollte er seinen Interpreter aber nicht in .Net schreiben.

Ich würde stinknormale Winforms verwenden.

.Net bekommt man ja sogar auf Linux zum Laufen - Wine & Winetricks
.Net selbst wäre zu langsam für die Forms - zumindest wenn man dafür VB benutzt... Also GTK ist da schon weitaus besser! QT ist meiner Meinung nach zu schwer... Allerdings habe ich mich damit auch nicht so viel beschäftigt...

Also Nach wie Vor meine Empfehlung: GTK

.Net kann man da vergessen - im Vergleich zu GTK ist die Performance da zu schlecht!


lg Morph

@Morphesus: da kann man sich sicher streiten ... GTK läuft besser unter Unixe oder .Net läuft kaum unter Linux ... ich denke mal man sollte warten was der TE antwortet

Morphesus schrieb:

.Net bekommt man ja sogar auf Linux zum Laufen - Wine & Winetricks
.Net selbst wäre zu langsam für die Forms - zumindest wenn man dafür VB benutzt... Also GTK ist da schon weitaus besser! QT ist meiner Meinung nach zu schwer... Allerdings habe ich mich damit auch nicht so viel beschäftigt...
Also Nach wie Vor meine Empfehlung: GTK
.Net kann man da vergessen - im Vergleich zu GTK ist die Performance da zu schlecht!

Ich glaub kaum, dass es noch einen Performanceuntershcied macht, wenn der Interpreter schon in VB geschrieben ist. Scriptsprachen sind generell nicht immer so toll für GUI-Anwendungen zu gebrauchen.

mal gaaanz langsam hier...

.Net bekommt man ja sogar auf Linux zum Laufen - Wine & Winetricks

Will das jeder? Ist das komplette .Net interpretiert? ->Nein
Und wenn er das machen würde, dann könnte er auch gleich Forms nehmen...

.Net selbst wäre zu langsam für die Forms - zumindest wenn man dafür VB benutzt...

die Forms von welchen man denke ich gesprochen hat laufen nur unter .Net, ansonsten wäre es WinAPI, was vom Prinzip her keinen Unterschied macht...

.Net kann man da vergessen - im Vergleich zu GTK ist die Performance da zu schlecht!

Das ist ganz und gar eine Falschaussage...

Ich würde sagen WinAPI, dann kann er das interpretieren wie er es will und auch entsprechend aufrufbar machen...

Wie wärs, wenn du das in C++ oder gar Assembler übersetzt und dann kompilierst, dann haste etwas wie BlitzBasic, bei entsprechender Übersetzung ist es schnell und auch keine Scriptsprache mehr...

Leute, Leute, ganz ruhig!

Eines ist klar: Ich werde definitiv normale Windows Forms benutzen. Das bietet sich einfach an, da Interpreter und Compiler schon in VB.NET geschrieben wurden.

Ich schätze, dass ich das folgendermaßen machen werde:
In der Library gibt es die Auswahl zwischen Konsolen- und Formanwendung. Bei einer Konsolenanwendung gibt es nur die Standardbefehle (die, die jetzt schon existieren), aber bei einer Formanwendung gibt es zusätzliche Befehle, die das Aufbauen einer solchen erst ermöglichen. Außerdem werden Input und Output verändert (z.B. bei Print wird der Text nicht in der Konsole, sondern in einer MessageBox angezeigt).

Hier ein mögliches Codebeispiel:


Ansonsten geht es hierbei weniger um die IDE, denn die war ursprünglich nur dazu gedacht, mir eine schnelle und einfache Möglichkeit zum erweitern und testen der Funktionen des Interpreters. Ich werde vermutlich nicht großartig daran weiterarbeiten, nur an dem Sprachkonzept selbst bzw. der Klassenbibliothek.

Ich programmiere unter Linux - auch .Net - und habe da reichlich Erfahrung, Kleiner... Wine ist bereits sehr weit entwickelt! Es sei denn du nutzt v0.8 irgendwas Dann siehts wieder anders aus... Also Das .Net Framework lässt sich problemlos installieren und die Anwendungen laufen einwandfrei bei mir.

Und da VB nunmal langsam ist - was wohl kaum einer bestreiten kann - würde ich eher empfehlen auf andere Bibliotheken zurückzugreifen. Und C++ und Assembler können leider nicht alle... ASM ist schwer - glaub mir, ich habe mich sehr viel damit beschäftigt, auch ein kleines OS geschrieben

Auch sind Skriptsprachen SCHNELLER als Kompilierte Anwendungen - noch nie verglichen? Siehe JavaScript vs. VB.Net...

Die WinAPI könnte man noch in Betracht ziehen.

lg Morph

Also klein bin ich erstens nicht, dann habe ich die Entwicklung mit Wine auch schon probiert, es hört schon bei GDI+ bei der kleinen Funktion einen LinearGradientBrush zu zeichnen auf...


VB (meinst du evtl. .Net?!) ist keineswegs langsam, natürlich ist es langsamer als eine Native Sprache, komm aber bitte nicht auch noch mit dem Argument C# ist schneller als VB .Net, dann müsste ich gleich ein weiteres Bild posten. Also wie du merkst ich + viele andere können das bestreiten...
Und ich denke ich selbst weiß wie schwer ASM ist...

Und Scriptsprachen sind NIE im LEBEN schneller als Kompilierte Anwendungen, das mag vielleicht bei dir der Fall sein, aber dann möchte ich deinen Code für diese Programme gleich gar nicht sehen. Der Interpreter von so ziemlich jeder ScriptSprache wird kompilliert sein, wie will der sonst laufen? Noch ein Interpreter?

Also ich habs außerdem noch nie geschafft JavaScript mit VB .Net zu vergleichen, eine Banane ist ja schließlich kein Apfel...
VB .Net ist KEINE kompilierte Anwendung und PUNKT
VB .Net hat viel mehr möglichkeiten als JS und PUNKT

Die WinAPI könnte man in betracht ziehen? Lass mich raten GTK+ ist schneller als die WinAPI? Ganz sicher nicht->GTK+ greift genauso wie QT, die WinForms des .Nets und was es sonst noch so alles gibt auf die Win API Methoden zurück und PUNKT

So genug gepunktet für Heute PUNKT

Morphesus schrieb:

Auch sind Skriptsprachen SCHNELLER als Kompilierte Anwendungen

What.
The.
Fuck.

Du willst uns also ehrlich weiß machen wollen, dass eine Sprache, die erst von einer kompilierten Anwendung verarbeitet werden muss SCHNELLER ist, als die kompilierte Anwendung selbst? Oh mein Got. Mit einem 't', weil ich vor WTF-moments nicht mehr schreiben kann.