Mono hat durchaus seine berechtigung. Wenn M$ tatsächlich auch bei den "normalen" Windoof Applikationen zukünftig noch mehr auf .net setzt werden dank mono vermutlich beide welten wesentlich kompatibler als dies mit wine bisher möglich ist/war.
von der Sache her ist mono/.gnu/.net sowas ähnliches wie java (+ anhängsel ) Man kanns also einma kompilieren und es läuft danach auf den unterschiedlichsten Systemen. Zumindest wenn die freien Implementierungen davon mal fertig sind. Derzeit müssen grafische Applikationen leider noch auf Wine zurückgreifen um "System.Windows.Forms" aufrufe irgendwie nachzubilden.
dazu wird das ganze dann auch noch nativ aussehen wenns ma fertig is afaik. Sowas schafft java höchstens mit awt und das ist dann nicht mehr bei der Java VM dabei und muss wieder manuell nachinstalliert werden...
Von Karl Martell am Do, 3. Februar 2005 um 08:31 #
AWT muss auch dabei sein, weil Swing damit seine Widgets zeichnet, deshalb ist es auch so lahm! Deine Aussage ist in etwa das gleiche wie: Ich brauche keine Grafikkarte mehr, ich hab ja jetzt OpenGL/Direct3D. Windows.Forms sollte auch keiner wollen, denn damit wird man angreifbar. QT# oder GTK# als plattformunabhängige Lösung ist der einzig gangbare Weg!
-Zitat- dazu wird das ganze dann auch noch nativ aussehen wenns ma fertig is afaik. Sowas schafft java höchstens mit awt und das ist dann nicht mehr bei der Java VM dabei und muss wieder manuell nachinstalliert werden... -/Zitat- Also mit AWT wirds keines Falls nativ aussehen, denn eine einheitliche Oberfläche auf allen Systemen ist ja Sinn und Zweck von AWT. Anders siehts da mit SWT aus dem Eclipse-Projekt aus. IMO benutzt das native GUI-Routinen sprich die Widgets des darunterliegenden OS.
Von Kevin Krammer am Do, 3. Februar 2005 um 16:23 #
Also mit AWT wirds keines Falls nativ aussehen, denn eine einheitliche Oberfläche auf allen Systemen ist ja Sinn und Zweck von AWT.
Da verwechselst du jetzt AWT mit SWING. SWING ist bei gleichem Look&Feel auf allen Plattformen gleich, AWT benutzt für sein Widgets Native Peers, also Gegenstücke der darunter liegenden Plattform, bzw eines darunter liegenden Toolkits.
Von Michael Flaig am Do, 3. Februar 2005 um 10:39 #
Du hast vergessen, dass .net nicht komplett offen ist. die windows forms gibts auch in .net und sind patentiert. solange also nicht alle windows entwickler auf mono oder ähnliches umsatteln sondern microsofts .net verwenden kann man die anwendungen genausowenig portieren wie heute normale win32 anwendungen. um platformübergreifend zu programmieren ist mono die bisher beste möglichkeit. so habe ich das zumindest verstanden ...
die windows forms api in .net ist teil vom ecma standard. im momment wird das zeug gerade implementiert und zwar native. den ansatz mit wine hat man wieder fallengelassen.
gestern gab es einen msdn webcast, in demgezeigt wurde, wie eine (zugegeben sehr einfache) .net windows forms anwendung mit .net kompiliert und das file ohne neukompilierung unter redhat 9 mit mono gestartet werden konnte.
> Derzeit müssen grafische Applikationen leider noch auf Wine zurückgreifen um "System.Windows.Forms" aufrufe irgendwie nachzubilden. Das sehe ich anders. Bei PortableDotNet musste ich kein wine installieren und konnte trotzdem System.Windows.Forms verwenden.
Manche posten hier auch schwer einseitig: 1. Ist es nicht nur Mono, dass .net implementiert, sondern auch das GNU Projekt mit der PortableDotNet und 2. Ist Java nicht mehr nur von Sun kontrolliert (siehe GNU Classpath und die vielen Freien VMs)
Da hast du etwas falsch verstanden. Die Pakete in Fedora Extras stammen nicht von Red Hat. Erst einige wenige sind von Red Hat. 99% kommen aus dem ehemaligen "Fedora Linux" Projekt (http://fedora.us) und freshrpms.net. Mono war dort noch nicht vorhanden. Erst *wenn* Mono tatsächlich zur Debatte stand *und* Red Hat ein Wort mitgeredet hat (z.B. zu rechtlichen Bedenken), *dann* könntest du von einem Wehren sprechen.
Haltet Euch von Mono fern. Je weiter die Projekte fortgeschritten sind, desto größer wird das Heulen, wenn M$ irgendwann die Hand aufhält und sagt ... ."Tja, sorry... Patente ..., aber wissen Sie, der Portierungsaufwand auf Windows ist ja gar nicht soo groß...zahlen Sie uns einfach den Verlust, den wir dadurch hatten, dass sie nicht von vornherein Windows benutzt haben und bessern Sie sich!"
Das ist doch Quatsch. Mono ist primär eine Implementation eines ECMA Standards und nicht von .NET. Natürlich wird eine maximale Kompatiblität zu .NET angestrebt.
.NET ist auch aus der Lage entstanden, dass Sun MS verboten hat, eine eigene Version von Java zu erstellen. Würde man deiner Argumentation folgern, dann kann Sun jetzt kommen und MS auf die Finger klopfen - Können sie aber nicht.
Genausowenig wird MS kommen und Mono verbieten.
Dass Patente ein Problem darstellen ist aber trotzdem richtig. Dieses Problem hast du aber unabhängig von Mono.
Mono ist mir viel lieber als zB Java. Bei Java hast du Sun, welches Java kontrolliert. Man kann zwar zu Sun gehen und Vorschläge machen, aber am Ende ist immernoch Sun da. Und Java ist nicht frei. Mono ist frei und das ist auch gut so. Wenn man mit Java GPL Software schreiben will, dann muss man sich bewusst sein, dass der User unfreie Software nutzten muss, wenn er die Software nutzten will.
Mono hat einen Zustand erreicht, in dem es stabil und zuverlässig ist. Es fehlt - zumindest unter Betriebssystem mit Gnome, Gtk usw - eigentlich an nichts. Die Anwendungsentwicklung ist schnell und effektiv. Zudem hat man die Vorteile einer Umgebung mit GC.
Meiner Meinung nach ist Mono eine ideale Sprache, um unter Linux Desktopanwendungen zu Entwickln. Ich sehe grosse Chancen für die Sprache, C/C++ in der Linux-GUI-Entwicklung zu verdrängen. Ähnliche Chancen sehe ich zB für Python.
Nicht von Mono fern bleiben, sondern darauf zugehen und von der Technologie profitieren. Mono ist gut und hat Zukunft.
PS: Auf MSDN gab es gestern sogar einen Webcast über Mono. Da wurde eine WinForm Anwendung ohne neu zu kompilieren auf Redhat 9 laufen gelassen. Auf http://www.go-mono.com/monologue gibt es einen Bericht dazu. Wie es aussieht ist MS sogar froh darum, dass es Mono gibt. Mono zu verbieten - falls MS es könnte - würde ja auch nicht viel Sinn machen, Mono nützt MS mehr, wenn es existiert.
Selten so einen Haufen Mist gelesen. Schäm dich! Wenns die wirklich ernst wäre mit freier Software (M$-Evangelist), dann würdest du wissen, dass man mit Java durchaus - und zwar weit besser als mit Mono - freie Software entwickeln kann: GCJ, CLASSPATH, KAFFE, etc. Das bewährteste Stück an open.NET ist doch die Java VM ...
> Dass Patente ein Problem darstellen ist aber trotzdem richtig. Dieses Problem hast du aber unabhängig von Mono. Ach so ist das... Problem erkannt - Problem gebannt oder was???
Hä? Wo gibts bei .NET/Mono ne Java VM? Es gibt die CLR. Klar gab es das Prinzip auch schon bei Java, bei anderen Programmiersprachen übrigens ebenfalls.
Von Kevin Krammer am Do, 3. Februar 2005 um 17:37 #
Wie es aussieht ist MS sogar froh darum, dass es Mono gibt
Das Problem ist, warum MS froh darüber ist.
So wird nämlich der Anschein gewahrt, dass es sich nicht um Windows bezogene Technologie handelt, d.h. im Moment stimmt das mehr oder weniger sogar.
Sobald sich die Erkenntnis, dass .NET auch auf anderen Plattformen verfügbar ist, besonders für Serverkompontenten auf Linux, werden einige Softwarehersteller .NET in Betracht ziehen, wenn serverseitige auch anderes als Windows im Einsatz oder zumindest geplant ist.
Aber wie die Geschichte mit Java zeigt, wird MS dann ihre Extensions erschaffen und sie nicht als Zusatzbibliothek zum Download anbieten, sondern mit ihrem Standard SDK ausliefern.
Diese Extensions werden dann entsprechend "abgesichert" sein (technisch und rechtlich), damit sie nicht auf anderen Plattformen implementiert werden können.
Wie bei MS Java werden dann unzählige Entwickler in diese Falle tappen und unwissentlich zw durch Unaufmerksamkeit wieder Windows-Only Software produzieren.
Wenn dann der Fall eintritt, dass man gerne gewisse Produkte zB unter Linux einsetzten möchte, wird man aufwachen und sehen, dass damit große Kosten verbunden sind, weil Teile der Produkte neu implementiert werden müssten.
Mono sollte darauf achten, nicht .NET für Linux zu sein, sondern einfach eine Plattform mit ähnlicher Technologie aber eigenständig.
Von Kevin Krammer am Fr, 4. Februar 2005 um 12:03 #
Das ist für die meisten Leute kein Unterschied.
Solange es heißt "Mono's .NET implementation is based on the ECMA standards...", ist Mono eine .NET Implementation.
Und .NET ist nunmal praktisch im Sprachgebrauch äquivalent zu MS .NET
Ich denke es besteht gar kein Interesse sich von MS .NET zu distanzieren, die Leute, die auf den .NET Hype Zug aufspringen, sollen ja Mono als äquivalente Plattform sehen.
Von Jochen Schmitt am Do, 3. Februar 2005 um 13:19 #
Wer Mono haben will, sollte am besten ein RfE in Bugzilla (http://bugzilla.redhat.com, Produkt Fedora Extra) einstellen. Wenn er dann noch Source-RPMs auf einen Webspace hochtlädt, sollte dies kein Problem darstellen.
Soweit ich weis, gibt es dann einen QA-Prozess, bei dem noch einmal ein Build mit dem RPM-Packet durchgeführt wird. Wenn man diesen Build dann abgenommen hat, wird das Paket im Repository veröffentlicht.
> Wir sind tief beschämt über die Verzögerung und wir geben uns in die > Hand der Gemeinschaft und bitten um Verzeihung«, heißt es in der > Ankündigung.
So tief beschämt können die nicht sein. Einen ClamAV 0.71 anzubieten, der einen beim ersten Patternupdate sofort als 'outdated' begrüßen wird, ist IMO beschämender, als ihn garnicht anzubieten.
Die Organisation und die Produkte der einzelnen Paketentwickler sind zwei verschiedene Dinge. Eine Ankündigung zu verzögern, weil einzelne Pakete möglicherweise nicht die absolute neuesten sind, wäre töricht. Im Fedora Extras CVS unter http://cvs.fedora.redhat.com findet sich bereits das Update für Clamav.
Gibt's leider noch nicht im Fedora Extras-Paket, aber als leicht zu kompilierendes .tgz: Cinepaint 0.19 (wie Gimp mit Support für 16bit/Farbkanal und Colour-Management)
(Wessen Distribution eine liblcms in Version <=1.13 mitbringt, der benötigt folgenden Patch: http://cvs.sourceforge.net/viewcvs.py/cinepaint/cinepaint-project/cinepaint/app/cms.c?r1=1.3&r2=1.4 )
Ist zwar n bissel OT, aber ich würde mal die Zukunft von Cinepaint interesieren.
Die Cinepaint Leutz wollen das Ding ja auf FLTK portieren und die Gimp Leutz planen in Version 3 (falls es hinhaut) GEGL zu nutzen, was es GIMP erlauben würde mehr als 8 Bit pro Kanal zu nutzen.
Da die letzte Version von Cinepaint schon etwas rudimentär (ok ist noch gtk1) war würde mich mal interesieren ob deren Projekt auf dauer überhaupt eine Chance hat falls GIMP im Kern mit ihnen gleichzieht.
Vorab: Cinepaint 0.19 macht hier einen sehr viel ausgereifteren Eindruck als 0.18.x
Klar, irgendwann wird auch Gimp 16bit/Kanal bieten, Krita wird dies etwas davor (oder danach) auch bieten.
Derzeit ist meines Wissens aber Cinepaint das einzige freie Programm, das * RAW-Bilder mit voller Farbtiefe importieren kann, * mit 16bit/Kanal umgehen kann * und Farbmanagement unterstützt.
Alternativ kommt für Digitalkamerabesitzer eigentlich nur Bibble in Betracht, wenn man eine gute Raw-Unterstützung braucht.
Wegen Cinepaint mache ich mir keine Sorgen, das hat den Schwerpunkt auf Filmbearbeitung und wird kontinuierlich weiterentwickelt. Wenn Gimp 16bit/Kanal und brauchbares Farbmanagement bietet, kann man ja wieder wechseln. Aber wenn man sich nur mal ansieht, welchen unbrauchbaren Dateidialog sie in Gimp 2.0 eingebaut haben, kann man schon verstehen, warum der Fork von Gimp gestartet worden ist. Wenn dann auch Krita mal fertig wird, hat man zwischen Bibble, Gimp und Krita sicher eine schöne Auswahl.
Aber derzeit gibt's halt nur die Auswahl zwischen Bibble (gut + 60EUR teuer) und cinepaint (frei, aber nur rudimentär).
Mit 2.0 wurde kein neuer Dateidialog eingebaut. Der kam erst mit 2.2 und seit gtk2.6 sind eigentlich alle relevanten Probleme die ich mit dem Dialog hatte verschwunden.
Aha. Und warum fehlt dann auf einmal der Bild-öffnen-Dialog keine Adresszeile mehr, zeigt über der Dateiliste die Unterverzeichnisse als Buttons an,...
Das Ding, was sich Dateidialog nennt, ist nahezu unbedienbar, wenn man nicht vorher den Gnome-HIG auswendig gelernt hat. Aber immerhin kann man auf den Datei-öffnen Dialog gut verzichten, da die meisten andern Programme/dateimanager ja ein "öffnen mit Gimp" im Kontextmenü haben.
Und ja, irgendwann schau ich mit auch gimp 2.2 an. Vermutlich gibt es dort die dritte Version des Datei-Dialogs. War es nicht so ein Vektorzeichenprogramm (inkscape, sodipodi,..?), das vormachte, wie man als Gnome Programm den KDE Datei-Dialog verwenden kann?
>Aha. Und warum fehlt dann auf einmal der Bild-öffnen-Dialog keine Adresszeile mehr,
Es gibt etwas viel besseres wie eine Adresszeile -> typeahead Du tippst einfach wie z.B. beim mozilla/firefox drauf los und schon bist du da wo du hin wolltest wenn dir die Maus zu umständlich ist.
Hier gibt es ein Bild: http://www.gnome.org/~davyd/gnome-2-10/images/gtk-typeahead-full.png
So, bin jetzt bei Gimp 2.2.3 angelangt. Der Dateidialog ist immer noch der gleiche :-( Und tippen kann ich, soviel ich will, aber da kommt kein Type-ahead Fenster. Naja, vielleicht muss Otto-Normal-Gimp-Anwender erst den Sourcecode des GTK Dateidialogs lesen, um irgendeinen Magic Key für Type Ahead (oder was vergleichbares) zu finden. Aber immerhin schaut der Dialog enorm aufgeräumt aus. Klar, was nicht da ist, stört nicht. Das nennt sich dann wohl neudeutsch Usability, wenn man selbst als langjähriger Gimp 1.0-1.4 Anwender auf einmal nicht mehr den Dateipfad eingeben kann..
Vielleicht ist aber auch nur mein Gimp-Paket kaputt (Ist es eigentlich normal, dass im Unscharf-maskieren-Dialog das Vorschaubild viel zu klein, quadratisch, und nicht in der Größe zu ändern ist?).
Wirklich schade das sich RedHat so dagegen wert...
gotdotgnu.com
gotmono.com
gotdotnet.com
von der Sache her ist mono/.gnu/.net sowas ähnliches wie java (+ anhängsel
)
Man kanns also einma kompilieren und es läuft danach auf den unterschiedlichsten Systemen. Zumindest wenn die freien Implementierungen davon mal fertig sind. Derzeit müssen grafische Applikationen leider noch auf Wine zurückgreifen um "System.Windows.Forms" aufrufe irgendwie nachzubilden.
dazu wird das ganze dann auch noch nativ aussehen wenns ma fertig is afaik. Sowas schafft java höchstens mit awt und das ist dann nicht mehr bei der Java VM dabei und muss wieder manuell nachinstalliert werden...
Windows.Forms sollte auch keiner wollen, denn damit wird man angreifbar. QT# oder GTK# als plattformunabhängige Lösung ist der einzig gangbare Weg!
dazu wird das ganze dann auch noch nativ aussehen wenns ma fertig is afaik. Sowas schafft java höchstens mit awt und das ist dann nicht mehr bei der Java VM dabei und muss wieder manuell nachinstalliert werden...
-/Zitat-
Also mit AWT wirds keines Falls nativ aussehen, denn eine einheitliche Oberfläche auf allen Systemen ist ja Sinn und Zweck von AWT. Anders siehts da mit SWT aus dem Eclipse-Projekt aus. IMO benutzt das native GUI-Routinen sprich die Widgets des darunterliegenden OS.
Da verwechselst du jetzt AWT mit SWING. SWING ist bei gleichem Look&Feel auf allen Plattformen gleich, AWT benutzt für sein Widgets Native Peers, also Gegenstücke der darunter liegenden Plattform, bzw eines darunter liegenden Toolkits.
die windows forms gibts auch in .net und sind patentiert. solange also nicht alle windows entwickler auf mono oder ähnliches umsatteln sondern microsofts .net verwenden kann man die anwendungen genausowenig portieren wie heute normale win32 anwendungen. um platformübergreifend zu programmieren ist mono die bisher beste möglichkeit.
so habe ich das zumindest verstanden ...
gestern gab es einen msdn webcast, in demgezeigt wurde, wie eine (zugegeben sehr einfache) .net windows forms anwendung mit .net kompiliert und das file ohne neukompilierung unter redhat 9 mit mono gestartet werden konnte.
Das sehe ich anders. Bei PortableDotNet musste ich kein wine installieren und konnte trotzdem System.Windows.Forms verwenden.
Manche posten hier auch schwer einseitig:
1. Ist es nicht nur Mono, dass .net implementiert, sondern auch das GNU Projekt mit der PortableDotNet
und
2. Ist Java nicht mehr nur von Sun kontrolliert (siehe GNU Classpath und die vielen Freien VMs)
Vermutlich eher mehr.
Was soll das? Warum werden immer diese leugen verbreitet.
Wenn du was freies nehmen willst dann tu das (gcj whatever)
aber behaupte nicht das original Java ist genauso frei.
Denn das ist einfach BS.
o13
Grüße
Sascha
Haltet Euch von Mono fern. Je weiter die Projekte fortgeschritten sind, desto größer wird das Heulen, wenn M$ irgendwann die Hand aufhält und sagt ... ."Tja, sorry... Patente ..., aber wissen Sie, der Portierungsaufwand auf Windows ist ja gar nicht soo groß...zahlen Sie uns einfach den Verlust, den wir dadurch hatten, dass sie nicht von vornherein Windows benutzt haben und bessern Sie sich!"
.NET ist auch aus der Lage entstanden, dass Sun MS verboten hat, eine eigene Version von Java zu erstellen. Würde man deiner Argumentation folgern, dann kann Sun jetzt kommen und MS auf die Finger klopfen - Können sie aber nicht.
Genausowenig wird MS kommen und Mono verbieten.
Dass Patente ein Problem darstellen ist aber trotzdem richtig. Dieses Problem hast du aber unabhängig von Mono.
Mono ist mir viel lieber als zB Java. Bei Java hast du Sun, welches Java kontrolliert. Man kann zwar zu Sun gehen und Vorschläge machen, aber am Ende ist immernoch Sun da. Und Java ist nicht frei. Mono ist frei und das ist auch gut so. Wenn man mit Java GPL Software schreiben will, dann muss man sich bewusst sein, dass der User unfreie Software nutzten muss, wenn er die Software nutzten will.
Mono hat einen Zustand erreicht, in dem es stabil und zuverlässig ist. Es fehlt - zumindest unter Betriebssystem mit Gnome, Gtk usw - eigentlich an nichts. Die Anwendungsentwicklung ist schnell und effektiv. Zudem hat man die Vorteile einer Umgebung mit GC.
Meiner Meinung nach ist Mono eine ideale Sprache, um unter Linux Desktopanwendungen zu Entwickln. Ich sehe grosse Chancen für die Sprache, C/C++ in der Linux-GUI-Entwicklung zu verdrängen. Ähnliche Chancen sehe ich zB für Python.
Nicht von Mono fern bleiben, sondern darauf zugehen und von der Technologie profitieren. Mono ist gut und hat Zukunft.
PS: Auf MSDN gab es gestern sogar einen Webcast über Mono. Da wurde eine WinForm Anwendung ohne neu zu kompilieren auf Redhat 9 laufen gelassen. Auf http://www.go-mono.com/monologue gibt es einen Bericht dazu. Wie es aussieht ist MS sogar froh darum, dass es Mono gibt. Mono zu verbieten - falls MS es könnte - würde ja auch nicht viel Sinn machen, Mono nützt MS mehr, wenn es existiert.
Schäm dich!
Wenns die wirklich ernst wäre mit freier Software (M$-Evangelist), dann würdest du wissen, dass man mit Java durchaus - und zwar weit besser als mit Mono - freie Software entwickeln kann: GCJ, CLASSPATH, KAFFE, etc.
Das bewährteste Stück an open.NET ist doch die Java VM ...
> Dass Patente ein Problem darstellen ist aber trotzdem richtig. Dieses Problem hast du aber unabhängig von Mono.
Ach so ist das... Problem erkannt - Problem gebannt oder was???
Es gibt die CLR. Klar gab es das Prinzip auch schon bei Java, bei anderen Programmiersprachen übrigens ebenfalls.
Das Problem ist, warum MS froh darüber ist.
So wird nämlich der Anschein gewahrt, dass es sich nicht um Windows bezogene Technologie handelt, d.h. im Moment stimmt das mehr oder weniger sogar.
Sobald sich die Erkenntnis, dass .NET auch auf anderen Plattformen verfügbar ist, besonders für Serverkompontenten auf Linux, werden einige Softwarehersteller .NET in Betracht ziehen, wenn serverseitige auch anderes als Windows im Einsatz oder zumindest geplant ist.
Aber wie die Geschichte mit Java zeigt, wird MS dann ihre Extensions erschaffen und sie nicht als Zusatzbibliothek zum Download anbieten, sondern mit ihrem Standard SDK ausliefern.
Diese Extensions werden dann entsprechend "abgesichert" sein (technisch und rechtlich), damit sie nicht auf anderen Plattformen implementiert werden können.
Wie bei MS Java werden dann unzählige Entwickler in diese Falle tappen und unwissentlich zw durch Unaufmerksamkeit wieder Windows-Only Software produzieren.
Wenn dann der Fall eintritt, dass man gerne gewisse Produkte zB unter Linux einsetzten möchte, wird man aufwachen und sehen, dass damit große Kosten verbunden sind, weil Teile der Produkte neu implementiert werden müssten.
Mono sollte darauf achten, nicht .NET für Linux zu sein, sondern einfach eine Plattform mit ähnlicher Technologie aber eigenständig.
> sein, sondern einfach eine Plattform mit ähnlicher
> Technologie aber eigenständig.
Mono sieht sich selbst als Implementation eines ECMA Standards und (ausdrücklich) nicht als Linux-Port von MS .NET.
Solange es heißt "Mono's .NET implementation is based on the ECMA standards...", ist Mono eine .NET Implementation.
Und .NET ist nunmal praktisch im Sprachgebrauch äquivalent zu MS .NET
Ich denke es besteht gar kein Interesse sich von MS .NET zu distanzieren, die Leute, die auf den .NET Hype Zug aufspringen, sollen ja Mono als äquivalente Plattform sehen.
Natürlich wäre es schöner, wenn alles aus einer Hand kommt, aber bei mir läuft mono (inkl. aller Zusatzpakete) & MonoDevelop einwandfrei.
Das genaue Repository werde ich nachreichen. Habe ich grade nicht vorliegen. (Google hilft da aber sicher)
Soweit ich weis, gibt es dann einen QA-Prozess, bei dem noch einmal ein Build mit dem RPM-Packet durchgeführt wird. Wenn man diesen Build dann abgenommen hat, wird das Paket im Repository veröffentlicht.
mfg: Jochen Schmitt
> Hand der Gemeinschaft und bitten um Verzeihung«, heißt es in der
> Ankündigung.
So tief beschämt können die nicht sein. Einen ClamAV 0.71 anzubieten, der
einen beim ersten Patternupdate sofort als 'outdated' begrüßen wird, ist
IMO beschämender, als ihn garnicht anzubieten.
Gruß, die Tendenz
Cinepaint 0.19 (wie Gimp mit Support für 16bit/Farbkanal und Colour-Management)
http://cinepaint.sourceforge.net/
(Wessen Distribution eine liblcms in Version <=1.13 mitbringt, der benötigt folgenden Patch: http://cvs.sourceforge.net/viewcvs.py/cinepaint/cinepaint-project/cinepaint/app/cms.c?r1=1.3&r2=1.4 )
Die Cinepaint Leutz wollen das Ding ja auf FLTK portieren und die Gimp Leutz planen in Version 3 (falls es hinhaut) GEGL zu nutzen, was es GIMP erlauben würde mehr als 8 Bit pro Kanal zu nutzen.
Da die letzte Version von Cinepaint schon etwas rudimentär (ok ist noch gtk1) war würde mich mal interesieren ob deren Projekt auf dauer überhaupt eine Chance hat falls GIMP im Kern mit ihnen gleichzieht.
Klar, irgendwann wird auch Gimp 16bit/Kanal bieten, Krita wird dies etwas davor (oder danach) auch bieten.
Derzeit ist meines Wissens aber Cinepaint das einzige freie Programm, das
* RAW-Bilder mit voller Farbtiefe importieren kann,
* mit 16bit/Kanal umgehen kann
* und Farbmanagement unterstützt.
Alternativ kommt für Digitalkamerabesitzer eigentlich nur Bibble in Betracht, wenn man eine gute Raw-Unterstützung braucht.
Wegen Cinepaint mache ich mir keine Sorgen, das hat den Schwerpunkt auf Filmbearbeitung und wird kontinuierlich weiterentwickelt. Wenn Gimp 16bit/Kanal und brauchbares Farbmanagement bietet, kann man ja wieder wechseln. Aber wenn man sich nur mal ansieht, welchen unbrauchbaren Dateidialog sie in Gimp 2.0 eingebaut haben, kann man schon verstehen, warum der Fork von Gimp gestartet worden ist. Wenn dann auch Krita mal fertig wird, hat man zwischen Bibble, Gimp und Krita sicher eine schöne Auswahl.
Aber derzeit gibt's halt nur die Auswahl zwischen Bibble (gut + 60EUR teuer) und cinepaint (frei, aber nur rudimentär).
Der kam erst mit 2.2 und seit gtk2.6 sind eigentlich alle relevanten Probleme die ich mit dem Dialog hatte verschwunden.
Aha. Und warum fehlt dann auf einmal der Bild-öffnen-Dialog keine Adresszeile mehr, zeigt über der Dateiliste die Unterverzeichnisse als Buttons an,...
Das Ding, was sich Dateidialog nennt, ist nahezu unbedienbar, wenn man nicht vorher den Gnome-HIG auswendig gelernt hat. Aber immerhin kann man auf den Datei-öffnen Dialog gut verzichten, da die meisten andern Programme/dateimanager ja ein "öffnen mit Gimp" im Kontextmenü haben.
Und ja, irgendwann schau ich mit auch gimp 2.2 an. Vermutlich gibt es dort die dritte Version des Datei-Dialogs. War es nicht so ein Vektorzeichenprogramm (inkscape, sodipodi,..?), das vormachte, wie man als Gnome Programm den KDE Datei-Dialog verwenden kann?
Es gibt etwas viel besseres wie eine Adresszeile -> typeahead
Du tippst einfach wie z.B. beim mozilla/firefox drauf los und schon bist du da wo du hin wolltest wenn dir die Maus zu umständlich ist.
Hier gibt es ein Bild: http://www.gnome.org/~davyd/gnome-2-10/images/gtk-typeahead-full.png
Und tippen kann ich, soviel ich will, aber da kommt kein Type-ahead Fenster.
Naja, vielleicht muss Otto-Normal-Gimp-Anwender erst den Sourcecode des GTK Dateidialogs lesen, um irgendeinen Magic Key für Type Ahead (oder was vergleichbares) zu finden.
Aber immerhin schaut der Dialog enorm aufgeräumt aus. Klar, was nicht da ist, stört nicht. Das nennt sich dann wohl neudeutsch Usability, wenn man selbst als langjähriger Gimp 1.0-1.4 Anwender auf einmal nicht mehr den Dateipfad eingeben kann..
Vielleicht ist aber auch nur mein Gimp-Paket kaputt (Ist es eigentlich normal, dass im Unscharf-maskieren-Dialog das Vorschaubild viel zu klein, quadratisch, und nicht in der Größe zu ändern ist?).