Newsgroups: de.comp.sys.amiga.misc References: <33e1fee0.5691689@personalnews.germany.eu.net> <1485.7146T670T385@abo.freiepresse.de> <6adF95PtugB@dawnie.alcatraz.inka.de> <13216521@sourcery.han.de> <6alLmiMtugB@dawnie.alcatraz.inka.de> From: "Olaf Barthel" Date: Wed, 30 Jul 1997 10:29:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-NewsReader: IntuiNews 1.3a (7.9.95) Subject: Re: Phase-5: Was mir nicht gefaellt.... Message-ID: <13216530@sourcery.han.de> Lines: 145 Path: 195.95.96.2!news.unisource.be!News.Amsterdam.UnisourceCS!news.unisource.nl!newsgate.unisource.nl!IRIS.global-one.nl!news-lond.gsl.net!news.gsl.net!news-dc.gsl.net!gsl-penn-ns.gsl.net!news-peer.gsl.net!news.gsl.net!news.maxwell.syr.edu!news-feed.inet.tele.dk!uninett.no!baghira.han.de!sourcery.han.de!not-for-mail In Article <6alLmiMtugB@dawnie.alcatraz.inka.de>, Ralf Ramge wrote: > > Hi, > > > ich wusste, daß Du es sichtest ;-) > > > Was ist an der gtlayout.library so unsäglich, daß Du es nicht > > sagen möchtest? ;) > > Aufgeblasen, unflexibel, häßlich und schlichtweg unnötig. Sie ist zu groß, sie kann nicht alles, häßlich ist eine subjektive Beurteilung und nötig ist sie eigentlich auch nicht -- aber nicht alle Dinge, die einem das Leben erleichtern, sind unbedingt nötig. > Oder etwas direkter ausgedrückt (Smilies lasse ich weg, deshalb sage ich > es hier): Es hat niemand was dagegen, wenn Du Dir selbst eine Library > zusammenbaust, um beim GUI nicht andauernd das Rad neu erfinden zu müssen. > Ich halte es jedoch für ziemlich daneben, diese dem Anwender dann in einem > Maße aufs Auge zu drücken, daß es schon keinen Spaß mehr macht. Gehen wir > mal der Reihe nach durch: Jeder hat seine eigene Meinung zu diesem Thema. Die Library ist leider sehr schnell von den ursprünglichen 44k auf über 70k zu den jetzigen 100k gewachsen und das trotz wiederholtem Umschreiben zwecks Reduktion des Codeumfangs. Einen Teil der Funktionalität braucht man wirklich nicht andauern, er ist aber drin, weil man ihn manchmal durchaus sinnvoller einsetzen kann, als alternative Lösungen (ich denke da zum Beispiel an die Tab-Gadgets oder die Tapedeck-Buttons). Ich erhebe nicht den Anspruch, mit der Library jeden selig machen zu können und habe bewußt darauf verzichtet, mit den anderen Layout-Engines in Wettbewerb zu treten. Wozu auch? Die gtlayout.library ist eben nicht so flexibel, wie andere Systeme. > - Term. Hier sehe ich keinen Nutzen dabei. Die GUI war vorher um Klas- > sen besser, schneller und übersichtlicher. `term' war der eigentliche Grund, mit der Library anzufangen. Wie gut Du Dich im alten (vor 3.1) Sourcecode von `term' auskennst, weiß ich nicht. Grundsätzlich war der Aufbau des GUIs aufwendiger und jedes kleine Fitzelchen von Hand programmiert. Neue Elemente hinzuzufügen oder auch nur kleine Änderungen durchzuführen, war fehlerträchtig und mühsam. Letzlich habe ich eine einheitliche Methode gesucht und mir dann selbst gebastelt, die das Erzeugen und Verwalten des GUIs vereinfacht. In der ersten Version, die die Library benutzt hat, ist der Programmumfang um fast 60K gefallen, wobei die Library damals um die 50K groß war und mehr konnte, als `term' damals nutzte. > - MagicMenu. Ich habe es gesehen und war entsetzt. Irgendwie finde ich > es recht heftig, wenn für ein recht kleines Programm eine derart fet- > te Library benutzt wird (und mit fett meine ich *fett*, 50% mehr Um- > fang als MUI mit nur einem Bruchteil der Leistung kann man wohl als > fett bezeichnen). Zumal Du anscheinend Martins alte Strukturen drin- > gelassen, denn irgendwie habe ich es geschafft (v2.15?), die alten > direkt implementierten Prefs zu aktivieren. In diesem Augenblick > habe ich Dich gehasst ;) Anmerkung dazu: nur das Prefs-Programm benutzt die Library. Ich wäre mit dem Klammerbeutel gepudert, die Library ständig im Speicher zu halten und damit durchgehend 100K zu verpulvern. MagicMenu selbst belegt etwas mehr als 60K im Speicher. Und das ist auch alles. > - Picasso96. Hier gilt das gleiche wie für die beiden zuvor genannten > Programme. Die GUI ist potthäßlich und das Programm belegt mehr > Speicher als eigentlich verdient. Und das tut es wirklich, anschei- > nend setzt Du den count gleich mal auf 1, damit man sie auf gar kei- > nen Fall mehr flushen kann. Ich dachte, mich tritt ein Gaul, als mir > nach knapp 700 Märkern Rechnung diese Library entgegenschwappt ;) Unterstell mir bitte lieber Dämlichkeit als Böswilligkeit, damit kann ich besser leben. > Olaf, ich hätte nichts dagegen, wenn Du diese Library derart versuchen > würdest durchzudrücken (anders kann ich mir einen Einsatz bei Programmen > >300 KB nicht erklären, denn darunter ist es schlichtweg maßlose > Verschwendung von Ressourcen), wenn die Library eine gewisse Verbreitung > hätte. Bei dieser Handvoll Programmen kann man davon beim besten Willen > nicht reden - dann könntest Du auch gleich mein LIBS: verschonen und den > Code direkt in Deine Applikation reinlinken, für mich als Anwender ist > der Effekt derselbe. Die Library läßt sich statisch zu Programmen dazulinken. Das hat Vorteile, aber auch den Nachteil, daß Library-Fehler auch dann in dem jeweiligen Programm bleiben, wenn ich sie an anderer Stelle schon beseitigt habe. > Und selbst wenn eine gewisse Verbreitung vorhanden wäre, bei welcher man > davon ausgehen könnte, daß es sich lohnt, fast 200 KB an Speicher für ein > oder zwei Fenster zu verschwenden, hat gtlayout immer noch das Problem, > daß Du noch verdammt viel Arbeit investieren mußt, um die Arbeit von > Stuntzi überhaupt zu erreichen - von überholen reden wir jetzt erstmal > gar nicht. Da mißverstehst Du mich; die Library ist nicht entstanden, um es mit MUI aufzunehmen oder hat sich jemals in diese Richtung entwickelt. Ich habe andere Anforderungen an das System, mit dem ich eine Benutzeroberfläche aufbauen und verwalten will, als Stefan seinerzeit bei der Entwicklung von MUI gehabt hat. > Ich kann, als Anwender und Programmierer, echt nicht verstehen, > weshalb Du mit gtlayout Deine Zeit und meine Ressourcen überhaupt ver- > schwendest, denn ich sehe aus beiden Perspektiven weder Sinn noch Nutzen > darin. Kläre mich mal über Deine Motivation auf, würde mich ehrlich > interessieren. Es wird zwar auch nichts daran ändern, daß die Library bei > mir Hausverbot hat, aber ich bin halt neugierig. Tja, die Library sollte für mich eine Reihe von Problemen lösen. Das hat sie auch geschafft, wenn sie auch andere Probleme mit sich gebracht hat. Ich kann's mir immer nicht verkneifen, meine Problemlösung dem Rest der Welt zur Begutachtung und Kommentierung an die Hand zu geben, einschließlich des Sourcecodes. > Und ich muß sagen: Hätte ich gewusst, daß mir nach der Bezahlung der > Picasso IV die gtlayout.library entgegenfällt (und diversen Versprechungen > im Handbuch wie Wavetables, die anscheinend doch nicht vorhanden sein > werden ;), hätte ich nochmal ernsthaft überdacht, ob mir die Karte das > Geld wirklich wert ist. Und der neue CygnusEd hatte automatisch schlechte > Karten, als ich Deinen Namen las, denn ich habe da so eine gewisse > Vermutung, daß das GUI nicht verbessert, sondern eher verschlimmbessert > wird ... ;) Ich finde Deine diesbezügliche Vorgehensweisen definitiv ein > wenig übertrieben. Au weia. Für wie maßlos hälst Du mich? > [..] > So, Du wolltest wissen, was ich denke, jetzt hast Du es ziemlich > ausführlich. Ich denke mal, Du kannst es verkraften ;) Ich bin Kummer gewohnt ;) > Wenn Du nicht nur meine Gründe, sondern auch meine Vorschläge hören > möchtest: Benutze bei zukünftigen Projekten auf unkommerzieller Basis > (also sowas wie Term, MagicMenu) doch bitte MUI. Das Teil ist > leistungsstark, läßt beim Benutzer kaum Wünsche offen und für > Programmierer ein Traum. Das ist Deine subjektive Ansicht, die ich wiederum nicht teile. Wenn mich MUI zufriedenstellen hätte können, wäre die gtlayout.library nicht entstanden. Nicht jeder Mensch löst seine Probleme wie andere Menschen es tun. Ich habe mich seinerzeit für meinen eigenen Weg entschieden und dem werde ich auch weiterhin folgen. -- Home: Olaf Barthel, Brabeckstrasse 35, D-30559 Hannover Net: olsen@sourcery.han.de