staging.inyokaproject.org

Ich bin gerade dabei, bei einem meiner Programme DND zu implementieren, was im Prinzip überraschend einfach war. Aber ich beobachte jetzt einige Unregelmäßigkeiten und habe noch keine Ahnung wie ich darauf reagieren soll/kann/muss.

• Dateimanager scheinen bei ihrer Meldung immer den Protokoll Präfix mitzugeben (Nautilus, Thunar).

• Bildbetrachter wie GQview, Geeqie, gThumb, ...) senden nur den Pfad zur Datei.

Das ist doof, da es eine einheitliche Behandlung verunmöglicht.

Was ich aber wirklich nervig finde, ist dass manchmal, nachdem ich von gThumbs oder Nautilus eine Datei in meine Anwendung gezogen habe, der Cursor verändert bleibt. Der Cursor ist kurz vor den Drop noch die "moving hand" mit einem Pluszeichen. Nach dem loslassen bleibt oft (aber nicht immer) die "moving hand" übrig anstelle des standard Cursors.

Ich würde gerne die Regelmäßigkeit dahinter erkennen oder hätte gerne einen Tip, wie ich das abstellen oder dahinter kommen kann woran das liegt. Das erweckt beim Benutzer den Eindruck, das Bild im Fenster verschieben zu können, was aber nicht geht, da es erstmal in das Fenster eingepasst (skaliert) wird.

Installiert habe ich das Ganze nach diesem Tutorial.

Dakuan schrieb:

Ich bin gerade dabei, bei einem meiner Programme DND zu implementieren, was im Prinzip überraschend einfach war. Aber ich beobachte jetzt einige Unregelmäßigkeiten und habe noch keine Ahnung wie ich darauf reagieren soll/kann/muss.

• Dateimanager scheinen bei ihrer Meldung immer den Protokoll Präfix mitzugeben (Nautilus, Thunar).

• Bildbetrachter wie GQview, Geeqie, gThumb, ...) senden nur den Pfad zur Datei.

Das ist doof, da es eine einheitliche Behandlung verunmöglicht.

Meinst Du, manche senden einen URI und andere nur einen Dateinamen? Das wäre doch einfach zu reparieren, indem man einfach bei Dateinamen eine file:// URI erzeugt.

Was ich aber wirklich nervig finde, ist dass manchmal, nachdem ich von gThumbs oder Nautilus eine Datei in meine Anwendung gezogen habe, der Cursor verändert bleibt. Der Cursor ist kurz vor den Drop noch die "moving hand" mit einem Pluszeichen. Nach dem loslassen bleibt oft (aber nicht immer) die "moving hand" übrig anstelle des standard Cursors.

Das klingt, als ob es entweder ein Bug irgendwo (Fenstermanager?) wäre oder Du das D&D-Protokoll vielleicht an einer Stelle nicht richtig bedienst.

Installiert habe ich das Ganze nach diesem Tutorial.

Das ist schon ein paar Jahre alt, also vielleicht nicht mehr aktuell...

Meinst Du, manche senden einen URI und andere nur einen Dateinamen?

Ja, genau. Hier mal eine Übersicht (erzeugt mit diesem Testprogramm).

PASTE: file:///home/manfred/prog/img/imgtest/img_err00.png
PASTE: /home/manfred/prog/img/imgtest/img_err00.png
PASTE: Ich hasse Anglizismen, das ist Bullshit.

Zeile 1 ist von einem Dateimanager, Zeile 2 von Geeqie und Zeile 3 ist ein markierter Text, den ich einfach nur vom Editor reingezogen habe.

Da heißt, ich müsste eigentlich auch noch überprüfen, ob ich da wirklich einen gültigen Dateinamen bekommen habe.

Dazu kommt dann noch folgendes: wenn mehrere Dateien markiert wurden, liefern Dateimanager die Namen immer sortiert ab, Bildbetrachter wie z.B. gThumbs liefern die Namen in der Reihenfolge ab, wie sie ausgewählt wurden. Werden mehrere Namen übergeben, werden diese durch '\n' getrennt, wobei ich mich dunkel erinnere, das dieses Zeichen theoretisch auch Bestandteil eines gültigen Namens sein kann. Ist halt lästig, wenn man alle solche Sonderfälle prüfen muss.

Das klingt, als ob es entweder ein Bug irgendwo (Fenstermanager?) wäre oder Du das D&D-Protokoll vielleicht an einer Stelle nicht richtig bedienst.

Am Fenstermanager liegt das mit Sicherheit nicht. Das passiert auf 2 unterschiedlichen Rechnern (Gnome, Xfce). Aber ich habe noch keine Idee, wie ich die Fehlerstelle eingrenzen soll. Wenn ich mich mit dem Debugger zu lange im Event Handler aufhalte, wird das gezogene Objekt wieder an seinen Ursprungsort zurückgezogen. Es gibt da offenbar ein Timeout.

Ich werde heute Abend mal versuchen, mir alle fraglichen Events auf der Konsole auszudrucken.

... oder Du das D&D-Protokoll vielleicht an einer Stelle nicht richtig bedienst.

Einen Fehler habe ich gerade gefunden. Im bereits genannten Tutorial steht:

• FL_PASTE

Indicates that buffer returned by Fl::event_text() is ready to be read by the widget. The widget's handle() function must return 1 to indicate that it has accepted the event.

Mein Programm hat aber das "must" ignoriert und nur dann eine 1 zurückggegeben, wenn das Bild erfolgreich geladen werden konnte. Das habe ich jetzt korrigiert, wodurch der Fehler aber nicht verschwindet. Aber das wundert mich auch nicht, denn mit "unbekannten" Dateien hatte ich bisher auch nicht wirklich getestet.

Aber obwohl der Fehler nicht zuverlässig reproduzierbar ist, wächst in mir der Verdacht, dass es sich hier um eine Art "Race Condition" handeln könnte.

Also wenn die Drop/FL_PASTE Meldung kommt, lädt mein Programm das entsprechende Bild (im Event-Handler), was je nach Größe etliche zig bis hundert Millisekunden dauern kann, wodurch die positive Rückmeldung entsprechend verzögert wird. Der Fehler tritt manchmal auf, wenn während dieser Zeit die Maus in einen Bereich außerhalb meines Programmfensters bewegt wurde.

Interessant ist aber, das der "falsche" Mauscursor sich nur zeigt, wenn die Maus sich wieder innerhalb meines Programmfensters befindet. Andere Programme betrifft das nicht.

Daher sehe ich momentan 2 Hauptverdächtige:

• Ich mache immer noch etwas falsch

• Es gibt einen Bug im FLTK Toolkit

Letzteres nachzuweisen dürfte schwierig sein, aber ich könnte die Auswirkung wegspielen, indem ich nach Behandlung des Events immer den Standard Cursor setze (noch nicht getestet).

Davon unabhängig würde mich aber noch interessieren, mit welchen Variationen der Meldungstexte (DND payload) ich noch rechnen muss. In einem der Kommentare zum o.g. Tutorial wurde ja vage angedeutet, dass unter Windows (mingw) die Texte auch mit "C:" beginnen können (was ich hier aber nicht überprüfen kann).

Sollte hierzu noch jemand Angaben machen können, immer her damit.

Dakuan schrieb:

Aber obwohl der Fehler nicht zuverlässig reproduzierbar ist, wächst in mir der Verdacht, dass es sich hier um eine Art "Race Condition" handeln könnte.

Sehr möglich.

Also wenn die Drop/FL_PASTE Meldung kommt, lädt mein Programm das entsprechende Bild (im Event-Handler), was je nach Größe etliche zig bis hundert Millisekunden dauern kann, wodurch die positive Rückmeldung entsprechend verzögert wird. Der Fehler tritt manchmal auf, wenn während dieser Zeit die Maus in einen Bereich außerhalb meines Programmfensters bewegt wurde.

Das ist aber auch ein No-Go: im Eventhandler tut man nichts, das länger dauert - insbesondere kein IO. Der Event-Handler muss ja nur zurück liefern, dass er den Drop erfolgreich angenommen hat. Das bedeutet m.E. nicht unbedingt, dass er die Inhalte auch fehlerfrei verarbeiten kann. Ich vermute die Rückmeldung ist nur dazu gedacht, sicherzustellen, dass man Dinge auf einer Drop-Site fallen lässt, die die entgegen nehmen kann. Wenn z.B. der Empfänger nichts mit einer URI anfangen könnte, sollte man das dann entsprechend zurückmelden.

Daher sehe ich momentan 2 Hauptverdächtige:

• Ich mache immer noch etwas falsch

s.o.

• Es gibt einen Bug im FLTK Toolkit

Das ist auch immer eine Möglichkeit. Hast Du mal deren Bug-Datenbank konsultiert?

Davon unabhängig würde mich aber noch interessieren, mit welchen Variationen der Meldungstexte (DND payload) ich noch rechnen muss. In einem der Kommentare zum o.g. Tutorial wurde ja vage angedeutet, dass unter Windows (mingw) die Texte auch mit "C:" beginnen können (was ich hier aber nicht überprüfen kann).

Das wäre ein typischer Windows-Dateipfad.

Der Event-Handler muss ja nur zurück liefern, dass er den Drop erfolgreich angenommen hat.

Dieses Ereignis muss aber noch irgendwie Verarbeitet werden. Ich werd' dann mal versuchen den Trick mit der Timeout Funktion aus dem Beispiel zu übernehmen.

Hast Du mal deren Bug-Datenbank konsultiert?

Da habe ich nichts passendes gefunden.

Das wäre ein typischer Windows-Dateipfad.

Viele FLTK Anwendungen laufen unter Windows (mit mingw) oder Mac. Das Beispiel in meinem ersten Link wohl auch, da es am Ende der Strings immer "\r\n" erwartet und diese 2 Bytes ungeprüft abschneidet, wodurch unter Linux immer das letzte Zeichen des Namens fehlt.

Ich habe den verzögerten Callback jetzt eingebaut. Im event Handler werden jetzt nur noch die benötigten Daten kopiert und die eigentliche Bearbeitungsfunktion wird über den Timeout aufgerufen, nachdem das Drop Event quitiert wurde. Im Event Handler passiert nur noch dies:

int ImageBox::handle( int event ) {
    int ret = 0;
    ...
    switch( event ) {
        ...
        case FL_PASTE:
            evt = event;
            evt_len = Fl::event_length() + 1;
            delete [] evt_txt;
            evt_txt = new char[evt_len];
            strcpy( evt_txt, Fl::event_text() );
            if(callback() && ((when() & FL_WHEN_RELEASE) || (when() & FL_WHEN_CHANGED)))
                Fl::add_timeout( 0.0, ImageBox::callback_deferred, (void*)this );
            ret = 1;
            break;
        ...
    }
    ...
}

Aber der erhoffte Erfolg ist ausgeblieben. Ich hatte schon nach 10 Versuchen wieder den falschen Cursor. Damit kann ich das mit der Race Condition wohl ausschließen. Aber der Effekt tritt nach wie vor nur auf, wenn der Cursor nach dem Drop noch bewegt wurde. Das habe ich jetzt aber nur unter Gnome getestet. Den Xfce Test mache ich morgen.