Login
Newsletter
Werbung

Thema: Aaron Seigo kritisiert Canonical

7 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von mgraesslin am Mo, 18. Februar 2013 um 18:02 #

siehe anderer Kommentar hier im Thread. Auf kde-look sind hoffentlich keine C++ Plasmoide, sondern scripted Plasmoide, die Plasma nicht blockieren sollten (wenn das doch ist, dann ist das ein Bug im Framework).

Wir reden hier also nur von Plasmoiden, welche von der KDE Community herausgegeben wurden und ja da ist gdb die einzige valide Lösung.

[
| Versenden | Drucken ]
  • 0
    Von iluminat23 am Mo, 18. Februar 2013 um 18:29 #

    Auf kde-look.org scheinen >260 Plasmoide als binary gelistet zu werden. Ich weiß jetzt nicht ob dies alle in C++ implementiert wurden oder ob es auch andere Möglichkeiten gibt ein Plasmid als binary bei kde-look zu platzieren.

    Gibt es ein Regelwerk, welches besagt, dass Plasmiden nur dann in C++ implementiert werden dürfen/sollen wenn diese direkt von der KDE-Community im Rahmen des KDESC gepflegt werden?

    Und wie schafft ihr es, dass bei gescripteten Plasmoiden dies nicht auftritt?

    Wird für das gescriptete Plasmoid ein eigener Prozess gestartet (der Interpreter)? Wenn ja, wiso kann dieser dann ohne Probleme Zeichnen aber für ein als Prozess gestartetes (C++) Plasmoid sollte dies nicht möglich sein?

    Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Feb 2013 um 18:31.
    [
    | Versenden | Drucken ]
    • 0
      Von Entwickler-Schlumpf am Di, 19. Februar 2013 um 10:55 #

      Pakete wie rpm, deb sind binary, tar.gz auch. Da die meisten oder viele Plasmoids aus mehr als eine Datei bestehen werden sie wohl gepackt beim hochladen.

      [
      | Versenden | Drucken ]
      0
      Von Entwickler-Schlumpf am Di, 19. Februar 2013 um 11:13 #

      Und wie schafft ihr es, dass bei gescripteten Plasmoiden dies nicht auftritt?

      Möglicher Ansatz; Ein eigener Prozess in dem scripted Plasmoids laufen, als kein eigener Prozess pro Script-Plasmoid weil zu teuer aber ein eigener Prozess für alle Script-Plasmoids. Das Ergebnis wird als eigene Anwendung(en) samt Fenster gezeichnet. Das Fenster ist fensterlos, durchsichtig und wird vor dem WM "versteckt". Ein Proxy Plasma-Applet, das im selben Prozess wie Plasma läuft, steuert das Fenster um es in die richtige Position zu bringen, Eingaben um-/weiterzuleiten, ...

      Mit QtQuick wird sich sowieso so einiges ändern und hat aich schon geändert weil dort ein eigener Renderthread und Scenegraph zum Einsatz kommt. Damit stellt sich die Frage nach der Legitimität von Prozessplittung wenn Crashfrei als Voraussetzung angenommen wird die mit Scripten einfacher zu garantieren ist.

      [
      | Versenden | Drucken ]
    0
    Von Otto am Mo, 18. Februar 2013 um 18:39 #

    Hm, also dürfen nicht Core-KDE-Community-Menschen kein C++ verwenden, um z.B. DataEngines oder anderes zu schreiben? So toll Javascript sein kann, aber manche Sachen, die man einbinden möchte, liegen nur per C/C++-Lib zur Anbindung bereit. Noch ne Uhr oder einen RSS-Reader oder ne Wetter-App, nee, das sind die einfachen Sachen.

    Und wieso dürfen dann Plasmoide überhaupt in C++ geschrieben werden? Denn der Traum von den Bug-freien Plasmoids, den kann ich nicht mitträumen, klar sollten Bugs gefixt werden, aber wie schnell geschieht das? Und wie schnell landet das auch beim Nutzer?

    Die Argumentation, nur C++-Plasmoids hätten solche Probleme, und die würden auch gründlich geprüft bevor sie beim Anwender ankommen, finde ich sehr idealistsisch, aber leider realitätsfern :( Überzeugt mich nicht, würde mich freuen, wenn Ihr eine Möglichkeit findet, Plasmoids transparent in eigenen Prozessen laufen zu lassen, mindestens die "absturzgefährdeten". Denn was ist z.B. der Unterschied zwischen KCalc und dem Calculator Plasmoid? KCalc läuft auch in nem eigenen Prozess. Und könnte ähnlich eingebettet werden wie der Calculator Plasmoid. Entsprechende D-Bus API, um KCalc's Erscheinungsbild je nach Einbettung anzupassen, voilà.

    [
    | Versenden | Drucken ]
    • 0
      Von mgraesslin am Mo, 18. Februar 2013 um 20:45 #

      C++ Plasmoide müssen kompiliert werden und an die richtige Stelle installiert werden. Sofern du nicht gerade weißt welche env Variablen du anpassen musst, läuft das auf installieren mit root-Rechten hinaus.

      Im Endeffekt bedeutet das, dass ein Plasmoid von einer Distribution angeboten werden muss - ich hoffe doch sehr, dass du nicht einfach Pakete von $IRGENDWO mit root Rechten installierst (nein kde-look ist keine vertrauenswürdige Quelle).

      Wenn eine Distribution das paketiert, dann erwarte ich zumindest eine gewisse QA die auch sein kann bei den Plasma Entwicklern nachzufragen: "schaut mal bitte drauf, ist das OK?"

      [
      | Versenden | Drucken ]
      • 0
        Von Otto am Mo, 18. Februar 2013 um 21:44 #

        Ich denke da vor allem an Inhouse-Plasmoids (nicht jeder will/muß seinen Spezialkram mit der Welt teilen, Teilen ist auch Verantwortung). Niemand kann garantieren, daß die nicht doch hier und ne Macke haben. Nun. daas gilt selbst für die von KDE ausgelieferten. Auch Profis schlampen mal, C++ ist da ungnädig. Als KDE-Community-Entwickler sollten Sie das ja wissen, all die bugs.kde.org-Einträgen schaffen einen kleinen Realitätsabgleich.
        Und im Produktiv-Einsatz ist es nicht akzeptabel, daß dann gleich die halbe Umgebung hängt. Da braucht man Stabilität. RAM ist billig im Vergleich zum Stundenausfall.
        Deswegen ist die derzeitige Umsetzung Mist. Welch historischen Gründe es auch gibt. Und dann ist ja auch nicht der ganze Workspace in einem Prozeß, das hatte ja sicher auch gute Gründe. Und diese Gründe sind für manche eben auch bei den Plasmoids wichtig. Niemand zwingt Euch. Ist nur ne Rückmeldung. Der Rest ist ja ziemlich nett (positiv gemeint). Aber das hier mit dem einen Prozeß ist und bleibt Mist, für mich und scheinbar ein paar andere.

        [
        | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung