Login
Newsletter
Werbung

Thema: Aethera - Kommunikationssoftware für KDE2

25 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von LH am Mi, 17. Januar 2001 um 23:49 #
Sind wir hier unter Windows oder wieso bedeutet 0.9 frühe Entwicklungsphase?
  • 0
    Von MoMo am Do, 18. Januar 2001 um 00:08 #
    Vielleicht solltest Du die Apps ausprobieren. So wie sich das Programm verhaellt, ist es noch eine Alpha-Version. Gerade ausprobiert. Sehr viele Funktionen zeigen keine Reaktion. Die Versionsnummer spielt dabei keine Rolle. Schliesslich koennen die Entwickler die naechste Version 0.91, 0.92 usw. nennen. Seit wann sagt die Versionsnummer etwas ueber die Qualitaet einer Applikation aus?
    0
    Von Anonymous am Do, 18. Januar 2001 um 00:10 #
    @LH: Vielleicht probierst Du das Programm aus. Dann wirst Du verstehen, warum es sich bei Aethera um eine "fuehe Phase" handelt
    0
    Von Spark am Do, 18. Januar 2001 um 01:11 #
    er wollte damit wohl ausdruecken, dass man einer software nicht die versionsnummer 0.9 geben sollte, wenn sie sich noch in einem fruehen entwicklungsstadium befindet und man das auch selber einsieht. dem kann ich auch durchaus zustimmen.
    0.9 bedeutet fuer mich soviel wie "ein zehntel fehlt zur fertigstellung" ;)
    0
    Von LH am Do, 18. Januar 2001 um 09:14 #
    Richtig Spark, hast es erfasst :)
    Für mich wäre Alpha höchstens 0.3 oder so. Ich finde das ist eine aufrichtigere Zählweiße
0
Von Olaf Schröder am Mi, 17. Januar 2001 um 23:53 #
gerade ausprobiert - sieht nett aus ist aber wirklich noch in einer frühen entwicklungsphase.
0
Von Alex Brand am Do, 18. Januar 2001 um 00:40 #
Hattet Ihr auch Probleme mit dem Compilieren? Ich mußte noch an den Sourcen Änderungen vornehmen. Oder liegt es daran, daß ich "nur" KDE 2.0.0 installiert habe?
  • 0
    Von Anonymous am Do, 18. Januar 2001 um 05:05 #
    Ja auch Compilier-Probs. das machen die Säcke mit Absicht, wie bei GNOME (kaum noch von null aus hochzuziehen) oder sax2
    0
    Von mad am Do, 18. Januar 2001 um 09:34 #
    Find ich fatal, hier Absicht zu unterstellen...

    Ich kann mich gut dran erinnenern, als es vor dem 1.0er Kernel hiess, den Feheler mit dem das compilieren vom Kernel abbricht, soll man einfach ignorieren. Der Kernel lief dann trotzdem. Absicht?

    Moechte auch wissen, wieviele groessere Programme du schon hochgezogen hast, ohne Probleme zu bekommen.

    Ich empfehle dir in diesem Zusammenhang mal gyve, gnustep, etc.

    mad

    0
    Von Alex Brand am Do, 18. Januar 2001 um 10:03 #
    @mad:
    Ich kann mich gut dran erinnenern, als es vor dem 1.0er Kernel hiess, den Feheler mit dem das compilieren vom Kernel abbricht, soll man einfach ignorieren. Der Kernel lief dann trotzdem. Absicht?

    Ich meinte eigentlich ein Problem in der Datei "mainwindow.cpp". In der Methode "aboutMagellan" wird eine statische Methode von KAboutData versucht zu verwenden, die es bei KDE 2.0.0 nicht gibt (KAboutData::License_GPL_V2), außerdem ist die Include-Anweisung weggelassen worden. Wenn sich diese Methode in KDE 2.0.1 oder 2.1beta1 geändert haben sollte, was ich nicht glaube, dann hätten die es in ihrem configure Skript abfragen können.
    Ich habe auch auf Mandrake 7.2 compiliert, wie kommt es dann, das die ein RPM-Paket für diese Distr. compilieren können???

    Die anderen Warnungen sind für eine Alpha/Beta zu akzeptieren.

    0
    Von mad am Do, 18. Januar 2001 um 10:09 #
    Auf der Website steht unter installationsanleitung eindeutig, das man KDE 2.1beta1 haben muss, und qt 2.2.2 (recommanded 2.2.3)

    Wenn es also unter 2.01 nicht geht, solltest du den Fehler dort suchen.

    0
    Von Alex Brand am Do, 18. Januar 2001 um 15:20 #
    Ok, das mit der statischen Methode stimmt die gibt es doch schon in KDE 2.0.0. Hatte ich nur anders im Kopf und das "_V2" gelöscht und '#include kaboutdata.h' hinzugefügt bevor ich es neu compiliert habe.
    Wo ich Dir Recht geben muß: KAboutApplication ist seit 2.1beta1 geändert.
    Meiner Meinung nach hätte man es aber schöner und vor allem KDE-Konformer programmieren können, dann hätte es auch unter KDE 2.0.0 geklappt. KAboutData gehört eigentlich in main(). Dann würde sich KAboutApplication auch die Daten von dort holen.
    Man hätte aber auch das configure Skript anpassen können ;-) Haben die aber zum Glück nicht gemacht und so konnte ich es auch ohne große Änderungen compilieren.
0
Von Olaf Schröder am Do, 18. Januar 2001 um 01:06 #
habe das rpm benutzt 1a keine probleme (mandrake7.2)
0
Von Anonymous am Do, 18. Januar 2001 um 08:29 #
gibt es magellan eigentlich noch?
0
Von Tuxschlachter am Do, 18. Januar 2001 um 11:38 #
Gibt es keine RPM-Pakete für SUSE?
(Diesmal bleibt Tux am Leben)
0
Von TomZ am Do, 18. Januar 2001 um 18:22 #
Hhmm ... mal 'ne Frage: Ich suche ein Tool, welches ungefaehr dieselbe Funktionalitaet wie Aethera hat. Nur muss ich leider noch des oefteren geschaeftlich unter Windows arbeiten, und ein Programm, welches unter Windows und unter Linux laufen wuerde, mit denselben eMail-, Kontakt- etc. Einstellungen waer der absolute Renner fuer mich. So aehnlich, wie man sich die Bookmarks etc. von Netscape auf beiden Systemen teilen kann

Kennt jemand sowas?

0
Von Spark am Fr, 19. Januar 2001 um 20:06 #
was sagt ihr eigentlich zu der diskussion, die da gerade auf dot.kde.org abgeht?
magellan ist BSD code.
kompany hat sich jetzt den code gnommen, weiter entwickelt und daraus ihre gpl software gemacht. das problem ist jetzt, dass die magellan leute davon nichts mehr haben, da gpl code nicht in bsd code verwendet werden kann. ist das jetzt ein nachteil der gpl lizenz, naemlich, dass sie intolerant ist, oder ist es ein nachteil der bsd lizenz, weil sie so etwas erlaubt?
das ganze ist interessant finde ich. das problem, dass bsd code "geklaut" werden kann, war ja bekannt. jemand haette ein unfreies email programm daraus machen koennen um selbiges zu verkaufen. aber das ist nicht wirklich eine konkurrenz, da die meisten anhaenger freier software dennoch die freie version verwenden wuerden.
jetzt sieht es aber anderes aus, die "diebe" sind die, die ihre software im grunde die "wahre" freie software nennen.
freie software als konkurrenz zu freier software?
der bsd lizenz drohen also jetzt "gefahren" aus beiden seiten des lagers. unfreie und freie software kann sich jederzeit bsd code schnappen, ihn in eine andere lizenz umwandeln und das ergebnis fuer die bsd version unerreichbar machen. es macht einen komischen eindruck, dass GPL einem anderen freien projekt schadet, aber es geht nicht anders. wuerde gpl in bsd code verwendet werden koennen, muesste man ein einfaches gpl programm einfach in bsd umwandeln um es danach in seiner unfreien software zu verwenden.
ist das jetzt ein beweis dafuer, dass bsd code fuer ernsthafte projekte keinen sinn macht?
was denkt ihr darueber?
  • 0
    Von Mosh am Sa, 20. Januar 2001 um 08:09 #
    IANAL but AFAIK geht die "Übernahme" von BSD-Code erst mit der modifizierten Lizenz
    (d. h. ohne den 3. Abschnitt).

    Warum sollte BSD keinen Sinn machen für ernsthafte Projekte, nur weil der Code unter andere Softwarelizenzen gestellt werden kann.

    Wenn jemand ein kommerz. Programm aus einem BSD-Programm macht, so ändert sich ja auch die Lizenz.

    BTW die Diskussion ist uralt.

    Mosh

    0
    Von Spark am Sa, 20. Januar 2001 um 15:35 #
    mit der neuen lizenz geht es wohl.
    nein, ich trolle nicht. wenn die diskussion uralt ist, dann habe ich sie wohl verpasst. ;) natuerlich ist mir bekannt, dass bsd code in closed source umgewandelt werden kann und das ist in der tat eine alte geschichte. nur sehe ich closed source nicht wirklich als konkurrenz zu opensource, das ist eine ganz andere welt.
    interessant finde ich das jetzt einfach, weil eine andere opensource lizenz der bsd lizenz probleme macht. die arbeiten mit viel einsatz an magellan, wollen das sicher auch zu einem weitverbreiteten kde email clienten machen und dann schnappt sich jemand den code, macht daraus gpl code, erweitert das ein bisschen und vermarktet das. im grunde kein problem, ist ja immer noch opensource und damit frei. aber wie frei? so frei, dass die entwickler des orignals, also des bsd codes, diese neuen anpassungen nicht mehr verwenden koennen, da gpl nicht frei genug fuer die bsd lizenz ist.
    waere der andere code unter einer kommerziellen lizenz, dann wuerde magellan jetzt dennoch weiterhin volle unterstuetzung erhalten, da sie nunmal opensource sind. aber jetzt gibt es aethera und das ist auch opensource und erweitert.
    teddy (also der entwickler von magellan) hat im grunde jetzt ein problem. entweder er stellt seinen source ebenfalls unter die gpl, um vom aethera code zu profitieren, oder er sieht zu, wie jemand anderem mit seinem projekt der durchbruch gelingt.
    deswegen frage ich, ist bsd geeignet, fuer solche projekte? oder ist die bsd lizenz nur wirklich angebracht, wenn man ausdruecklich damit rechnet, dass jemand anderes den eigenen code schnappt um daraus etwas besseres zu machen?
    oder sollte man dann lieber die alte bsd lizenz verwenden, die AFAIK nicht erlaubt, dass der code in gpl code umgewandelt wird.
    aber das ist diese lizenz auch nicht mehr ganz so frei, wie ich sie eigentlich kenne...
Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung