Es ist wirklich schön zu sehen das auch noch an anderen freien Alternativen zu Windows entwickelt wird. Besonders unter dem Aspekt das Vielfalt das wichtigste ist. Werde es mir nachher mal runterladen und genauer anschauen.
Wenn Linux & Co mal irgendwann nicht mehr geek genug und vollkommen von den boesen, profitgierigen, kapitalistischen Konzernen uebernommen wurde, dann gibt es ja immer noch genug Alternativen, mit denen man dann "anders" sein kann.
Was ich unter proprietär verstehe? Stell die Frage nochmal, wenn Du folgendes gelesen hast: (http://www.rebol.com/license.html)
REBOL/Core
REBOL/Core is free and will always be free. It is for educational and general use.
* You can download and copy the software free of charge. * You can redistribute the software free of charge and without notification to us. * You can use this software for any legal use, including commercial uses. * You need not give us credit, but maybe display the REBOL logo? * The software is provided on an "as is" basis, without warranty of any kind. * You cannot modify the software or the license.
Type "license" from the REBOL console to see the specific license details.
Hm, und zusätzlich noch ohne X-Server? Wollen die wirklich *alle* GUI-Applikationen selbst schreiben? Das wird mit der beschränkten Manpower des Projekts nicht klappen. Letztendlich genau das Problem, das Kurt Skauen bereits erkannt hatte.
Außerdem frage ich nach der wirklich revolutionären Idee an AtheOS/Syllable, die eine Abkehr vom evolutionärem Prinzip der Softwareentwicklung rechtfertigen würde. So bleibt nur ein schales "Not invented here...".
mmmhhh, von vorneherein moeglichst plattformunabhaengig schreiben Wenn es POSIX kompatipel ist, und jemand ein bekanntest TK (wxWidget, FLTK, Qt, gtk ...) integriert, wuerden alle unsere GUI-Applikationen (meist wxWidget) laufen (gcc vorausgesetzt).
Wenn ich das richtig verstanden habe, will Syllable ja Applikationskonsistenz bis in die Präsentationebene erreichen. Da wird's nichts mit dem Portieren eines oder mehrerer Widgetsets. Es sind die Widgets zu benutzen, die der GUI-Manager vorgibt.
Also praktisch wie MS-Windows95 mit MFC-Dialogen (Naja, hoffentlich etwas moderner).
Mmmhh, ich sehe das Problem gerade nicht Wenn ich mir wxWidget anschaue benutzen die, unter Linux, das "GTK-Widgetset" bzw. Motif unter Win32 (wenig Erfahrung meinerseits) sieht es sehr nach MFC aus. Allgemeine Funktionen um einen 'Pixel' zu zeichnen wird jede Grafikschnittstelle mit sich bringen (wichtig fuer FLTK). WxWidget hat es auch hinbekommen das MFC-Eventhandling plus Drag 'n Drop und das GTK-Eventhandling plus Drag 'n Drop etc. hinter eine einheitliche Schnittstelle zu bringen. Beim Clipboard kommt meist (FLTK, wxWidget, GTK! Qt?) das "native Clipboard" zum einsatz. So sehe ich nicht das Problem Wrapper zur Syllable-Grafik zu erstellen. Ich will die gewaltige Arbeit nicht kleinreden, ich sehe nur das technische Problem halt nicht.
Evt. kann es mir ja wer erklaeren, sofern eins da sein sollte.
Es ist ja auch kein technisches Problem. Wenn du aber schon so weit gehst, kannst du auch gleich X portieren. Genau das soll ja aber nicht passieren. Alle Programme sollen *gleich* die native Schnittstelle des GUI-Managers von Syllable benutzen. D.h. "nimm den Widgetset, der mitgeliefert wird oder stirb". Außerdem ist Drag&Drop mehr als nur ein Clipboard. Es muss auch sichergestellt sein, dass die eine Anwendung versteht, was ihr die andere mitteilen will. Was beim Clipboard der Bediener sicherstellt, indem er das richtige ausschneidet, macht bei Drag&Drop eine Interfacedefinition -- und die definiert ebenfalls Syllable.
Man kommt also um das Portieren jedes einzelnen Programms nicht herum, es sei denn, man will nur einen Bruchteil der Funktionalität abbilden. Da sind wir doch schon.
stimmt schon. dein gedanke ist auch immer wieder in diskussionen aufgetaucht. du hast auch insofern recht, dass das ganze posix-kompatibel ist und der gcc bereit steht, aber trotzdem lehnen die entwickler eine solche portierung ab (vor allem die von gtk und qt). wenn nämlich so ein port zur verfügung stehen würde, wäre die erstellung nativer programme recht unattraktiv, oder? das eigene 'toolkit' ist dabei durchaus attraktiv, dadurch dass z.B. das ganze gui stark auf threads setzt.
deswegen äußert der maintainer dazu auch immer wieder gerne, dass die portierung eines anderen toolkits in einem so frühen stadium der entwicklung einem schuss in den kopf eines kleinkindes gleichzusetzen wäre ;).
TechnoSlave
Zitat von der Webseite: "The entire source is available via the GPL"
(http://www.rebol.com/license.html)
REBOL/Core
REBOL/Core is free and will always be free. It is for educational and general use.
* You can download and copy the software free of charge.
* You can redistribute the software free of charge and without notification to us.
* You can use this software for any legal use, including commercial uses.
* You need not give us credit, but maybe display the REBOL logo?
* The software is provided on an "as is" basis, without warranty of any kind.
* You cannot modify the software or the license.
Type "license" from the REBOL console to see the specific license details.
> REBOL/Core is free and will always be free.
Warum ? Deswegen:
> * You cannot modify the software or the license.
Wenn es immernoch nicht klar sein sollte, wird es vielleicht hier klarer:
http://www.golem.de/0605/45408.html
Gruss
infognom
Außerdem frage ich nach der wirklich revolutionären Idee an AtheOS/Syllable, die eine Abkehr vom evolutionärem Prinzip der Softwareentwicklung rechtfertigen würde. So bleibt nur ein schales "Not invented here...".
m2c mah
Also praktisch wie MS-Windows95 mit MFC-Dialogen (Naja, hoffentlich etwas moderner).
Evt. kann es mir ja wer erklaeren, sofern eins da sein sollte.
mfg
Mah
Man kommt also um das Portieren jedes einzelnen Programms nicht herum, es sei denn, man will nur einen Bruchteil der Funktionalität abbilden. Da sind wir doch schon.
wenn nämlich so ein port zur verfügung stehen würde, wäre die erstellung nativer programme recht unattraktiv, oder? das eigene 'toolkit' ist dabei durchaus attraktiv, dadurch dass z.B. das ganze gui stark auf threads setzt.
deswegen äußert der maintainer dazu auch immer wieder gerne, dass die portierung eines anderen toolkits in einem so frühen stadium der entwicklung einem schuss in den kopf eines kleinkindes gleichzusetzen wäre ;).