suche Helfer für Entwicklung ''Resizeable Textarea 0.2''

    Hallo!

    Nach Monaten, in denen ich Bugmeldungen und vor allem Erweiterungswünsche zu der Extension bekommen habe, habe ich mich jetzt aufgerafft und will eine neue Version herausbringen.
    Dabei möchte ich allerdings sehr ungern wieder ganz alleine dasitzen und mich mühsam duch die "Dokus" wühlen. Ich würde mich sehr über ein wenig Hilfe freuen, was das Bug-testen angeht und vor allem neue Funktionen, mit denen sich andere evtl. schon beschäftigt haben.

    zu den Neuerungen sollen gehören:
    - die Unterstützung von einzeiligen Textfeldern
    - Speichern der Einstellungen für einzelne Domains ähnlich, wie in uri_id
    - Unterstützung von initial versteckten Textareas (z.b. quickreply-felder in hidden div's)
    - Updatefunktion z.b. über http://mozdev.org/ oder erweiterungen.de
    - Kompatibilität zu Firefox 1.5* (am liebsten erst, wenn die "Stable" rauskommt)

    die dazu erforderlichen Funktionen, für die ich Codebeispiele suche, wären:
    - lesen/schreiben der userContent.css
    - Updateroutine und alles, was man dazu wissen sollte
    - verschiedene Funktionen, wie sie in uri_id benutzt werden (am besten jemand, der sich mit dem quellcode schon mal beschäftigt hat)

    Dieses Rumgefrickel mit den jämmerlichen Dokus zum Mozilla für die gecko-spezifischen javascript-Funktionen möchte ich mir nach Möglichkeit ersparen, wenn sich damit jemand schon beschäftigt hat.

    Eine Frage habe ich dazu noch: Muss ich nach jeder Änderung den Fux neu starten, oder gibt es auch eine andere Möglichkeit, die Extension neu zu laden?

    PS:
    - enentuell könnte ich auch noch etwas hilfe bei der übersetzung gebrauchen, obwohl die sich sowieso nur auf das about-fenster beziehen wird.

    Hallo raik,

    Zitat

    Dabei möchte ich allerdings sehr ungern wieder ganz alleine dasitzen und mich mühsam duch die "Dokus" wühlen. Ich würde mich sehr über ein wenig Hilfe freuen, was das Bug-testen angeht und vor allem neue Funktionen, mit denen sich andere evtl. schon beschäftigt haben.


    Da hier nicht viele rumlaufen, die sowas können, solltest du es vllt. auch im MozillaZine versuchen. (Ich bin leider mit Search Engine Ordering voll ausgelastet, Firefox 1.5 bedeutet auch dafür einige Anpassungen, z.B. den ganzen Kompatibilitätskram mit 1.0.x rauswerfen)

    Zitat

    zu den Neuerungen sollen gehören:
    - die Unterstützung von einzeiligen Textfeldern
    - Speichern der Einstellungen für einzelne Domains ähnlich, wie in uri_id
    - Unterstützung von initial versteckten Textareas (z.b. quickreply-felder in hidden div's)
    - Updatefunktion z.b. über http://mozdev.org/ oder erweiterungen.de
    - Kompatibilität zu Firefox 1.5* (am liebsten erst, wenn die "Stable" rauskommt)


    Ich weiß jetzt nicht, wie du die Größenänderung realisiert hast, aber würde es vielleicht auch ein persist-Attribute tun?
    Bei mir läuft Resizeable Textarea übrigens mit den neusten 1.8-Branch-Nightlies, ich musste nur manuell die maxVersion hochsetzen.

    Zitat

    die dazu erforderlichen Funktionen, für die ich Codebeispiele suche, wären:
    - lesen/schreiben der userContent.css


    das macht glaube ich Flashblock, da kann man sich das sicher abschauen

    Zitat

    - Updateroutine und alles, was man dazu wissen sollte


    Ein Tutorial gibt's hier. Einfacher ist es, die Erweiterung einfach bei update.mozilla.org hochzuladen.

    Zitat

    - verschiedene Funktionen, wie sie in uri_id benutzt werden (am besten jemand, der sich mit dem quellcode schon mal beschäftigt hat)


    URI-ID wird ja in Firefox 1.5 überholt sein von daher solltest du überlegen, ob dir die Kompatibilität zu Firefox 1.0.x den Aufwand, manchen Code doppelt zu schreiben Wert ist...

    Zitat

    Eine Frage habe ich dazu noch: Muss ich nach jeder Änderung den Fux neu starten, oder gibt es auch eine andere Möglichkeit, die Extension neu zu laden?


    für Firefox 1.5 gibt es eine einfache Lösung: http://kb.mozillazine.org/Getting_starte…ion_development
    Firefox 1.0.x braucht einige komplizierte Verrenkungen, die ich allerdings nicht wirklich kenne.

    Also, beta testen, bugs suchen und ähnliches würde ich machen. Mit den Funktionen halfen könnte etwas schwieriger werden, da müsste ich mich genauso durch die dokus wühlen.

    Aber wozu willst du die UserContent.css bearbeiten? Das ließe sich IMHO eleganter lösen, auch wenn ich nicht genau weiß, was du erreichen willst.

    uri_id fügt in jede seite ein css-attribut ein.
    aus "http://www.google.com" würde z.b. "www-google-com" .
    dadurch kann ich in der userContent.css zu jeder textarea auf jeder seite extra die breite und höhe speichern.
    diese zuweisung würde dann später der fux selber aufgrund der userContent.css vornehmen. ich muss das nicht mit der extension bei jeder neu geladenen seite in einer ini suchen und selber einfügen. performance-gründe also hauptsächlich.

    wenn du eine bessere lösung hast?

    Zitat von Dr. Evil

    Ich weiß jetzt nicht, wie du die Größenänderung realisiert hast, aber würde es vielleicht auch ein persist-Attribute tun?


    kannst du mich darüber mal näher aufklären? ich hab was von einer "persist database" gefunden, aber nicht, was es damit genau auf sich hat. vielleicht hilft es ja ...

    ich werd wohl ne debug-funktion integrieren, um das zukünftig leichter zu machen.
    ich gehe alle textareas einer seite durch und positioniere jeweils ein div unten quer, eins rechts hochkant und eins genau auf der ecke (wegen der unterschiedlichen cursor 3 stk.). dann gibts pro seite noch ein div, das onmousedown den angezeigten cursor übernimmt und das ganze fenster abdeckt, damit der mauszeiger sich beim ziehen über andere elemente nicht ändert. (rein optische sache)
    dann wird einfach onmousemove die textarea resized (style="width:;height: ") und onmouseup die divs neu positioniert und das cursor-div "minimiert" (0,0).

    die divs hänge ich am ende des dokumentes ein, um andere scripte möglichst nicht zu beeinflussen.
    eina andere lösung wäre, ne tabelle um die textarea zu legen:

    Code
    <table border=1>
  <tr>
    <td><textarea></textarea></td>
    <td>resize horizontal</td>
  </tr>
  <tr>
    <td>resize vertical</td>
    <td>resize beide</td>
  </tr>
</table>


    da hätte ich weniger arbeit mit dem nachführen der divs, könnte aber das ursprüngliche dokument beeinflussen.
    und ohne code-injection in das dokument kann ich ja auf seine elemente nicht zugreifen.

    eine andere lösung wäre, beim resizen nur erst mal ein div mit "dotted border" anzuzeigen, das resized wird, und erst onmouseup die textarea anzupassen. wäre performanter, würde weniger ruckeln, als jetzt.
    so funktioniert es in windows ja auch ...

    wenn das ginge, würde ich ja glatt das html:textarea element des browsers "überladen", also eine eigene konstruktion bereitstellen, die dann einfach die zusätzliche funktionalität mitbringt und sioch ansonsten wie das orginal verhält, aber dazu müsste ich vermutlich direkt kontakt mit den devs des gecko bekommen ...

    Wie Evil bereits empfohlen hat würde ich das URIid Verfahren nicht verwenden, sondern diesen einen CSS Selektor der Styles nur auf Seiten einer bestimmten URL anwendet. Auswendig weiß ich den jetzt nicht, aber ich find ihn raus wenn's sein muss.
    Zum Speichern: Mir ist bist jetzt auch noch keine elegante Lösung eingefallen, aber direktes speichern in der userChrome wäre nicht wirklich wünschenswert, da du diese dann 1. extrem voll machst und 2. spätestens nach einer Änderung des Users. (Ich würde am ehesten alles in eine Variable speichern nach dem Schema:
    info1,info2,info3;info1,info2,info3;
    usw.)
    Aber die Speicherung wäre noch das geringste Problem. Wie willst du ein Textfeld erkennen? Das geht z.B. per ID (so blockt z.B. Adblock Plus Div-Tags), allerdings hat nicht jedes Textfeld eine ID. Dann könnte man noch beim obersten Element anfangen und dann weiter nach unten gehen. Allerdings unterstützt Firefox kein nth-child soweit ich weiß, sodass man ein Problem hat, wenn mehrere Textboxen in einem Element sind.
    Davon abgesehen hätte die letztere Methode den Nachteil, dass durch leichte Verschiebung die Textbox nicht mehr erkannt wird, z.B., dass die Textbox nicht mehr in dem 2. div Tag ist, sondern schon im 3.

    Grüße

    als erstes: persist geht so wohl nicht.

    Um zu verhindern, dass die userContent.css zu groß wird könnte man auch eine eigene Stylesheet-Datei anlegen und sie über @import nachladen. Das bräuchte nur eine Zeile. Ich denke aber nicht, dass das so sauber ist, da die CSS-Datei und die @import-Zeile ja bei der Deinstallation nicht entfernt werden und die Größen dann auch danach noch ohne Änderungsmöglichkeit bestehen bleiben würden.
    Deshalb meine ich, es wäre sauberer, dass ähnlich wie RIP über XPATH und extra XML-Dateien zum Speichern zu machen, die beim Laden jeder Seite (evtl. auch gecached) ausgelesen werden

    also
    1. was hat es mit diesem "persistent"-attribut auf sich? das würde ich schon gern wissen, selbst wenn es hier nichts nützt.
    2. der url-spezifische css-selector ist erst ab ff 1.5 verfügbar. damit würde ich alle älteren versionen ausschliessen.
    3. die einstellungen in die userChrome zu importieren, war geplant.
    was hat esmit XPATH auf sich? wo gibts dazu infos und beispiele?
    die userContent.css hätte den vorteil, dass das der bowser ganz regulär verarbeitet, ohne dass ich das alles per script machen muss. verarbeitet denn der browser diese xml-dateien automatisch, oder muss ich das auch noch per script machen?
    ich kann mir ja so schon genug szenarien vorstellen, wo sich mein code mit dem der seite ins gehege kommen könnte.

    ich glaub, ich werd mal probieren, direkt in der textbox.xml (toolkit.jar) das html:textarea element zu manipulieren. wäre doch die eleganteste lösung ...

    ich verstehe die frage nicht: "Wie willst du ein Textfeld erkennen?"
    textareas spricht manauf DOM-ebene an:
    var TA = document.getElementsByTagName('textarea');
    und spricht sie per index an.
    var ersteTextarea = TA[0];
    ich könnte natürlich auch ein eigenes attribut definieren und dem eine eindeutige id zuweisen. nur kann ich darauf dann bei der permanenten speicherung nicht zurückgreifen, weil das ja nicht erhalten bleibt, wenn die seite verlassen wird.

    1: das "persist"-Attribut ist XUL-only deshalb hier nicht anwendbar: http://www.xulplanet.com/tutorials/xultu/persist.html

    2: meine Meinung: Warum alte Versionen unterstützen?

    3: die Dateien müsstest du selbst per Script auslesen. Beispiele zu XPATH findest du in sehr vielen Greasemonkey-Scripts. Kurz gesagt kannst du mit XPATH ein (oder mehrere) bestimmtes Element ohne aufwändiges DOM-rumgehopse (childNodes[*].childNodes[*]...) finden.

    4: Die 0. Textarea könnte ja vom Autor der Seite entfernt werden sodass der Index aller anderen Textareas plötzlich falsch wäre...

    1. Ja das setzt man z.B. in XUL-Fenstern ein um die Größe und/oder Position eines Fenster zu speichern.
    2. Ich stimme mit Evil überein, schließlich sprechen wir ja nicht von IE7 der alle älteren ausschließt, sondern von Firefox. Da die neue Version keine Nachteile gegebenüber der alten hat, wird es den Leuten auch nicht schwer fallen upzudaten da im Moment sowieso schon recht viele mit der Beta2 surfen.
    3. Ich würde zwar nicht in der userContent direkt speichern, sondern wie gesagt alle nötigen Informationen per XML speichern oder sonst wie und beim Laden des Fuches dann eine css Datei erstellen die man dann einfach in die userContent importiert. Die Styles per Script einzubinden hat den gravierenden Nachteil, dass die Textbox normal ist und erst nach dem Laden, wenn das Script also ausgeführt wird, sich auf die angepasse Größe ändern. Entsprechend müsste bei einer Größenänderung der Seite diese Datei spätenstens beim Verlassen der Seite neu geschrieben werden.
    Zu XPath gibt es http://www.w3schools.com/xpath/xpath_intro.asp hier eine sehr gute Anleitung. Vereinfacht gesagt ist das ganze eine schnellere Methode Elemente zu selektieren ähnlich wie in CSS via Attribut, Eltern, Kindern usw. Diese Methode ist zum Speichern ganz praktisch, aber wenn du sowieso das ganze ohne Script (zum Laden der gespeicherten Größen) machen willst kannst du dir auch ein "eigenes" Format überlegen - je nach dem was du nötig hälst für die Speicherung (man könnte auch direkt die nötigen CSS Selektoren und Anweisungen speichern)

    zu 4.
    who cares?
    wenn das einmal im jahr passiert, kann der anwender die textareas auch neu resizen. für mich gibt es doch sowieso keine möglichkeit, die neu hinzugekommene textarea zu identifizieren und es wäre auch mit kanonen auf spatzen geschossen.

    mal sehen, ob ich es hinbekomme, das html:textareaelement des browsers zu erweitern ...
    vielleicht garnicht mit dragmarks, sondern mit einer neuen tastenkombination (alt + ⇒) (alt + ⇓)?

    4. Stimmt schon, irgendwo hast du recht.

    Allerdings würde ich lieber die Textareas noch per Maus ändern. Das ist irgendwie "intuitiver", weil man zwar schnell ist, aber auch sehr genau sein kann. Bei Tastenkombinationen muss man ja in bestimmten Schritten gehen. Je größer desto ungenauer, je kleiner desto langsamer. Außerdem habe ich meine Winamp Kontrollen auf Alt+Pfeiltasten bebunden, aber das wäre eher zweitrangig.

    Zur textbox.xml: Die Idee hört sich gut an, aber ich glaube in der textbox.xml wird garnicht die Textarea definiert, sondern die Textbox. Zumindestens scheint dort die Textarea schon zu existieren und diese wird nur als Ausgangselement für die XUL Textbox verwendet...
    Grüße
    xeen

    die html-elemente sind wohl im kompilat definiert, da geht nix, also wieder der weg über ne extension.

    hab mal zwei ideen umgesetzt:

    beim ersten einfach der textarea mit nem click den focus geben, dann "Esc" und mit der maus reinclicken und ziehen.

    das zweite funktioniert ähnlich, wie meine ursprüngliche umsetzung, nur dass jetzt beim ziehen erst ein rahmen gezeigt und resized wird, ähnlich der funktionsweise von windows, wenn "fensterinhalt beim ziehen anzeigen" deaktiviert ist. erst nach dem loslassen wird die textarea angepasst. hat nur den nachteil, dass sie sich dann noch seitlich verschiebt, wenn die umgebenden tabellen relative breiten haben.

    mir gefällt die erste lösung besser, sogar besser, als die aus der version 0.1a .

    EDIT:
    oder sollte ich die resizefunktion lieber per kontextmenü aktivieren? dass man "resize" auswählt, in die textarea clickt, resized und beim loslassen der maus wird das ganze wieder deaktiviert. wenn ich die werte speichere, käme das ja nicht so oft vor.
    oder ähnlich adblock über nen unten rechts eingefügtes element zum aktivieren?

    PPS:
    ein problem sehe ich mit den "per-site user stylesheets" noch:
    da auf einer website mehrere, verschiedene seiten mit textareas vorkommen können, muss ich den ganzen pfad angeben.
    und wenn jemand per mode-rewrite da z.b. die session-id eingebaut hat, wirds verdammt schwierig.

    EDIT2:
    links zu temporären testseiten entfernt.

    Sieht nett aus, wobei das erste Beispiel bei mir nicht klappt und du beim 2. Beispiel falsche cursor verwendest.

    n-resize (n=north=Norden=Oben) auf dem unteren rand macht genauso wenig sinn, wie w-resize (w=west=Westen=Links) auf dem rechten Rand. :wink:

    Wo is der Unterschied bei beiden Demos?! In Firefox 1.5b2 kann ich beide einfach sofort nach dem Laden der Seite an ihren Kanten anpacken und beide ändern auch sofort ihre Größe und der eingegebene Text fließt neu im Element.

    Die erste Demo funktioniert bei mir überhaupt nicht.
    Die zweite finde ich gut.

    Aber wieso muß ich in künftigen Versionen irgendwelche Tasten drücken oder Menüitems auswählen?
    Am besten finde ich die Vorgehensweise aus Version 0.1a. Warum soll die eigentlich geändert werden?

    Zitat von JonHa

    Sieht nett aus, wobei das erste Beispiel bei mir nicht klappt und du beim 2. Beispiel falsche cursor verwendest.

    n-resize (n=north=Norden=Oben) auf dem unteren rand macht genauso wenig sinn, wie w-resize (w=west=Westen=Links) auf dem rechten Rand. :wink:

    "funktioniert nicht" ist keine fehlerbeschreibung. :wink:

    • was hast du in welcher reihenfolge gemacht?
    • was sagt die javascript-konsole?
      • fehler?
      • warnungen?
      • mitteilungen?
    • welche browserversion?
    • welches betriebssystem?
    • ...?

    zu den cursorn: was ist daran falsch? unter windows sind n-resize mit s-resize und w-resize mit o-resize optisch identisch. (doppelpfeile)

    xeen
    du hast aber ohne installierte version 0.1a getestet?. :wink:

    caveman
    siehe oben, "funktioniert nicht" ist keine fehlerbeschreibung.

    Zitat von Raik

    caveman
    siehe oben, "funktioniert nicht" ist keine fehlerbeschreibung.


    Na denn:
    • RTA v0.1a natürlich zuvor deaktiviert und Fx neugestartet
    • Auf der Seite habe ich in die Textarea geklickt, Esc gedrückt und dann versucht, die Textarea zu ziehen. Es erscheint aber kein Zieh-Cursor und auch so läßt sich da nichts ziehen
    • in der JS-Console passiert absolut nichts
    • keine Warnungen, keine Mitteilungen
    • Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 (XP Home und Pro getestet)

    Aber nochmal die Frage: Was ist denn so schlecht an der Art, wie v0.1a die Box vergrößert? Funktioniert doch, und ohne irgendwas zu klicken oder drücken.