Konsole’s user interface changes

Konsole is the app that probably almost every KDE developer uses on a daily basis, but there hasn’t been much development on the user interface front during the last releases. The two brave souls Robert Knight and Kurt Hindenburg are busy triaging and fixing bugs. So to say Konsole is more maintained than developed due to a simple lack of manpower. Nonetheless some recent changes may be worth blogging about.

Konsole does a brilliant job at being a terminal emulator but it doesn’t follow user interface standards set by the majority of KDE apps very well. The remainder of this post is mostly about the menu bar and popup menus. Generally, Konsole is forced to apply to the scheme CTRL+SHIFT+Shortcut where other apps would use only CTRL+Shortcut because apps in the terminal might want to use those. Up until now Konsole had it’s very own idea about shortcuts and accelerators. For example, if you wanted to open another tab, you had to do CTRL+SHIFT+N where it should actually be CTRL+SHIFT+T. There are other examples but all those should be fixed by now. Furthermore the menus gained some rearrangements. If you’re a heavy user of Konsole profiles, you may appreciate that they don’t pollute the file menu any more:

As a small bonus, your default profile now shows the ‘favorite’ emblem :-) As you can see, the view menu was streamlined, the actions ‘Show Menubar’ and ‘Full Screen Mode’ where moved where they belong to: into the settings menu.

You may notice that the ‘Scrollback’ menu went into nirvana. This was simply needed because it grouped the ‘find’ actions (better put into the edit menu), ‘Save Output’ (went to the file menu) and some options stuff that should rather be found in the settings menu. Also, a popup menu for Konsole’ custom tab bar was added recently by Kurt: However, this may probably be merged soon with the popup menu that you get when you right click inside the terminal session:

All these are mostly small changes on the road to a refreshed Konsole experience, so for now we’d like to get some feedback on how you like these and what parts of Konsole may be improved further UI-wise. Here’s a partial TODO list to make it an even better KDE citizen:

  • Replace all those custom config dialogs with KConfigXT based ones
  • Change Konsole’s custom tabs implementation to KTabBar
  • Code cleanup, maybe even stick to a single code style :-)
  • Bugs…

GSoC updates: the client agent

This follow-up post is about my proceedings for my GSoC project to integrate SyncML support in Akonadi. This consists basically of two parts, a server agent and a client agent. The former allows other devices to talk to your Akonadi server while the latter let’s your Akonadi server speak with others. Quite simple? Not really, SyncML is a complex and error-prone beast. That said, the server component might take some time to be ready, but the client agent is actually useful now. So let’s have a little test session!

The following stuff is pretty low-level, requires some compiler/shell knowledge, a KDE development environment set up and is not intended for end-users. Still there?

Compilation
If you have your KDE development environment up and running, just checkout trunk/playground/pim/syncml from KDE SVN. You need to have libfunambol installed, which you can either compile for yourself from source our use a package from that repository (a patched libsyncml is available too, if you want to build the server agent). Not much to say here, just build and install it.

Setup
If you’ve reached this step you now should be able to add a SyncML client agent in the Akonadi resource configuration control module (system settings -> advanced tab -> akonadi configuration):

syncmlclient-agent-3

If you did so, you should now be presented with the following configuration dialog:

syncmlclient-agent-4

There you can setup the remote server (speak web-service) you want to sync with. Your job is basically to decide what parts of your PIM-data you want to be synced (contacts, calendar, etc.) and how to match the corresponding local Akonadi resource with the remote database on the server. Some more advanced values will be exposed soon, SyncML has gazillions of options available! Here are some possible values to toy with:

myFunambol.com

URL: http://my.funambol.com/sync
username/password: you should register!
contacts remote db: card
events remote db: event
tasks remote db: task
notes remote db: note

ScheduleWorld.com

URL: http://sync.scheduleworld.com/funambol/ds
username/password: you should register!
contacts remote db: card
events remote db: cal
tasks remote db: task
notes remote db: note

Mobical.net

URL: http://www.mobical.net/sync/server
username/password: you should register!
contacts remote db: con
events remote db: cal
tasks remote db: task
notes remote db: vnote

Rumors have it that some Google services are also SyncML-capable but I don’t know the settings needed. Feel free to post a comment if you know something here. As a sidenote, you can actually have multiple agents for several remote sides in parallel.

Showtime!
For now all that stuff lacks a GUI, there’s some initial work on a KControl module but for now we have to communicate via D-Bus with the client agent. The same is true for visual feedback. The agent is able to tell you whether the sync succeeded or not. If you want to know more, you have to watch Akonadi’s debug output for now. Fire up a terminal and enter the following stuff:

$ akonadictl restart
$ qdbus org.freedesktop.Akonadi.Agent.akonadi_syncmlclient_agent_0 / sync

Before you actually try this, be warned! This is unstable code that is still in heavy development and all kind of weird things may happen to your PIM data, so make a backup before you proceed.

syncmlclient-agent

GSoC status update for weeks 3-5

Ok, this one took a bit longer than expected. But better late than never..

In the last 3 weeks I’ve been concentrating on the SyncML server agent. Here is how it currently looks:

syncml server agent 1

As you can see, I streamlined it quite a bit but there’s still a lot of options available. This is necessary to cover all kinds of weird devices (and what they think what is standard SyncML behavior). Who ever told you that SyncML was simple is wrong :-)

syncml server agent 2

One can already interact with the server, it should respond to simple queries but does no actual syncing with your Akonadi resources yet. More specific this involves to map Akonadi’s concept of resources and collections to libsyncml’s datastore concept. There’s usually one libsyncml datastore per content type available (one for notes, events, task, etc.) but Akonadi can have more than one resource for such things (For example my Akonadi instance has 3 calendar resources right now). This part turned out to be quite tricky, but I’m getting there.

A nice side-effect is that libsyncml now has one more project outside of the OpenSync project. We’re in good contact, I even got SVN access to speed up patching ;-) The bigger news is probably that libsyncml now has a stable branch.

That’s it for now, I’ll try to provide more frequent updates …

GSoC week 1-2 wrap up

Ok, time to write a bit about my progress in the first two GSoC coding weeks. So far, the foundations are laid out, I finally decided which SyncML implementation to use and how to realize what I plan. En plus, some code already hit playground ;-)

First of all I decided to go for libsyncml as my backend. The two other competitors (Funambol C++ client SDK and libsynthesis) either don’t have all the required features (SyncML server mode, OBEX transport) or are difficult to handle from my POV. I did a rather lengthy review for myself and decided that this is the right way to go, even if libsyncml does have some issues here and there.

Before I’d like to go into further details, I’d like to revise what I’d like to achieve:

  • Being able to sync my mobile against Akonadi
  • Being able to let Akonadi sync against others
  • Configure all that in a comfortable way (don’t mess to much with SyncML)
  • Have it automated (where possible)

Being able to allow a mobile device to sync with my desktop’s Akonadi instance effectively means running a SyncML server to which the device can connect to and which interfaces with Akonadi itself.

Therefore we need a “Akonadi SyncML server agent”:

syncml_server_agent_1

And the corresponding configuration interface:

syncml_server_agent_2

There you can set how you want to expose SyncML functionality and what resources you want to be sync-able. Some advanced SyncML stuff is also there to help with all the beasty devices out there (more than you might think). As you can see, right know only one server instance is allowed to run at the same time, but this might change in the near future. For example you might want to have one OBEX / TCP server which exposes all your contact resources for your mobile and another one via HTTP which exposes each and every resource available for another Akonadi instance (I’ll come to that in a moment). Even more so, you might want to set some proper SSL encryption your HTTP setup but not necessarily for the mobile device (we’re all lazy aren’t we?).

Depending on what you are up to you might want to let your Akonadi instance behave like a client, e.g. let it go knocking on some web services (myFunambol.com, ScheduleWorld, Google stuff, etc.) or another Akonadi instance. And you don’t want to do that by yourself all the time. So we need a “Akonadi SyncML client agent” to do exactly that. Here’s the config screen draft:

syncml_client_agent_1

syncml_client_agent_2

This is where you can set how to access the remote server and again, what Akonadi resources you want to have synced. You also have to set some SyncML-specifica to access calendars and contacts on the remote partner. As you can see here, SyncML clients should be able do their job in different ways. You might want to have one client which syncs weekly with your google calender and you might want to have one client on your laptop which syncs with your desktop’s Akonadi instance upon network discovery (help, please!!).

And to be able to configure all that stuff without getting lost, we’ll need a KCM module. A profile concept remains to be elaborated to hide away all the complexity (more in a follow-up post).

Some code can already be found under playground/pim/syncml but you need a pretty recent version of libsyncml and libwbxml to get this to work. You can also fetch those dependencies with some patches applied from my SUSE-BuildService repository for several RPM-based distros:

http://download.opensuse.org/repositories/home:/saschpe/

Kigo testing wanted

Remember that go game (as in Weiqi, the traditional chinese board game) in development for KDE? After a 3 weeks break (holidays, new year and a paper to write), I’m now back at full speed getting this thingy shaped up.

kigo-051-screenshot

If you want to help testing, add that PPA repository for Ubuntu Jaunty (development version) to your /etc/apt/sources.list, update and install the kigo package and have fun!


deb http://ppa.launchpad.net/saschpe/ubuntu/ jaunty main

On retracting moves …

Wee, I can redo a move! Shiny new features entered the world of Kigo (formerly known as KGo) in the last two weeks. Let’s have a start with the full undo/redo implementation. This does not sound very noteworthy off course, but (at least the redo part) turned out to be more of an issue than I originally expected. The scapegoat is once again the wonderful GTP protocol, it features a nice undo command which makes undoing moves a breeze. Unfortunatly the original implementors forgot to add a redo command, in fact the GTP-compatible Go engines don’t know this concept. Ergo one has to track all the different moves (moves, passes, resigns, generated actions, …) externally and re-apply them if the user decides to jump through the command/action/move history. But Qt came to the rescue, the Qt undo framework is a breeze to use and saved the day here. Long story short, here is a little screenie showing the obvious:

kigo-11

Doesn’t that look a bit like dock widgets? Yeah, I decided to replace my first design of using different screens to show game state with a more modular approach. Screen-based meant something like having a SetupScreen responsible for setting a new/loaded game up and a GameScreen for handling board display/interaction/… (and ErrorScreen, you get it). Altough this worked quite well it raised some issues here and there. It first of all results into a static user interface which is non-customizable. Second thing is a lack of seperation of concerns in the codebase (in contrast to what was originally intended by using that screen concept). Namely which class/screen is the owner of the Go engine backend class and the running Go engine? Also some doubled code for house-keeping … Moving away from this approach to using QDockWidgets took around 3 hours (a nice example how Qt enables rapid application development). Actually I had to throw away only little portions of code because all visual stuff was created with Designer, so bits and pieces of those UI files just had to be copied into smaller distinct pieces. So the new approach is laid out like this:

  • Kigo::MainWindow class which is _the_ GUI class with it children
    • Kigo::GameView class (QGraphicsView subclass) as a widget to interact with the user
    • Kigo::GameScene class (QGraphicsScene) only depends on a GoEngine and is responsible for giving it a (themed) visual representation
    • Kigo::GoEngine class, the GTP abstraction and responsible for game interaction, etc.

All those little dock widgets are then shown or hidden based on game state and allow for great extensibility in the future (The game editor feature for example). Enough bla bla, here is another screenie:

kigo-2

Seems like I forgot to mention the most important fact, playing against a Go engine is possible now. Strange as it sounds but I finally got this right and enabled it in the GUI part. So you finally can play Go with a Go game, how awesome is this?

Having this sorted out there are still some things marked as TODO. Being able to let multiple go engines fight each other is still in the pipeline, I already had a solution here but I want to have it implemented in a clear way, so you won’t see this feature in current trunk. Multiplay via GGZ or the more traditional go servers will definitly happen after a first release. And yes, there will definitly be a release in time for KDE-4.2, probably in extragear.
Therefore I plan to get in touch with the kdegames guys a bit more to get things sorted out (sorry guys, internet connection in my current location remains mostly a wish, but I promise to do better).

Next thing to concentrate on is to get this backend configuration right, as well as fixing some usability glitches. And a better icon would be cool, the one I stole from KReversi (and which seem to be not used any more) is nice but a bit too green, I would be glad if someone could turn this into a more wooden (resembling a go board) appearance.

Expect these changes to be pushed into SVN in the following days…

KGo status updates

Having had no status update of KGo since quite some time, I’m going to fix that now. So what actually is KGo? As the name implies it is an implementation of the traditional Go (or Weiqi) game widely played in Japan an China. We are in luck that we already have a good free Go engine, GnuGo. And even better is the fact that there exists some sort of de-facto standard on how to communicate with Go engines, the GTP protocol. Having all the necessary building blocks at hand I decided to start getting something done and here it is:

kgo-screen-1

This screen shows the setup phase of an recorded masters game where you can setup to start at a certain move and wether you want to replay it versus a go engine or versus another human. Ahh… the version currently in SVN trunk has playing versus an engine disabled (but it is implemented and works) because im refactoring the responsable code at the moment. Loading from and saving to SGF files works nice and I have plans to add support for playing online either via GGZ or the more traditional Go servers but this definitely won’t happen too soon…

Here we have one of the configuration screens and what can be seen is that it is themable (like all the other kdegames) and that you can choose your preferred Go engine backend and get instand feedback if that engine is supported or not (that little green light):

kgo-screen-3

As you can see, the current theme is rather functional and I do have to admit that I used and modified some artwork from KReversi. This shot shows some recommended moves generated by the Go engine backend. In fact nearly all game calculations are done in the backend but this is not as clean as it may sound. The GTP protocol is in state of transition since … years .. and it is missing a lot of necessary things.

So i ended up writing a complete GTP protocol wrapper which implements all the needed tidbits like player management, nice status querying and game board manipulation.

kgo-screen-4

Altough one can use it to play Go at the moment there are still a lot of areas which need improvement. So if you want to help out feel free to grab it from SVN and start testing:

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/games/kigo kigo

Stay tuned …

Update: I just decided rename it to Kigo, took quite a bit of time but it was just commit back into SVN.