All new Okteta features for KDE 4.3 in one picture

No great things happened to Okteta for the upcoming version 0.3, to be part of KDE 4.3, especially to the core system:

• Files are still completely loaded to memory, so better avoid really large files.
• No real-time collaborative editing.
• No multiple view to the same document.
• No working threads bound to the effected documents.
• No syntax highlighting.
• No sets of view settings, and no storing of the used one.
• No raw file system/process memory views.
• No embedded Goto/Find dialogs.

See me disappointed. And it looks like there will be almost no time to work on any of these features for 0.4

Still the new version number is justified, as some simple tools have been added:

• a file system browser, as known from Kate/KDevelop
• an opened documents browser
• a bookmark editor
• a checksum/hashsum calculator

While the first three are just alternative interfaces to existing functionality as offered in the menu, the checksum calculator is at least a new feature: It enables to create checksums of the types Modular sum (8-32 bit), Adler-32, and CRC-32. And hashsum algorithms are taken from the QCA2 library, if available, and can be SHA-0/1/224/256/384/512, MD2/4/5, RIPEMD-160, and Whirlpool.

Bookmarks now are also titled. But they still have one big drawback: They are not saved (also in session management), so you loose them if you close the file, please keep this in mind!

The status bar features active status labels: You can directly change Overwrite/Insert and Read-only/Read-write modes, also the encodings of the values and chars. And even directly adjust the size of the display with a zoom slider.The elements shown in the status bar are limited by the available size, which means the minimum size of the full windows will not be bound to the size of all status bar elements, so you can make it as small as you like.

Looking at the screenshot one may wonder if Okteta couldn’t simply be built on top of Sublime, the KDevelop platform, or reuse Kate’s UI framework or even the KOffice one. I had investigated this before, but found Sublime and Kate too much bound to plaintext-style documents, and similar with KOffice. And I felt not to have the time for all the discussion needed to influence the development for my needs and ideas
Which is why I have been working on an own infrastructure (Working title Kakao, new name still pending), centered around generic document types to be synched asynchronously between multiple address spaces and modified by different users, which I even intend to become some KPart 2.0 in the end (don’t hold your breath, may be just another failed ambition in the end). The code written is still far from what I have in mind, and also includes some hacks/shortcuts to have it working for Okteta now, so please ignore it for the time given.

KDELirc is back in kdeutils

Get out your infrared remote control, wipe the dust from it and grap for some fresh batteries! (Hm, are there solardriven infrared remotecontrols?) With KDE 4.3 you will be able to command the programs on your computer from your armchair again. KDELirc (homepage, code) has returned to KDE, is back in the kdeutils module.

It was almost six years ago, the 27th of May 2003, when Gav Wood moved KDELirc into the KDE repository:

“Initial import of kdelirc, an advanced KDE LIRC system;
Code mostly works on my system and is being uploaded here in order to ease collaboration and testing.”

Following it made its first public release on the 3rd of February 2004, as part of KDE 3.2, sharing a debut with such programs as Kontact, Kopete, KGpg, and KWallet (which may be the reason why it is missing in the changelog then, oh well).

It was not until the great porting to KDE4 that KDELirc then had to be dropped from the main branch of the kdeutils module, as the old maintainers had lost time (or their remote controls?), so noone finished the little but important details in the port to the KDE4 platform (The KDE3 version of course is still available).

Then Michael Zanetti and Frank Scheffold, who obviously still own some remote controls and armchairs, but also like to run KDE4, took over and have been giving the code their love and care, that finally KDELirc is able to enjoy the KDE4 platform, too. So there it is, back at home. Now that the initial port is completed, Michael and Frank have quite some ideas how to evolve KDELirc from here.

So, armchair riders, be prepared to get more. By getting out of your armchair and helping And if is only by finding out the data for your remote control, so it can be added to LIRC or KDELirc. Check out the KDE 4.3 Beta1, soon coming to a mirror near you, and open the System Settings, look for “Remote Control” and see yourself. Even better would be to make sure LIRC also works on *BSD and OpenSolaris. If you are ambitious, you could try to write a backend for ReactOS. Perhaps even Windows or OS X, if you really need to.

Getting tooltipped how cute Qt is…

I have seen others praising Qt. Thought they are just a little bit too euphoric. But then I never really had to code against the Win32 API or to use AWT, so perhaps I miss some experience in hell to recognize heaven.

And looking at Qt4 I especially miss to see brilliance if looking at the printing framework or the QDockWidget system, those are not really pleasing me and my needs. And connections of signals and slots not being checked at compile-time has always annoyed me.

But now and then I find solutions that are really making me happy:
Yesterday I wanted to add tooltip support to bookmarks in Okteta, so if hovering over a bookmark mark in the view the name of the bookmark (now editable) would be shown in a tooltip. After I had thought a while about how to achieve this, involving QTimer and mouse events, I was not too satisfied with my ideas and hoped this could be done easier. So I used a well known index service and was pointed to this coding example by the Trolls themselves, which showed me how to do this with just a few lines in a very straightforward way. I liked this. Thank you who made this possible

It basically boiled down to (real code needs refactoring):

bool AbstractByteArrayViewPrivate::event( QEvent* event )
{
    Q_Q( AbstractByteArrayView );

    if( event->type() == QEvent::ToolTip )
    {
        QHelpEvent* helpEvent = static_cast( event );

        KHECore::Bookmark* bookmark = 0;

        KHECore::Bookmarkable* bookmarks = qobject_cast( mByteArrayModel );
        if( bookmarks )
        {
            const int index = indexByPoint( helpEvent->pos() );
            if( index != -1 )
                bookmark = bookmarks->bookmarkFor( index );
        }

        if( bookmark) )
            QToolTip::showText( helpEvent->globalPos(), bookmark->name() );
        else
        {
            QToolTip::hideText();
            event->ignore();
        }

        return true;
     }

    return q->ColumnsView::event( event );
}

So with KDE 4.3 you will have tooltips if hovering over bookmarks marks in Okteta. Have a good look at them, because you will loose all of them if closing the file they are set for, because storing the bookmarks will not be done in time for the hard feature freeze and has to wait for at least KDE 4.4, yes, a pity.

Network:/ kioslave entered kdereview

While today those lucky enough to be chosen for participating in GSoC can start their activities, we all wish them much fun and pleasing results, others can mark an end to a period of development: Not just kdelirc did enter kdereview and now awaits your critics, also did a so-called network:/ kioslave I have been working on in the last month.

Read on for some background about this kioslave. This text had been written for the Commit-Digest but did not make it in time for the latest one:

Concept

The network:/ kioslave offers the listing of the network from a general point of view. It should map the physical world as much as possible, with all the devices and services. The main purpose is discoverability of what there is around the computer and object-oriented access to it.

It is a little bit in the tradition of the lan:/ kioslave, which is driven by LISa, but unmaintained for KDE 4. While LISa in it’s time basically had to use pinging, the network:/ kioslave now can use backends for the modern service discovery systems like zeroconf.

Design

The network kioslave currently consists of four parts:

• a library named network, which models the devices and services, driven by backends for the various service discovery systems
• a mimetype definition file, which adds types for the various devices and services
• the kioslave itself
• a kded module to emit proper KDirNotify signals if the network structure changes, so all views using the network:/ kioslave get updated

Both the kioslave and the kded module link to the network library. Due to synchronisation problems the kioslave currently pulls the needed data from the kded module using D-Bus, instead of directly using the network structure in the linked-in network library.

Status

The kioslave is already quite usable for networks with devices using zeroconf, like there is with KDE programs using KDNSSD/Avahi or all Apple computers. Even reacting to (dis-)appearing of services and devices seems to work flawlessly now.

All service types are currently simply forwarding to the corresponding url, if there is one. So for services which have direct support in KDE for the used protocol, like webdav, http, ftp, svn, ssh or vnc, you can click on the service item and then either find yourself listing the files, browsing html pages, login to the shell, or whatever this service and the (KDE) clients enable you to.

For some servicetypes you first have to assign yourself a handler, if the mimetype for the service could not be derived from a matching one, like inode/directory. For this goto System Settings>File Associations and see for “inode/vnd.kde.service.*“. E.g. for “inode/vnd.kde.service.rfb” add “krdc -caption "%c" %u” (%u is important) as application handler. So clicking on a rfb service will start KRdc for that service.

A little bit annoying can be that there is not yet a configuration to filter the presented services, e.g to hide all system-level and unknown service types.

And, might be a stopper for some, Dolphin and the Plasma Folderview widget do not cooperate too well, they often show some error messages if launching remote urls. So just use it in Konqueror for now Well, other non-file kioslaves are affected as well, so one should see after that.

Future

Wide, wide open.

More backends are needed, for UPnP, SMB stuff and others. There is already a rudimentary backend for SLP, but this crashes due to threading problems (the kioslave ran the network library in a separate thread, until the current synchronisation fix with the D-Bus pulling was switched to), so the zeroconf one is the only working backend currently.

Supporting the display of the status of the service needs support, e.g. updating on the presence change in a Bonjour Chat service. And getting some Meta information for services to display, here the name and such.

Then I am looking for a service which can help to identify device types properly (printer, router, computer, laptop, phone, or handheld, perhaps even manufacturer/model). Currently the type is guessed by the services running,
which is not really perfect. Also it would be nice to have individual icons for the devices to display, similar like favicons are used for web services.

Next, things like virtual machines or PDF “printers” bear some challenges how to present them best. In general there needs to be a definition for what system is a device and what is a service. In that process the mimetypes for the services and devices also need some rethinking.

Also the network library needs to be checked if it could not end as a generic library to end in Solid or another place. And could substitute KDNSSD with a generic interface to publish objects/systems to the net or query/get proxy objects for systems on the net, including WebServices ( see also similar ideas from Jakub).

Furthermore, all programs which can connect to a remote source need to expose this capability also on the commandline, so they can be started explicitely for a given service. E.g. some KDE games are network enabled, but do not yet support to connect to a remote game by having the url passed as a commandline argument. I did a quick example patch for KBattleship, but it seems I need more motivating material for the KDE games developer At least this particular patch is now committed (during the Chemnitzer Linux-Tage I demoed the network:/ kioslave to Patrick and Eckhart at the KDE booth, which resulted in a KBattleship tournament, won by Eckhart with easiness.)

And in the end I would like to have some more spatial oriented views for hierarchical items, based on concepts found in the environment view of Sugar and the Semantic Desktop DeepaMehta, best automatically structured by using the geo information of the devices.

Seems it will be ready next week.

Infrared control coming back to KDE4

One entry in the list of planned features for the module kdeutils reads

Bring back kdelirc

So this is going to become another example of the “just-put-to-hold-not-vanished” nature with FLOSS:
kdelirc, a tool to operate your programs by an infrared controller, had been lost in the KDE3 to KDE4 conversion. But Michael Zanetti heard the call for maintainership and jumped onto the code to make it ready for KDE4, for now in the playground section of the repository.

And a few days ago he wrote to the kde-utils-devel mailinglist:

I think we (Frank and I) can bring back kdelirc for 4.3.

He then described the current state:

- It is fully ported to Qt4/KDE4. No Qt3Support.
- We have heavily refactored/rewritten major parts because the original code was in a really bad state in terms of readability and maintainability.
- It is basically the same program as before. There are some new extensions and remote controls.

It is not 100% finished yet, but we’re on a good way. All the functionality is restored. We still have to do the following tasks:
- Finishing rework of kcmlirc.cpp
- Fixing some bugs introduced during rewrite.
- creating svg icons
- some general cleanup (krazy checks etc)

About the documentation: We still have the original one. It is not perfect but at least not worse than at KDE3 times. Perhaps someone has the time to help out here…?

To get it into KDE 4.3, kdelirc needs to be complete enough to enter the review section until April 20th. So if you are looking to do your presentations or tune your music with a remote control already with KDE 4.3 again, now jump in to fix the remaining issues as listed, e.g. the one of krazy. Get in contact on the kde-utils-devel mailinglist.

Start with just giving it a try. For your convenience:
svn co svn://anonsvn.kde.org/home/kde/trunk/playground/utils/kdelirc
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$YOURINSTALLPATH$ ../kdelirc
make
make install


Interested in maintaining KCalc?

One of the powers of FLOSS is that if an author/maintainer has no more time or no more interest in some program that program does not vanish with the author’s/maintainer’s change of focus. It’s development/maintenance is just put on hold. Until someone else takes the sources and gets things back into rolling.

And now let’s see how short the time of “put on hold” has to get for KCalc. David Johnson, who has been giving his care for it since more than a year, making it one of the good KDE4 programs, now had to write to the kde-utils-devel mailinglist:

Real life has been intruding into my KDE time. While I still plan to help out KDE, I doubt I will be able to adequately support kcalc. So I’m putting out a call for a maintainer.

This isn’t urgent, but if you or someone you know may be interested, please contact me.

Contact is done with an email to david at usermode org. I hope we soon can welcome someone new to the little team of developers in the module kdeutils, do not forget to join our mailing list and say “Hi!”.

If you like some inspiration: One interesting challenge might be to factor out the calculation engine and share it with the calculator plasmoid. And an option for a prompt history display would be great to have, too.

Currently it is even possible for you to do new features for 4.3 with the Soft Feature Freeze yet coming at Thursday, April 16th. So think about, if KCalc could become your program for some time

How do you do remote presentations?

Dear lazyweb,

have you ever done a presentation or given a talk to a remote audience, via the internet? Or setup an infrastructure to make this possible?
Which software did you use, which setup, which protocols?

What I am looking for is

• something like a one-to-one video chat with an extra channel for a (shared) screen,
• just that the “one” on the other end is a full room with people, caught by a camera and some microphones feeding a single source.
• The (shared) screen would be given by the single person end, for the interactive slides and demos.
• Bonus points for being able to show little movies over the connection.
• The multiple person end would be able to overlay the video of the single person to the display shared screen locally, either by a second projector (second head/screen to the computer) or as a little window on the first screen.

This should be really possible with today’s FLOSS software and the common hardware. But how?

Thanks for your hints.

PS: Reminds me of what somebody told me a few days ago. Yamaha builds pianos with which one can give remote performances over the internet, due to the mechanics being controlled by commands recorded from the sensors on the other’s piano mechanics, see e.g. this video. And, FWIW, it’s built on Linux

Feedback for the network kioslave, please

Two things that cheered me up today:

1. A really interesting interview with two developers of Étoilé. I think they are so right with their approach. The application-centric approach sucks a lot and is one of the biggest culprits of the sad state of the personal computer interface still after four decades since the so-called mother of all demos, from 1968 (sic!). Since I first heard from that project three (already?) years ago I have been checking their homepage for news every week Definitely a project to watch and learn from. If you look closely at the Okteta sources, the Kakao part, you might even see where I try to lay the base for something remotely similar to CoreObject. And a project to join? Hm, if I would start with FLOSS I would definitely try to work in that project. But I am now engaged with KDE, which also is going some good directions

2. A really big Multiseat deployment in Brazil, with up to ten(!) workplaces per mainboard. No idea, if they are using KDE. But I feel so inspired by the technical approach, and still feel sorry I once failed to setup a multiseat myself (due to X drivers of the graphic cards surprised to not be the only graphics card on the same PCI bus and by this confused, or something, memories are fading), so I could never show it at the local Linux-Info-Tag Dresden (BTW: Will you be at the Chemnitzer Linuxtage, 14.-15. March? KDE will be there, thanks to Palapeli-Stefan and others).

If they are using KDE, I am wondering what the output of the network kioslave would be and how it could be improved.

Now, you can cheer me up, too:
Just give some ideas how you would want network kioslave to work like. Go and try it, should also compile with KDE 4.2:

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/network/networkkio
mkdir build
cd build
cmake ../networkkio
make
make install

This will install a kded-module for kio-updates on changes of the network, a solidnetwork library, the network-kioslave and some mimetypes for known services.
Some of the services are for now simply subtypes of the types directory or symlink, so clicking on it should forward to the url that is attached to them. You can also redefine the handling with the usual file association dialog.

Even better, join the coding, I welcome everyone to write the backends for UPnP, WebServices, Lisa-like scanning and what else there is that could be shown in the network.
I also would like better code for the device type detection. Are there any services which would help to see if a host is a big server, a laptop, a netbook, a router? Perhaps even the model, like Producer Cooldevice 2010? Currently I plan to go for heuristics by found services, but I wonder how it is done in Windows or OS X if listing other devices in the network.
Then a config would be nice, to limit the number of service shown (and hide the unknown optionally). Also to define which other domains than the local network should be scanned.

Browse your network

Have you developed a network service, used DNSSD:: PublicService to publish it with the zeroconf system, and then wondered why it didn’t show up in Konqueror with zeroconf:/ from the kdenetwork module?

I did. And found out that the zeroconf kioslave restricts itself to filesystem services and redirects to the listing of the services for convenient browsing of such filesystems. It also orders the listing by the service types in the first level, not the hosts. Which is nice for that, but not what I was looking for. I wanted to see all devices and the services in the domains I care for, like lan:/ might have done (if it ever had worked for me), I only know it from screenshots, like this one

So hands on, write your own, brave man. Followed that, so find the prototype code in playground as network-kioslave. It also includes a library which might develop into something general to be added to Solid. But let’s wait for that. There is a lot of stuff that needs to be done, integrating the different service lookup systems, finding a general model for all them, and much more. I have first-hand rumors that others are starting on support for UPnP, so I am looking forward for some cooperation where possible. If you are experienced with samba, please contact me, too.

See a lovely screenshot in the style of the season (isn’t it always this season?) for what already works. As backend KDNSSD is used, and then quite some guesswork happens to generate a device and service structure from the info available. But it’s a start:

Nothing much to see, the local network is pretty empty currently, just a lonely router and my computer… And the one on it offering KBattleShip is myself, so nothing to distract me

Clicking on the services shows where I am currently stuck. A service item represents a service running on a host at some port (or even ports?). But what to do on this service? E.g. the ssh service could be used to open a ssh-session in Konsole. Or be used for browsing with the “fish:/” kioslave. A database service could be either queried or configured. So just doing a redirect to another protocol is not what I want here. Instead there should be some new mimetypes one could register clients/handlers for. So in the context menu you could choose another option than the default one. Would also be nice for metadata display. I already install some new mimetypes for network services/devices, but the naming pattern might need some discussion. And xdg spec support. Much to be done…

Bonjour, what services are in this location?

I just committed a KDE 4 port of the SLP kioslave into playground. The KDE 3 version might be at least known to the OpenSuse users, as Novell is a strong supporter of the Service Location Protocol (SLP, srvloc), and so it had been developed in some Suse repository and always been installed with the OpenSuses.

So far it’s a 1:1 port, perhaps with new bugs introduced by the port:

Why did I do this port? I am looking to see of there could be a better presentation of the units and services in a network, e.g. in Konqueror, Dolphin and the filedialog. I was at least impressed by the environment view of Sugar.

Before I ported the SLP kioslave I had made myself a little familiar with the zeroconf kioslave residing in the module kdenetwork, for the Zero Configuration Networking (Zeroconfig). Perhaps I can take up, where Jakub has stopped previously, and move all service discovery services (recursiveness ahead) behind an abstraction/wrapping layer, best support for multiple backends at the same time.

In the end I hope to reach a system in which programs that support realtime collaboration on the same data do not need to provide a second selector view to choose the document to connect to, but can just reuse the filedialog. Or get started from the “file” manager by a click on the relevant service item.
There are lots of possibilities in this area. E.g. you could checkout a module from a repository to a place on your disk with one drag. Just let your imagination roll what is possible…

Our friends in the GNOME camp are already some more happy camper with regard to realtime collaboration. See for GTK+ getting support for MPX, the same for Vino for a multi-pointer remote desktop, the GTK+-using AbiWord getting support for the Telepathy tubes, or just the working Gobby.

At least concerning Gobby there is hope for KDE, see some recent update on the state of Kobby. And then there is the Teamwork plugin for KDevelop, but I haven’t yet managed to get it running. My plans for Okteta in this regard are stalled a little by the work on the service discovery, but it’s them which are driving me there