bliet
Anmeldungsdatum: 10. Januar 2007
Beiträge: 841
|
So, habe es nun getestet mit dem DEB-Paket, welches Ikem auf GitHub zu Verfügung gestellt hat. Bei mir schließt sich ein Fenster immer, wenn ich ein Text markiere, welcher über mehrere Zeilen lang ist. Das sollte ja eigentlich nur passieren, wenn man das Fenster ganz nach unten zieht. Nicht schön.
|
lawl0r
Anmeldungsdatum: 17. Januar 2013
Beiträge: 8
|
Du kannst um das temporär zu lösen in der Datei /etc/opensnap/hit_bottom den Aufruf von "wmctrl" auskommentieren.
Ich empfehle dir allerdings die neuste Version nochmal versuchen zu kompilieren. Bei der sollte das Problem behoben sein und Aktionen sollten nur getriggert werden wenn man ein Fenster von der Titelleiste zieht. Leider gibt es dazu noch kein .deb Paket. Da müsstest du entweder Ikem lieb fragen, oder warten bis ich mich dazu aufraffe selber eins zu bauen. Wenn das auch mit der neusten Version auftritt bitte output von opensnap -v während das auftritt posten.
|
bliet
Anmeldungsdatum: 10. Januar 2007
Beiträge: 841
|
Ich habe nun die neuste Version kompeliert. Läuft super. Danke.
|
Ikem
(Themenstarter)
Anmeldungsdatum: 13. Januar 2011
Beiträge: 38
|
Ich hab mir heute die Zeit genommen und lawls Opensnap Version heruntergeladen, kompiliert und ein Paket gebaut. Ergebnis siehe Anhang.
- opensnap_1.0.0-1_i386.deb (9.6 KiB)
- Download opensnap_1.0.0-1_i386.deb
|
Ikem
(Themenstarter)
Anmeldungsdatum: 13. Januar 2011
Beiträge: 38
|
Wenn ich mir für Opensnap ein paar Features wünschen dürfte, dann wären das:
|
lawl0r
Anmeldungsdatum: 17. Januar 2013
Beiträge: 8
|
@bliet dass freut mich zu hören ☺ - Unsnap muss ich schauen inwiefern das möglich ist. Das wäre durchaus cool, aber da opensnap nicht die Informationen des WM's hat könnte das problematisch werden genau so umzusetzen wie bei Aero Snap (sprich dass man es einfach wieder wegziehen kann. Was möglich sein sollte wäre z.B. hit_bottom für unsnap zu verwenden. Ich persönlich nutze die schliessen Funktion eigentlich eh nie. Alternativ könnte man es unsnappen wenn ein gesnapptes Fenster nochmal gesnapped wird. - Das Offset muss eigentlich nicht automatisch erkannt werden. Das ist der Bereich in px der als Rand gilt, so dass wenn du z.B. ganz am rechten Rand klickst das nicht als "snap" gewertet wird, sondern dass du das Fenster quasi von aussen da reinziehen musst. Ich wüsste jetzt nicht was man da automatisch erkennen soll, ich denke 10px sollten als default wert gut funktionieren. Oder hab ich dich falsch verstanden? - Ein schickes Icon. Hmm, ich habs nicht so mit Design aber ich schau mal was ich machen lässt. Ich nehme auch gerne Vorschläge entgegen 😉 Zuletzt noch wäre ich froh wenn wir Feature Requests und co. bei GitHub als Issues tracken könnten, dann sind die Informationen auch alle schön zentral beisammen.
Was ich als nächstes bauen wollte ist ein .deb generator script und ein target für make install. Wenn du nichts dagegen hast Ikem würde ich da gerne deine debs als Basis nehmen. @Ikem
Das deb hat noch die alten configs.
|
Ikem
(Themenstarter)
Anmeldungsdatum: 13. Januar 2011
Beiträge: 38
|
Ich benutze LXDE und habe am oberen Rand ein Panel das 26 Pixel gross ist. Wenn ich nun Opensnap ohne "--offset 26" starte, dann muss ich das Fenster ganz nach oben schieben, damit es maximiert wird. Sprich, Opensnap erkennt nicht automatisch, da ist ein oder mehrere Panel, die muss ich vom sichtbaren Bereich abziehen.
|
lawl0r
Anmeldungsdatum: 17. Januar 2013
Beiträge: 8
|
Phu, ich schau mal ob ich per EWMH irgendwie an die Informationen des paddings für den WM komme. Das einzige was mir gerade einfällt ist ein (wenn möglich unsichtbares) Fenster horizontal und vertikal zu maximieren via EWMH und dann mit der Bildschirmgrösse zu vergleichen. Das wird aber auch Probleme machen bei Multihead setups, da xrandr die screensize aller Schirme zusammen liefert, wobei es hier sicher möglich ist die Grösse eines einzelnen Heads zu holen. Ich glaube aber ehrlichgesagt aber nicht dass ich das in absehbarer Zukunft implementieren werde, opensnap ist jetzt schon ein Zusammengewürfle von fragilen hacks und ich denke nicht dass das viele Leute stören wird. Ich lasse mich aber auch gerne eines besseren belehren. Du kannst natürlich auch einfach einen Pull-Request mit funktionierendem code dazu öffnen. Ich merge das dann gerne 😉
|
Ikem
(Themenstarter)
Anmeldungsdatum: 13. Januar 2011
Beiträge: 38
|
Also wie man an diese ganzen Werte kommt weiss ich. Den aktiven Desktop bekommt man z.B. mit: user@host: xprop -root|grep "_NET_CURRENT_DESKTOP(CARDINAL)"
_NET_CURRENT_DESKTOP(CARDINAL) = 0 An die Werte für den "Viewport", also den sichtbaren Bereich kommt man u.a. mit: user@host: xprop -root|grep "_NET_WORKAREA(CARDINAL)"
_NET_WORKAREA(CARDINAL) = 0, 26, 1024, 768, 0, 26, 1024, 768 Wobei jeweils vier Werte für einen Desktop stehen, und die vier Werte für: $X, $Y, $WIDTH, $HEIGHT Quelle: http://standards.freedesktop.org/wm-spec/1.4/ar01s03.html Beispiel: http://www.futuredesktop.org/tmp/desk-test.c
|
Ikem
(Themenstarter)
Anmeldungsdatum: 13. Januar 2011
Beiträge: 38
|
Bzgl. des Paketes, das hab ich erst vor kurzem gebaut. Ich hab das Paket heruntergeladen, entpackt und die Konfigurationsdateien mit denen im Repo verglichen. Die Konfigurationsdateien sind identisch. Ich hab übrigens nichts dagegen, das du meine Pakete als Basis für deine Pakete nimmst. Irgendwann wollte ich das sowieso wieder abgeben. Und ich hatte auch daran gedacht das Debian-Paket von "make" bauen zu lassen. Hab aber noch nicht raus wie. Um den Paketbau wenigstens etwas zu automatisieren, hab ich mir dieses Skript geschrieben.
|
bliet
Anmeldungsdatum: 10. Januar 2007
Beiträge: 841
|
Falls ihr noch irgendwelche Hilfe braucht, bin ich auch bereit was zu machen.
Die nächsten drei Wochen hab ich eher weniger Zeit, danach aber 😉 Was ich mir wünsche würde (kann es auch später in GitHub einpflegen) wäre eine Config-Datei, in der man die Parameter definieren kann. Oder eine kleine GUI. Das wäre für den normalen User zumindest schön. Man könnte ja in GitHub mal ein alles Sammeln und dann Milestones festlegen?
|
lawl0r
Anmeldungsdatum: 17. Januar 2013
Beiträge: 8
|
Ich habe für die Vorschläge mal github issues eröffnet. Ihr könnt gerne weitere aufmachen.
Experimentelle/unvollständige Unterstützung für unsnapping ist bereits umgesetzt: https://github.com/lawl/opensnap/issues/4
|
Ikem
(Themenstarter)
Anmeldungsdatum: 13. Januar 2011
Beiträge: 38
|
Ich hab mir den Quellcode aus dem unsnap Zweig heruntergeladen. Ich bekomme beim kompilieren ein paar Fehlermeldungen.
|
lawl0r
Anmeldungsdatum: 17. Januar 2013
Beiträge: 8
|
Ikem schrieb: Ich hab mir den Quellcode aus dem unsnap Zweig heruntergeladen. Ich bekomme beim kompilieren ein paar Fehlermeldungen.
Das sind "nur" warnungen, gebaut haben sollte es trozdem. Ich hab den Code nicht aufgeräumt da es noch nicht so funktioniert wie ich will.
|
JörnS
Anmeldungsdatum: 25. November 2010
Beiträge: 2107
|
Huhu, ich war eben beim Meeting von der Lubuntu Quality Assurance. In zumindest einem Blog ( http://lubuntublog.blogspot.com.es/2013/06/aerosnap-feature.html ) wird berichtet, das das Aerosnap-Feature in 13.10 ausgeliefert wird. Davon abgesehen, dass es nicht stimmt - es wäre ja toll. Hat jemand schon mal angestoßen, das Opensnap in die Repos aufgenommen wird? EDIT, 27.06.13 Hab eben in der Mailingliste gesehen, es geht seinen Gang. Wooooohoooo! ☺
|