>Wenn ich ein pdf im Filemanager anklicke, soll es im Standalone-Acrobat Reader geladen werden. >Klicke ich im Browser auf einen Link zu einem pdf soll es eingebettet dargestellt werden.
Ist geplant/schon relisiert zu vereinfachen. Das beschäftigt schon die Entwickler.
>Klicke ich im Filemanager auf eine Archivdatei soll der Inhalt des Archives angezeigt werden. Im Browser will ich es runterladen. Dito
>Mir gefällt es auch, was Konqui alles kann. Ich mag es auch einfach schnell ftp:// in die Adresszeile einzugeben, wenn ich auf meinen Server will. >Allerdings sind diese URLs für Anfänger viel zu kryptisch und unintuitiv. War für 3.1 geplant, wird aber doch erst in 3.2 auftauchen: Ein einfaches grafisches Frontend zur Eingabe der URLs für die KIO Slaves. Steht übrigends im Feature-Plan mit "Adopt me", also ran an den Code ;-)
>Die internen Viewer-Komponeneten habe ich eigentlich alle deaktiviert. Ich sehe deren Sinn nicht so ganz. >Ich kann das Zeug ja gleich mit der passenden Application öffnen. Die Viewer sind schneller in der Anzeige, nicht sehr viel, aber doch vorhanden.
>>Die internen Viewer-Komponeneten habe ich eigentlich alle deaktiviert. >>Ich sehe deren Sinn nicht so ganz. >>Ich kann das Zeug ja gleich mit der passenden Application öffnen.
>Die Viewer sind schneller in der Anzeige, nicht sehr viel, aber doch vorhanden.
kde == schnell? scheint mir paradox ;-)
ich selbst bevorzuge applikationen, die eine aufgabe richtig erledigen und halbwegs schlank bleiben, statt alles nur halb zu koennen und vor muskeln nicht mehr in schwung kommen (ja, es gibt noch rechner mit weniger als 256mb und 500 mhz).
das Thema Performance von KDE und allen anderen C++ Applikationen ist schon so oft runtergeleiert worden, daß auch Du die Hauptursachen kennen solltest. Unter anderem betreust Du ja selbst eine C++ App und die dürfte mit dem Windowskompiler auch schneller starten(?).
Mein Rechner ist auch unter Deiner Angabe (im fehlen da noch 32MB) und ich kann damit leben.
Deine Philosphie ist okay: Für alles seine eigene Applikation. KDE will das halt anders und integriert daher viel mehr. Es soll ja ein Environment und nicht nur ein Toolkit mit WM sein.
Der oben genannte Konqueror gibt's auch als Embedded, da hat er wahrlich nicht so viel MB ;-) Und warum gibt's den nicht für den Desktop? Weil die meisten lieber den Full-Featured als einen ganz schmalbrüstigen Browser wollen. Die Mehrheit entscheidet hier, sowohl als Entwickler als auch als Anwender. Und wie leicht es ist KHTML in ein simples Fenster zu packen, kennst Du auch. Alle Projekte die kleine Browser haben wollten, sind wieder eingeschlafen, weil kaum einer so was will. Ein paar MB mehr sind den meisten Anwendern weniger wichtig als hohe Performance (cachen), alle Seiten betrachten können (alle Bugs mit speziellem Code umschiffen), jedes Plugin, usw. usw.
Und halb können ist auch nicht fair, weil pauschal. Das solltest Du genauer erläutern.
ich kenne die hauptursachen der schlechten performance, aber das aendert nichts daran, dass kde speicher en masse in sich reinfrisst und das es definitiv laenger dauert, eine lib zu laden oder noch 5 weitere dazu. wie schon andere hier bemerkt haben, entschlacken tut hier not. es wuerde sicher schon enorm viel bringen, wenn applikationen auch wirklich nur das einbinden wuerden, was sie brauchen, und nicht, was irgendeine schablone vorgibt. ich wuerde es begruessen, wenn die vielen kleinen anwendungen, fuer deren funktionsumfang die qt ausreicht, auch nur diese benutzen wuerden statt noch einiger kde-libs (ich weiss, die integration...). und du hast recht, lincvs startet unter win schneller, aber auch unter unix ists noch ertraeglich. ich finde die qt zu gut, um auf c umzuschwenken ;-)
bei meinem altrechner kommt noch die susi 8 hinzu, die geht auch nicht zimperlich mit dem speicher um, aber auch das wird sich demnaechst erledigt haben...
es kann ja jeder machen was er will und damit gluecklich werden, aber es gibt genug beispiele aus der geschichte, wo eierlegende wollmilchsaeue gegen spezialisten den kuerzeren gezogen haben. aber davon abgesehen koennte ich mir vorstellen, dass integration nicht unbedingt mit massiver fettleibigkeit einhergehen muss. integration heisst wohl nicht, 500 anwendungen fuer alles, was die welt nicht mehr braucht. beschraenkung aufs wesentliche war schon immer eine tugend.
ich nehm mal an, den embedded-konqi gibts nicht auf dem desktop, weil die leute, die nen schlanken browser wollen, da eh nicht den konqi nehmen. ich will gerne glauben, dass es leicht ist, khtml in ein fenster zu stopfen, aber ich will nicht die dazugehoerige lib. ausserdem muss ich auch oft unter win arbeiten (genaugenommen meistens ;-( ), da find ichs gut, wenn meine lieblingsapplikation auch dort laeuft. warum kleine browser bis jetzt nichts geworden sind, hat sicher ne ganze reihe von ursachen, auf jeden fall beobachte ich solche projekte.
das halb-koennen ist natuerlich pauschal postuliert. und ich kann hoechstens veraltete beispiele nennen, da ich kde ja nicht nutze. was mich immer massiv gestoert hat, waren bugs wie doppelte (uebereinanderliegende) icons, bildschirmschoner mit einem kleinen ausschnitt vom desktop statt des ganzen oder gar doppelt gestartete bildschirmschoner, gelegentliche abstuerze und dergleichen mehr. ich weiss zwar, dass ich den ueberfluessigen bildschirmschoner von der konsole aus killen kann, aber nicht meine Frau...
>Klicke ich im Browser auf einen Link zu einem pdf soll es eingebettet dargestellt werden.
Ist geplant/schon relisiert zu vereinfachen. Das beschäftigt schon die Entwickler.
>Klicke ich im Filemanager auf eine Archivdatei soll der Inhalt des Archives angezeigt werden. Im Browser will ich es runterladen.
Dito
>Mir gefällt es auch, was Konqui alles kann. Ich mag es auch einfach schnell ftp:// in die Adresszeile einzugeben, wenn ich auf meinen Server will.
>Allerdings sind diese URLs für Anfänger viel zu kryptisch und unintuitiv.
War für 3.1 geplant, wird aber doch erst in 3.2 auftauchen: Ein einfaches grafisches Frontend zur Eingabe der URLs für die KIO Slaves. Steht übrigends im Feature-Plan mit "Adopt me", also ran an den Code ;-)
>Die internen Viewer-Komponeneten habe ich eigentlich alle deaktiviert. Ich sehe deren Sinn nicht so ganz.
>Ich kann das Zeug ja gleich mit der passenden Application öffnen.
Die Viewer sind schneller in der Anzeige, nicht sehr viel, aber doch vorhanden.
>>Ich sehe deren Sinn nicht so ganz.
>>Ich kann das Zeug ja gleich mit der passenden Application öffnen.
>Die Viewer sind schneller in der Anzeige, nicht sehr viel, aber doch vorhanden.
kde == schnell?
scheint mir paradox ;-)
ich selbst bevorzuge applikationen, die eine aufgabe richtig erledigen und halbwegs schlank bleiben, statt alles nur halb zu koennen und vor muskeln nicht mehr in schwung kommen (ja, es gibt noch rechner mit weniger als 256mb und 500 mhz).
viele gruesse, Tilo
das Thema Performance von KDE und allen anderen C++ Applikationen ist schon so oft runtergeleiert worden, daß auch Du die Hauptursachen kennen solltest. Unter anderem betreust Du ja selbst eine C++ App und die dürfte mit dem Windowskompiler auch schneller starten(?).
Mein Rechner ist auch unter Deiner Angabe (im fehlen da noch 32MB) und ich kann damit leben.
Deine Philosphie ist okay: Für alles seine eigene Applikation.
KDE will das halt anders und integriert daher viel mehr. Es soll ja ein Environment und nicht nur ein Toolkit mit WM sein.
Der oben genannte Konqueror gibt's auch als Embedded, da hat er wahrlich nicht so viel MB ;-)
Und warum gibt's den nicht für den Desktop? Weil die meisten lieber den Full-Featured als einen ganz schmalbrüstigen Browser wollen. Die Mehrheit entscheidet hier, sowohl als Entwickler als auch als Anwender. Und wie leicht es ist KHTML in ein simples Fenster zu packen, kennst Du auch.
Alle Projekte die kleine Browser haben wollten, sind wieder eingeschlafen, weil kaum einer so was will.
Ein paar MB mehr sind den meisten Anwendern weniger wichtig als hohe Performance (cachen), alle Seiten betrachten können (alle Bugs mit speziellem Code umschiffen), jedes Plugin, usw. usw.
Und halb können ist auch nicht fair, weil pauschal. Das solltest Du genauer erläutern.
und du hast recht, lincvs startet unter win schneller, aber auch unter unix ists noch ertraeglich. ich finde die qt zu gut, um auf c umzuschwenken ;-)
bei meinem altrechner kommt noch die susi 8 hinzu, die geht auch nicht zimperlich mit dem speicher um, aber auch das wird sich demnaechst erledigt haben...
es kann ja jeder machen was er will und damit gluecklich werden, aber es gibt genug beispiele aus der geschichte, wo eierlegende wollmilchsaeue gegen spezialisten den kuerzeren gezogen haben. aber davon abgesehen koennte ich mir vorstellen, dass integration nicht unbedingt mit massiver fettleibigkeit einhergehen muss. integration heisst wohl nicht, 500 anwendungen fuer alles, was die welt nicht mehr braucht. beschraenkung aufs wesentliche war schon immer eine tugend.
ich nehm mal an, den embedded-konqi gibts nicht auf dem desktop, weil die leute, die nen schlanken browser wollen, da eh nicht den konqi nehmen. ich will gerne glauben, dass es leicht ist, khtml in ein fenster zu stopfen, aber ich will nicht die dazugehoerige lib. ausserdem muss ich auch oft unter win arbeiten (genaugenommen meistens ;-( ), da find ichs gut, wenn meine lieblingsapplikation auch dort laeuft.
warum kleine browser bis jetzt nichts geworden sind, hat sicher ne ganze reihe von ursachen, auf jeden fall beobachte ich solche projekte.
das halb-koennen ist natuerlich pauschal postuliert. und ich kann hoechstens veraltete beispiele nennen, da ich kde ja nicht nutze. was mich immer massiv gestoert hat, waren bugs wie doppelte (uebereinanderliegende) icons, bildschirmschoner mit einem kleinen ausschnitt vom desktop statt des ganzen oder gar doppelt gestartete bildschirmschoner, gelegentliche abstuerze und dergleichen mehr. ich weiss zwar, dass ich den ueberfluessigen bildschirmschoner von der konsole aus killen kann, aber nicht meine Frau...
viele gruesse, Tilo