Milian Wolff

Ok, just a quick update on what we are doing / have done the last two days except drinking beer and eating quite a lot of food (though it never seems to be enough somehow….)

• Apol was polishing CMake support, speeding up KDevelop startup time when you enabled the QtHelp plugin, making sure that Kross plugins get loaded properly and some other things
• Adymo started some refactoring of Sublime in an experimental branch (actually they had quite a long discussion right now about things in the UI which should be changed/fixed). Besides that he also fixed some little bugs in the includepath resolver for CMake
• Nsams is fixing PHP support and adding new features here and there. Esp. completion inside a foreach over a Iterator class works now!
• and as always ZWabel did fix quite a lot of bugs, most of them which only were discoverable in a few corner cases, very nice indeed.
• shaforo who sadly already left us again to attend university fixed the sorting in the Project view among other things
• With Apols help I managed to get started with a documentation plugin which (currently) integrates PHP.net. I plan to make it possible to use the downloadable PHP.net documentation as well to speed things up. Actually setting up a documentation plugin is very easy! Maybe I’ll take a look at writing a documentation plugin for Zend, Symfony, etc. pp. as well - should be fairly easy. Maybe I can come up with a generic documentation plugin which makes it possible to include any kind of .html documentation with some configurable mapping… lets see! Or maybe I should take a look at writing Kross plugins (Apol could help me here as well) for that purpose.

Except these changes we also discussed how to support dynamically typed languages like PHP, Ruby, Python and JavaScript better. One result of it that we now plan to fully support the dedicated map types of each language, with autocompletion and such. Of course that won’t be possible for 100% of the use-cases, but we hope to support at least the most common ones (i.e. 90%). You can take a look at http://www.kdevelop.org/mediawiki/index.php/SupportForDynamicMaps for more information.

Additionally Nsams, Apol and Zwabel took a look at the GDB plugin and started working on it a bit. It’s still a work in progress though.

My biggest change is that color highlighting support for dark color schemes now is in trunk. It automatically adapts to changes in the global KDE color scheme, yet you still have to manually change the Kate color scheme. Actually I intend to add an interface to Kate so we can use it’s color schemes instead of the global KDE one - makes much more sense and would fix some bugs (i.e. fix from dark color scheme to a light one). Here’s a screenshot of it (with the PHP.net documentation showing):

dark color scheme and syntax highlighting in KDevelop 4

If you followed the planet kde you might have seen some blog posts about color reception and color generation by Ariya Hidayat. I will take a look at it and implement it in KDevelop. Or I simply pick a given set of colors and use them - for 10 colors or so we need it doesn’t make that much sense to let them be generated. Yet the article he linked to about adaptive coloring for syntax highlighting will be helpful I think! Thanks!

Yet it currently works quite well I’ll first try to fix the colors in the Declaration tooltip, quickopen and codecompletion lists.

So stay tuned for more KDevelop goodness throughout the next days.

Hello Planet KDE!

I want to give you a little insight on the current state of PHP support in KDevelop4:

Me and Nikolaus Sams (nsams) are working diligently on a plugin for PHP support in playground. It’s somewhat stable, i.e. we fix any crashes we stumble upon, but I would call it Alpha state at most. It may eat your babies so to speak. Yet I’m happy to say that at least one user is already using it for production (hi leinir ;-) ).

implemented PHP support

Well, here’s a (not complete) list of features that are already working. Though I have to warn you: no screenshots included ;-) It’s actually all very similar to the C++ screenies you can see on the web.

sematic highlighting

Let’s start with a feature that only very recently was added for PHP - semantic highlighting. Niko moved some language independent parts of the C++ plugin from KDevelop to KDevplatform and now PHP has the same code highlighting features as C++.

I personally love this feature since it makes it even easier to grasp code and it makes the code highlighting more consistent since there is no visual difference between PHP built-in functions/constants and your own.

code completion

Arguably one of the most useful features the DUChain enables us to write is code completion. There’s already full support for:

• PHP built-in functions, classes, constants, superglobals
• user-defined functions, classes, constants, superglobals, variables, etc.
• proper code completion for objects which respects access modifiers (private, public, protected) and differentiates between static/non-static members and methods
• code completion for overridable and implementable functions inside classes
• hints in the argument list of function- and method class
• sane code completion after keywords such as “extends, implements, catch(), new, throw” and some more I think

There’s still some bugs to fix and a few features to implement. But I can easily say that even the current state of code completion makes one wonder how he could use Quanta (from KDE3 times) for such a long time! It’s simply nothing compared to this!

The next feature I hope to add is support for type hinting in function calls. I.e. only show arrays where arrays are requested and the same for objects of a given type. Also no PHP keywords are currently completed at all…

other DUChain/UseBuilder stuff

Thanks to the DUChain you already get lots of information about declarations, such as uses (which files, which lines etc.). Also very neat is the hover popup you might now from C++ which among others shows you phpdoc comments inside your browser. I also plan to integrate the php.net documentation into KDevelop, similar to what is already possible for QtHelp.

inline validation / syntax checking / linting

Another feature which saves lots of time is on-the-fly syntax checking: You won’t have to fire up your web-app inside a browser just to be greated by that pesty “syntax error, unexpected ‘CHAR’ in FILE on line XYZ” message… No! Instead you will see a nice reddish zig-zag line where you made the error and can fix it before heading off to the browser.

But we don’t only do basic syntax checking. We do more than that, thanks again to the power of the (holy?) DUChain. You can spot undeclared variables, function/method/class/constant redeclarations and more. Actually I hope that one day we spot most of the notices, warnings and errors PHP could emit.

tests

We already have a multitude of regression tests which will make sure that we don’t mess up any existing stuff. Lets hope for even more of them :) I love test-driven development.

The End

Well, thats pretty much it for the moment. You can have a look at what we are up to at the Quanta Feature plan on techbase.

If you are a PHP developer and can write C++ with Qt, why not get in touch with us? You can find us both on the KDevelop mailinglist and at least me and leinir are often found in #kdevelop on freenode.

PS:

Let me finish with a quick introduction of myself:

My name is Milian Wolff, I study Physics at the FU Berlin (just finished the 3rd semester). I started learning programming when I was around 14 with PHP. Over the years I became very good in it and the other webdevelopment techniques like Css, JavaScript etc. Recently I started to fullfill my biggest geek dream by learning C++/Qt/KDE and starting to contribute to the KDE project.

Some of you might now my from the LinuxTag in Berlin where I could be found at the Kubuntu-De.org community booth. At least with some of you I had a beer (well, I doubt it was only one). I hope to repeat this tradition in 2009. Every once in a while I can also be spotted at ubuntu-berlin events.

Kirocker is such a great application, it’s a pity the developer Sébastien Laoût has given up on it and is using Windows now!

Usually I only use the kicker applet, the full screen window is nice for parties though. But I didn’t like the way the applet handles scroll events: It seeks (if possible). Since I rarely seek when listening to music I’d rather have the behaviour of the Amarok tray icon: volume control!

I had a look inside the sources and found this part in src/coverdisplay.cpp:

void CoverDisplay::wheelEvent(QWheelEvent *event)
{
    if (areControlsShown()) {
      if (event->orientation() == Qt::Vertical) {
         PlayerInformation *infos = PlayerInformation::instance();
          if (infos->canSeek()) {
             int deltaSeconds = 10 * (event->delta() > 0 ? 1 : -1);
               m_infos->seekRelative(deltaSeconds);
            }
      } else {
           if (event->delta() > 0)
              AmarokApi::volumeUp();
         else
               AmarokApi::volumeDown();
       }
  }
}

As you can see it already supports volume control via scrolling! The thing is I’ve disable four-way scrolling for my MX1000. Thus I’ve simply swapped the if statements and now I’m really happy with Kirocker. Here’s the updated snippet:

void CoverDisplay::wheelEvent(QWheelEvent *event)
{
    if (areControlsShown()) {
        if (event->orientation() == Qt::Vertical) {
            if (event->delta() > 0)
                AmarokApi::volumeUp();
            else
                AmarokApi::volumeDown();
        } else {
            PlayerInformation *infos = PlayerInformation::instance();
            if (infos->canSeek()) {
                int deltaSeconds = 10 * (event->delta() > 0 ? 1 : -1);
                m_infos->seekRelative(deltaSeconds);
            }
        }
    }
}

Replace the old code, compile Kirocker, install it. Then restart kicker (killall kicker; sleep 1; kicker;) and Kirocker should accept scroll events in the way the Amarok tray icon does!