I used to store my calendars, contacts, tasks at Google and sync them from there to my android phone and thunderbird/lightning on different machines running linux or win*. For a number of reasons I decided to deGoogle my data habbits and have migrated to an ownCloud server.

Google contact has a rather easy to use way of grouping contacts, actually it's more like tagging the contacts to belong to a group. Android supports those groups out of the box. Thunderbird, with the help of an addon, syncs those contacts and automagically has a mail list for each of the groups defined in Google contacts. Ease of use and clarity for data handling, each contact has the info about which mail distribution list will apply directly as a property with itself. I like that.

OwnCloud, at least with the last few versions of it's 5er, does it more or less as well as Google does. The interface may not be that refined and handy, but the structures and functionality is there, which I appreciate a lot. 
Syncing to android requires 2 apps (cardDav-sync and calDAV-sync) costing few € each and then everything works nicely like it ever did. Fun.

Syncing to Thunderbird's addressbook needs an addon which, unfortunately, is crippled in the way it handles mail lists. Categories are synced and recognized, I can even edit them conveniently. But there is no automatic and no decent manual way to build a mail list based on the categories of the synced contacts. There is a modal window that expects me to type email addresse in order to add them to the list. Type. No filter select, or at least drag and drop. Type. 

This is the moment that I start to check Kontact again. Not the first time, KDE on arch is my main desktop for a year and it was KDE on debian before (less fun). 
Connecting Kontact to ownCloud is very easy, actually comfortable. Syncing the contacts works smooth and fast, including the contact photos. KAddressbook shows me a flat list of names but there is a context menue which allows me to add fields for display and sorting. My pet property, Categories, is not included though.

Double click on a contact entry opens a editor dialog with a field for the categories, comfortable to select from a list of all existing values, if I decide to create a new one it is synced to ownCloud minutes later. Very nice indeed.

But try to create a group and populate it and there is a time tunnel back into the computational stone ages! There is a New Group dialog which is modal and no drag & drop is possible. Select a number of contacts, New Group -> the very same dialog, no 'selection awareness' and adding the selected entries to the new group. No!
The dialog expects me to type the name, at least offering an input-aware selection as I start to type. Seriously no fun!

So:
- is there any known way to automatically sync groups according to category settings?
- or at least, any known way to populate groups via drag&drop of selected entries?
- or, at the very least, any docu, examples, helpful sites on how to get and set the relevant data, methods etc to script my own way with qdbus-qt4 ?
I can 
qdbus-qt4 org.kde.kaddressbook /kaddressbook/MainWindow_1 org.kde.KMainWindow.activateAction akonadi_contact_group_create 
but i just opens the modal editor window and thus gets me nowhere.

KRDC kann kein vnc

Sunday, August 18. 2013

 Ich hatte den Remote Desktop Client krdc mit pacman -S kdenetwork-krdc allein installiert, aber es ging und ging nicht. Den gewohnten Aufruf aus der konsole lehnte er mit Verweis auf nicht unterstützte URL ab und bei manuelle Auswahl bot er nur RDP aber kein VNC an. Google wusste gar keinen Rat. Die Antwort erriet ich aus der Beschreibung im KDE-Userbase Wiki: Krdc is one of a pair of KDE programs (Krfb is the other) 

Krdc funktioniert nur, wenn kdenetwork-krfb auch installiert ist.

Passwörter von Google Chrome migrieren

Friday, August 16. 2013

 bei einer Neuinstallation von Arch hat Google Chrome alle Passwörter vergessen, ob wohl Chrome die unter Linux/KDE doch in der Wallet ablegt, und die hatte ich mitgenommen.

Ich weiss, man braucht sich einfach nur mit dem alten Googleaccount anmelden und die gespeicherten Einstellungen herunterladen. Aber damit kann Google die eine mit der anderen Browserinstanz verknüpfen. Und das will ich nicht.

Also kdewallet aufgemacht und die Inhalte als XML exportieren. Stellt sich 'raus, dass Chrome in der wallet eine ganze reihe von Ordnern unterhält, mit individualisierten Namen wie etwa 

<folder name="Chrome Form Data (1234567)"> 

Einer davon, mit fast keinen Einträgen, ist klar der neue, jetzt aktuelle. Ich bastele aus einem der vollen Folder und dem Namen des aktuellen das XML für ein Update und Importiere diese XML wieder in kdewallet. Nimmt's, speichert's und schon kennt Chrome nach dem Neustart wieder das Passwort, damit  ich hier davon berichten kann.

Diese Kennungen stehen übrigens als
~/.config/google-chrome/Default/Preferences:      "local_profile_id" 
auf der Platte, chrome und chromium 

KDE 4.10

Saturday, February 16. 2013

 Wenige Tage nach dem release bot mir pacman die Installation von KDE SC 4.10 an und ohne viel Zögern habe ich es installiert. 
Als kleine Remineszens an alte KDE-Zeiten war danach meine Desktop-Möblierung verschwunden, also die Hintergründe und widgets auf den acht virtuellen desktops. Leise fluchend habe ich sie mir wieder restauriert. Es brauchte dann noch 2 reboots, bis alles wieder lief.

Nepomuk scheint seine Arbeit viel besser und unauffälliger zu erledigen, aber die semantischen Features sind trotzdem zuweilen einfach verschwunden. Die Oberfläche ist chick, teils zu chick, so have ich probleme mit den transparenten popups des Panels unten, die auf überfüllten Desktops skaum noch zu lesen sind.

Und der Pager funktioniert nicht mehr richtig. it meinen vielen virtuellen desktops benutze ich den sehr oft und zwar zum umschalten als auch zur Orientierung. Für jeden virtuellen Desktop gibt es ja eine kleine Preview, wo die Fenster als dunkler Kasten gezeichnet werden, ausserdem gibt es beim Hoover mit der Maus eine popup mit einer Liste der offenen Fenster.

Und das Ding ist wählerisch geworden. Zuerst dachte ich sogar, es würden nun gar keine previews mehr dargestellt, vor vollen desktops und der pager zeigt nicht ein Fenster an. Aber dann entdeckte ich, dass für einige Programme sehr wohl wie gewohnt Fensterumrisse gezeichnet wurden, einige Programme werden nur beim start berücksichtigt, solange sie einen SplashScreen zeigen. Und der grosse Rest wird ignoriert.

Hier mal eine kleine Liste von Programmen in den drei erkannten Klassen:

Solche Fenster werden im Preview berücksichtigt:

  • pager settings
  • ksnapshot
  • AcquireImages
  • Panorama Creator
  • Avahi SSH Server Browser
  • KDE Wallet configuration
  • KsCD
  • Nepomuk Server configuration
  • password dialog of Kdesu
  • Kompare
  • KTimer

Diese Programme schaffen es nur mit dem anfänglichen SplashScreen:

  • Google Earth
  • RetroShare
  • Kdenlive
  • Kwave
  • XMind

und unter den vielen anderen, die ganz ignoriert werden, sind auch:

  • dolphin
  • KInfo
  • Konqueror
  • FireFox, Chrome, Opera
  • LibreOffice
  • Kate
  • KWrite
  • SystemSettings
  • konsole

Leider habe ich vergeblich nach einem anderen report solcher Probleme gesucht und auch zu wenig Ahnung von den Möglichkeiten, Fenster unter KDE zuöffnen, um an der Liste der unterschiedlich behandelten Programme und fensterarten die Ursache ablesen zu können.

Ich habe dazu einen Bug eingetragen und wer was weiss: Tips willkommen!

https://bugs.kde.org/show_bug.cgi?id=315273

 

 update 20.3.2013:

5 Wochen Stille und auf einmal Bewegung im Bugreport, zwei Confirmer, ein workaround:

kwin --replace &
aus der console nach dem Start von KDE korrigiert das Problem jedenfalls für die laufende Session. 
Nicht wirklich elegant - aber damit sollten die Devs im Prinzip genügend Info haben, den Käfer zu klatschen.

update 6.4.2013:
auf arch hält KDE SC 4.10.2 Einzug und der Pager zeigt jetzt gleich nach dem Start (und ohne konsolentricks) previews für alle Fenster aller vDesktops. Wenn man genau hinsieht, stimmen allerdings die Grössen nicht...

Notizen zu Arch Linux

Friday, October 5. 2012

 Das wird wohl nicht nur mir so gegangen sein: die ersten pointer auf Arch Linux liefert Google, immer wieder finden sich in den Ergebnissen zu Suchen auf >Programm und Problem< recht weit oben brauchbare Texte aus wiki.archlinux.org. Früher oder später, bei mir eher später, realisiert man, dass das eine Linux-Distribution ist, die womöglich etwas Interessantes hat. Rolling Release.

Eine Test-Installation in einer vm gefällt mir (nachdem ich das karge Ödland der Installation tapfer durchquert habe, eine Mutprobe und Fegefeuer, um sicher zu stellen, dass nur Kommandozeilen-feste Leut' mit Zweitrechner (um die nächsten Installationsschritte im Wiki nachzulesen) dazustossen. So installiere ich Arch bald schon auf einer freien Partition, eigentlich nur zum Test aber bald schon wird es zum default.

Unter debian bin ich das Gefühl nie los geworden, dass der KDE nur missmutig mitgeschleppt wird, und was KDE-PIM angeht kommen meine Beschreibungen um das Attribut mutwillig kaum herum. Bei AUR ist das nicht so und meine ganzen "Lieblingsbaustellen" funktionieren plötzlich.

Ausserdem mag ich es einfach, ringsum die aktuellen Versionen zu haben und nicht auf das übernächste release hoffen zu müssen...

Es gibt auch Nachteile, oder zumindest Mühseligeres. Debian hat einfach ein riesiges Meer an Paketen und wenn mal doch etwas von dritter Seite dazukommen muss, kann man ziemlich darauf setzen, dass ein .deb im Angebot ist. Arch-Pakete hat natürlich keiner und so hat es länger als einen Monat gedauert, bis ich meinen Brother Laser endlich installiert bekommen habe.

Und die Paketwelt ist bei Arch zweigeteilt, es gibt die offiziellen packages, die man mit pacman -S installiert und mit pacman -Syu aktuell hält. Und dann gibt es die Arch User Repositories, AUR, mit einer Sammlung von build files, mittels derer man sich die entsprechenden Programme selbst als source lädt, kompiliert und dann letztlich installiert. Der vorletzte Link hat eine ausführliche Anleitung, die Kurzfassung ist:

  • die AUR-Seite finden, Kommentare lesen, ggf auch mal nach Alternativen schaun
  • benannte Abhängigkeiten erfüllen
  • tarball mit buildfiles an gesonderten Platz herunterladen (zB: /usr/local/src/AUR mit Schreibrechten für den user, dort wget paketurl)
  • tarball auspacken, hineinwechseln und dort als user makepkg -s
  • dann, wenn der build geklappt hat, als root mit pacman -U paketName.tar.xz installieren

Das sind dann foreign packages und pacman listet alle solchen mit pacman -Qm

 Etwas Vereinheitlichung zwischen den beiden Paketsorten und deren Handling schafft yaourt,  "Yet AnOther User Repository Tool". yaourt ist eine Erweiterung für pacman, welche die Benutzung des AURs direkt aus dem Paketmanager heraus erlaubt. Ich habe die im Wiki beschriebene Installation aus dem französischen Repository gewählt, also /etc/pacman ergänzen um:

[archlinuxfr]
Server = http://repo.archlinux.fr/$arch
und dann 
pacman -Syu yaourt
 

 

(Page 1 of 5, totaling 21 entries) » next page