KOffice 2.0

The KOffice team has released version 2.0.0. This is a very important milestone as it is the first actual release of what represents some three years of development. It's not recommended for production use yet, however. The 2.0.0 release is a platform release: it's a way to "get it out there".

What are the implications of "getting it out there"? It means that the KOffice team will now have "release often" on their mind, it means early adopting testers can more easily grab KOffice 2 for their operating system of choice and start testing it and it means that people who are interested in getting involved with KOffice as contributors can now feel confident that they are getting involved with something that isn't a vapour(ware) trail but something real that does real, actual releases.

This is not unlike the KDE 4.0 release, actually. I hope everyone has learned enough about "getting it out there" platform releases to make this first set of steps work well for KOffice 2 and the people behind it. That means not rushing to make it the default in operating system releases, testing it with the realization that there are many cracks left to be plastered over, etc.

The image Cyrile used on his blog entry announcing KOffice 2.0.0 sums it up visually just perfectly:

Together, including those of us who don't contribute to KOffice directly, we can make this a great success. I'm really happy for and proud of the KOffice team, and I hope you can be as well.

Kexi and Krita are my personal faves, but the entire suite holds immense promise.

You can read more about the release by visiting KOffice 2.0.0 article on TheDot or visting the release announcement from the KOffice project itself.

Read More

today's heroes

Every so often I'll post about my heroes for the day or week. These are people who have done something exceptional that elevates their efforts in quality, quantity, impact or all three. I'm sure we all see examples of this in KDE on a fairly regular basis, but it's nice to take a moment to let them know.

Such is the case with Dario Freddi Andres. (D. Freddi's a great guy, too, who is also active on b.k.o and Plasma .. but I was thinking about D. Andres. Too many Darios. Oops!) He's been an absolute monster on bugs.kde.org for the Plasma team for a while now. Dario comments on, tests, finds duplicates and even offers solutions on an amazing volume of reports. Without Dario, our bug list would be in much worse shape than it is.

The striking thing, at least for me, is Dario's knowledge of the entire body of reports. He often knows what reports are probably duplicates, when certain kinds of problems were fixed (so reports against older versions of Plasma / KDE / Qt can be flagged appropriately), etc. This is the kind of knowledge you can only get by being around the body of reports for an extended period of time. It's not unlike getting to know the layout of a town or the woods in your backyard: you need to do more than just glance at a map and walk through it once. To really get to know it, you have to spend time in it and move all around it.

I wish we had more Darios, as his level of knowledge about the reports in bugs.kde.org against Plasma is invaluable and certainly surpasses my own.

Another hero for the day is Skanlite. It's a small application that does exactly what I need it to: operate my scanner. It doesn't have a million fancy features. In fact, it has hardly any fancy features at all, and that's the beauty of it. I fire it up, it detects the scanner automatically without any configuration and lets me get to the business of scanning directly. I only use my scanner once every month or two, but when I do I don't want to spend time with it. I want to just throw some paper in it and hit a button, maybe adjust the contrast or DPI or switch to grayscale instead of colour. Skanlite does exactly that.

I'm sure there are those who need or want a more complicated and capable application for scanning because they do a lot of it on a daily basis and have additional needs like batch processing or image management. That's something that really belongs in a different application, however, and I applaud Skanlite for sticking to it's one purpose, which probably covers 99% of use cases right there, and doing a damn fine job of it.

Skanlite, of course, relies on things like USB and sane working properly in the operating system. These are things I couldn't take for granted not so many years ago with the exact same hardware (my flatbed scanner is rather old, but it's a great workhorse and keeps on churning), so kudos as well to the people working deeper in the stack: you make it possible to let people with good UI sensibilities attack those problems without getting lost in a maze of hardware issues.

My third hero for the day is Gitorious. I added a developer to the KDE developers team on Gitorious today, something I hadn't done before, and it took me all of ten seconds to figure it out and actually do it. This is what I call lowering the barriers to entry! So far my experience with the new Gitorious along with the Qt universe that is developing there is bringing nothing but smiles to my face. I'm looking forward to some of the more advanced features they have planned and hope that in the not-to-distant future we can have a git.kde.org ready to go using the same software.

I'd also like to make a mention in passing to some of our younger contributors: there are a few teenagers who contribute to KDE and Plasma out there. They often don't work at the same pace or with the same confidence as the older developers, but I admire their tenacity (they just keep banging away at the problems until they get it right) and their spirit of adventure. I remember the awe I felt when I got to work with others in industry on real world projects as a teenager and how I had to work extra hard (or so it felt at the time) to accomplish what seemed effortless for these experienced hands who were helping guide me through. It's wonderful that we have a similar spirit of mentorship and apprenticeship in KDE.

As for me, I'm in between conference calls and patch reviews at the moment. If things go well, I'll be able to spend my afternoon quietly coding. :)

Read More

wamf

Back in the day ... waaaay back in the day, I had a friend who had once sung in a punk band in New York City (hello, CBGBs! :) and at one point got accidentally (long story) committed to a mental institution. She had a pretty crazy life in general. Anyways, she used to ask, between drags of her thin brown cigarettes, "Wamf?" (Pronounced "wawmpf", or something like that.) What she was asking was, "What are my feelings?" Well, she wasn't actually asking what her feelings were, but what yours were. She was odd like that.

There are still days when I sit back and think ... "Wamf?"

I got back home from Switzerland Sunday night, and got right back to work on Monday morning. I was in the Confoederatio Helvetica for ten days .. and I really wouldn't even know where to begin about the trip. French people singing songs in their mother tongue, backed by an upright base and a nylon strung guitar on a rooftop terrace in Zurich at night? Or how they launched fire-toting paper hot air balloons from the deck so we could watch them float over the city (!) and up into the clouds? Or the dragons on the water spouts in Gottlieben? Or revisting Kreuzlingen? Or tramping on foot into Germany to do some shopping? Or cycling through the old town in Biel/Bienne? Or eating Spargel themed dishes on St. Petersinsel? Or watching fencing?

(Edit: I nearly forgot to mention the guy I saw using a laptop with KDE 4 on it in an airline lounge in Heathrow. Turned out he was an astronomer doing research at a University in England. Neat...)

I wasn't online much during the work week in between the two weekends I was there, but I got some work done. More importantly I had the chance to breathe. Wamf? Calmness .. happiness .. contentment.

I'm back now and my body has finally caught up with being eight timezones to the left again. Not bad given that I got in at 23:00 and was at work by 09:00 the next day. Maybe they could make timezone hopping an Olympic sport. It's probably the only realistic chance I'd have in participating in the games. Assuming, of course, I somehow lost my ethical issues with them. That's another story though. Wamf? A little exhausted.

I've been mostly working on bug fixing these last few days, though I've also been working on moving forward some netbooky type project stuff forward. It's a bunch of somethings I've been working on since last November and which has had more than its fair share of ups and downs. It seems on the up now, though, and I hope to be able to blog about the whole thing sooner rather than later. Wamf? Excited, but with great caution in the winds.

While I work on bugfixes and attend conference calls, I'm jealously eyeing up the GSoC students working on fun new features and Marco and Artur starting in on the new netbook interface. I'm happy that we've got so many really important "last mile" type projects going right now. It leaves us in a momentary "nothing new to show" trough, though, as all these projects are in their first trimester (to use a pregnancy analogy, for no particular reason). It's good timing, though, with 4.3 just a couple months out, as they should be maturing very nicely in time to drop into trunk when 4.4 dev opens up and in a good place to work on at Akademy. Wamf? Pure excitement, a little envy, no caution needed. :)

I also have convinced a fellow here in Calgary to start a little project so that we can demo a really neat aspect of Plasma for people. It's sort of a parlor trick, to be honest, but the kind of parlor trick that could take off in a big way with the right opportunities. The project is building a proof of concept device using an Arduino processor with a Bluetooth board attached. When you approach with a Plasma device (well, pending Rob's GSoC project on Remote Plasmoids) we'll see that there's something available via Bluetooth. Plasma will poke the device such that it spits out a Javascript Plasmoid that will then appear ready for action. Walk away and the Bluetooth connection goes away and so does the widget. The first prototype app will probably emulate a printer: how much paper and toner is there; print a test page; etc.

The idea is to allow Plasma enabled devices to access things inside of otherwise "dumb" machines and give the user a rich interface to it with no configuration (just some approval and security clearances). Image this on a factory floor, or in a restaurant, or inside a vending machine. At first, I'd expect the applications to be pretty vertical as we don't have millions of Plasma devices wandering around in people's pockets and backbacks ... yet. ;)

Perhaps it'll just be a cool demo that goes nowhere, and it's certainly nothing that hasn't been thought of before ... but it's something that really fits with the vision of social and contextual computing: who are you, where are you, what kind of device are you using and who and what is nearby?

Wamf? A mixture of relief (to be nearing fruition of some of the longer term concepts) and tinglyness.

Oh, an I picked up a German language starter kit thing from PONS. Four CDs and a couple of books. We'll see how that goes. The wamf on that one is a sense of adventure (oooh, new things! :) and nervousness (I've never learned another language before and I have an odd sort of performance anxiety..).

Well, that was a lot of stuff about not much .. but it's what I felt like sharing right now. Hopefully I'll some stuff more in the "cool" zone to show in the coming weeks and we'll definitely be showcasing some of the nice stuff coming in 4.3 as it draws closer too ... but for today, I'm good .. hope you are, too.

Love 'n hugs ...

Read More

JavaScript ScriptEngine and plasmapkg in kdebase-runtime

I've moved the JavaScript Plasma ScriptEngine and the plasmapkg tool (which takes care of install, upgrading, uninstalling and listing things wrapped in Plasma::Packages) into kdebase-runtime. plasmapkg was being used by the PlasmoidPoackage in libplasma, so that one was almost a no-brainer, but the main reason for the move was so that Plasma using apps can take advantage of using Plasma::Packages for their post-install data add-ons and JavaScript for Plasmoids and Runners (in 4.4 I'll be adding DataEngines).

It was the Amarok team that asked for better access to these tools, which up until this point had been hiding away in kdebase-workspace which really isn't an acceptable dependency to carry for a non-workspace application.

I'm really excited about the growing usage of scripting, and JavaScript in particular, to extend applications at runtime. JavaScript has the combined benefits of being fast, lightweight, dependency-free for Qt and KDE using apps (it's already in the dependency chain), easy to add to your app and easily secured.

If your app needs to be extensible and you're thinking of providing a C++ plugin interface for it, think hard if you can't "get away with" a JavaScript based one instead.

I'm also noticing a lot more Python and Ruby coders appearing around KDE and working either full apps and/or Plasma addons. This is also a nice trend: Python and Ruby are, in my humble opinion, terrific and for many situations perhaps even the preferred path compared to C++.

Read More

just when i think...

So I've flipped over into bug hunt mode and amongst the various other things I had to do today I decided to tackle some outstanding beasties.

The slowness of loading the slideshow wallpaper was one such problem to tackle. After a couple hours working on it, I managed to reduce the time to build a list of wallpapers by ~97% while also drastically reduce the memory usage. Can you say "low hanging fruit"? :)

What this means, for instance, is that the same 3,200 image and 84 package collection spread out across 91 directories (nested within 4 "top level" directories) went from taking ~14.5 seconds to load on my laptop (which is time spent waiting at log in) to ~0.4s.

Seeing as this process supports both regular image files for wallpapers as well as detecting wallpaper packages while recursing through the directories and avoiding duplicates, that's not too horrible. Probably still space for improvement somewhere in there, but I was feeling pretty good about myself and that little accomplishment ...

... until I read this email from Luboš on kde-core-devel. He wins. :)

Read More

Akademy 2009: The reason to go.

When I look back at each installation of our annual global conference, Akademy, the purpose for attending was pretty obvious.

There are the generic reasons, which make not only Akademy but all KDE face-to-face events worth attending: building personal bonds with people in our community, working out answers for the hard questions that can take hours (or even minutes) in person instead of weeks or months (or never) by email and irc, trying new ideas out in a collaborative environment, pushing hard to put polish, finish and completion at the end of a long push of development.

Each Akademy has also had, at least for me, some special reason to:

• Ludwigsberg: the first one, held in 2004. (C'mon, you can't miss the inaugural!) There was a lot of "so, where do we go from here?" where "here" was KDE3; usability, multimedia, desktop search, improved C++ ABI. A lot of what got started there ended up setting directions for KDE 4.


• Malaga, 2005: a big focus on integrating the KDE platform and the rest of the frameworks we deal with and with a lot of emphasis and discussion on application development progress. It was also where we started working on some of the hard decisions for KDE4: emphasis on JavaScript for scripting, moving away from KControl's treeview as the default interface for control panels, etc..


• Dublin, 2006: KDE 4. This is really where a lot of the firming up of the "what will KDE 4 be" discussion took place


• Glasgow, 2007: Getting KDE 4 out the door. Lots of talks and discussions about what we'd come to call the Pillars of KDE and work on getting these pieces into place in our apps.


• Belgium, 2008: KDE 4.0 is out the door, how do we take that first step and get it ready for production use? What are the missing bits that still remain?

That list glosses over a lot things that went on at each of the Akademy events. It's really impossible to completely capture what it's like to spend a week with a few hundred people all eager to move KDE forward to the next plateau. The meetings, the talks, the good times, the cool hacks ...

... so what's in store for Akademy 2009? What will be the one line summary for Gran Canaria a year from now? In other words: why should you want to be there? Obviously there are the generic reasons; those are constant and not to be lightly dismissed. If they were the only reasons for beign at Akademy it'd still be worth going ten times over, but they aren't the only reasons and that's what keeps Akademy so special year after year and why it grows in participation and usefulness as measured by results year over year.

My input would be this: make it about where we are headed with KDE 4.5. Yes, that's two releases out and it's certainly not realistic to put detailed feature lists together, but we ought to be picking our heads up again at this point and looking a bit forward.

If you look at the Akademy retrospective list above, you might note that we started looking at KDE 4 when it was way over the horizon and we were still working on KDE 3.4 each and every day. As KDE 4.0 approached, our line of sight grew shorter and our focus more intense. Then as we crossed the start line, marked by 4.0 being released, we started looking pretty much right at our feet instead of the horizon. None of this was wrong or bad, it was exactly what we needed to do at that point in time.

What we ought to avoid, however, is getting in the habit of looking at our feet exclusively. That's really easy to do once we've hit our groove and are into the business of polishing (stabilization, feature fill-ins and performance improvements). It's what happened to the project sometime early on in KDE 3 and the result is that by the time we got to 3.5 we had a big pile of features and nowhere clear to go with them.

KDE 4 has the potential to not end up as a "big pile of features"; it can instead embody clarity in direction and harmony in purpose.

We have some really clear pathways that we drew out for ourselves: beauty (advanced graphics, solid visual design), usability (simple as possible, but no simpler), environmental awareness (think: Solid), desktop search and semantics and other advanced functionality. These are not things a project achieves over night or even over the course of one year. They are a journey, one that is so enjoyable to take that it's just fine that we keep extending the end points for ourselves no matter how far we get. We need to make sure we are still on those paths, and maybe even come up with some new ones if we've discovered that, having come this far, we have some missing tools in our toolbox.

That won't happen if we stare exclusively at our feet, however.

Akademy 2009 is the perfect opportunity to lift our heads up and look into the near distance. We don't need to look out as far as we did from the perch of KDE 3.3 into what would become KDE 4.0, but we need to look beyond the impending release of 4.3 as well.

• How far along the various paths we set out for ourselves are we? This is the question where we pat ourselves on the back for what we've accomplished thus far and then use that energy to draw big red lines around the bits yet missing.


• Where do we need to put more resources and focus? (Personally, I'd put Nepomuk up as a good, though certainly not only, candidate)


• What goals do I have for my project in the next year?


• Let me hear your goals for your project in the year...


• What is the role of $PROJECT in the larger context of KDE? Who uses it, relies on it, contributes to the bits underneath it?


• Now that we've arrived at this point, what new audaciousness should we add to the mix? (Personally, I'd add "innovative netbook experience", "social desktop" and "support the new financial applications module to become the best in breed set of F/OSS apps in that category" as three of them)

I sent around an email to a number of projects in the KDE universe asking a series of questions for a "KDE 2009 Introspective". I had planned on releasing the results of that within the next week or two. Instead, it seems that a keynote at Akademy 2009 might (it hasn't been confirmed yet, so I might be jumping the gun a bit here ;) be given about it. In which case, I'll extend the findings, do some follow up rounds, harass the projects who haven't responded and try to hit up even more projects than I did in my first round of pestering .. er .. emailing.

(On a side note, even if it is approved, I won't be delivering this presentation since, for personal life reasons, I won't be at this Akademy. It tears me up inside that I will be missing Akademy this year, the first one I won't have been at, but it's the Right Thing(tm) to do right now in the bigger picture. You can put money on it that I'll be at Akademy in 2010 though. :)

My hope is that everyone who comes together for Akademy 2009 helps craft in a collaborative fashion this heads-up snapshot that we can use together to lay down another year or three of KDE awesomeness. My hope is that we take the time to identify topics which people can then hold sessions on to form consensus based directions that we then execute in the next year.

As someone who will be waiting for the results on the outside, I hope that those who are there can exit with a clear and focused message of "what we saw, what we decided, where we're going".

To accomplish that, Akademy 2009 needs you to be there. Your attendance will be an opportunity to not only hang out with one of the coolest bunch of people going in software today but to also help draft the exciting future of our project by examining where we were, where we are and where we want to be. World domination awaits.

Here is the registration page, you know what to do. :)

Read More

Qt development opens up

In case you missed it, Qt is now being developed with the help of an open gitorious system. This was a long time in the planning and a lot of work to get out the door (including funding some development of gitorious), so hats off to the people at Qt Software for that.

What this means is that we can now both contribute easily to Qt itself as well as track development of Qt as it happens. Right now it's only syncing twice daily to the Qt Software internal git repository, but as I understand it this window will shrink down to realtime as the system proves itself to be working well.

Seeing the number of clones that have already popped up and the sorts of things people are working on in them (ranging from bug fixes to performance improvements to new features) it should be pretty interesting to watch this evolve.

I remember being at a Trolltech Dev Days a few years back when someone in the audience asked Matthias Ettrich, who was on stage taking questions after his keynote presentation, why some feature was missing in Linguist ... and the next question was someone asking something similar about Designer. It struck me that these are exactly the kinds of small features that the people in that audience could have contributed themselves quite easily had they the opportunity to do so. Now they do. :)

Now I wonder how much longer until KDE's sources are hosted in a git repository... :)

Read More

random ramblings, nothing to see here

Yesterday I had a bit of a fever, probably something I picked up from P. who was ill earlier in the week from something he picked up at school. My laptop had also started to overheat randomly. So after some light hacking in the morning (reworked the time engine to be a lot cleaner internally now that it does sun and moon positioning, by creating a TimeSource class instead of using DataEngine::setData directly; this means the source name is parsed out exactly once and prevents dozens of allocations on every source update (which is twice a second for clocks showing seconds); this also resulted in some internal improvements to Plasma::DataEngine itself so that engines using custom DataContainers don't incur any odd performance penalties; then triaged a few dozen bug reports) I turned the laptop off, took it apart and cleaned out the fan assembly of dust and fluff.

Good news is that today the laptop temperature is back to how it was when I first bought it (love that temperature plasmoid, btw :) and my fever is gone too. Huzzah for that.

P, some friends and I are going to see the Start Trek movie tonight, so I hope its as good as people have been saying.

I'm also taking up a second language, more seriously this time, because I have a renewed need to communicate effectively with people who speak German. I was looking at various "Learn German" offerings at a local book store and the "Instant Immersion" series looks interesting but the entries for it on winehq looked pretty dismal as far as running it in WINE goes. Does anyone out there have a recommendation for a good "Learn German, You Stupid Enlglish Speaking Monoliguist" product?

I'm looking for something that's not audio-only or text-only, as I learn much quicker with multisensory input. Software would be cool, but it has to run on Linux. Otherwise, I'm looking for something with a book and some audio or video CDs/DVDs.

Oh, we also spent some time filling in some of the missing bits on the Plasma "significant changes" changelog for 4.3. That's all stuff that's actually in svn right now for 4.3.0. I'm sure we've missed some things from that list as well, and the "small" things aren't in those changelogs because then it would just be silly long and probably not overly useful due to the ammount of "noise".

This also means we're moving into bug seek-and-destroy mode for 4.3.0. Yesterday I put together a small list of zooming and activity regressions to squash in the coming week and we're making good progress on the resource leak problems as a number of reporters have been exceptional helpful in sending in detailed information about their system and output from various measuring tools when they run Plasma or just specific widgets in various configurations.

Right now, though, it's dinner time.. and then Star Trek time. Yay! :)

p.s. Glad to hear that the KDE GSoC students from North America are having a good time in Boston! From the pictures I've seen, it looks like we have decent gender representation even, and I'm hopeful that we can keep as many of those students involved with KDE in the coming years as possible so we can build our army of North American KDE partiers .. er .. hackers. ;) Seriously though, there's more funding in the pipe for North American hackfests related to Qt/KDE; ping me if you have a good idea for one. :)

Read More

FindLibKNotificationItem-1, take 2

The KNotificationItem lib is now in kdelibs/experimental/. This builds automatically if you grab kdelibs from svn, and will be packaged separately from kdelibs for release (so there will be a kdelibs and a kdelibs-experimental package). It also means there's no need to grab extragear/libs or anything else; just svn up kdelibs and build. This should be the best of all worlds and give people tracking KDE from svn and application developers (hi KDE PIM-stars!) fewer heart attacks. ;)

This was my original suggestion (or was it kdelibs/kdeui/experimental?) but was turned down on kde-core-devel. So I followed consensus, and then it turned out that the consensus solution had problems. We went back to the drawing board and found a new consensus position. Hopefully we have something that will work for everyone now. Just goes to show that sometimes it takes a couple attempts to get a new process down right.

Thanks to everyone who was involved in the process for keeping their heads and the discussions on track. I'll be updating the Techbase page later today or tomorrow (depending on how my appointment this evening goes) to reflect the extended and updated understanding on how to trial new API that is hoping to be destined for kdelibs proper.

Love 'n hugs ...

Read More

FindLibKNotificationItem-1

If you update various parts of KDE svn today and cmake starts telling you that you are missing FindLibKNotificationItem-1, please checkout (or update if you already have it) extragear/libs/ and install libknotificationitem-1. This is the temporary library for the "client" side of the new system tray protocol we're trialing in 4.3.

If all goes well, then we can nail down the API and ABI for KDE 4.4 and move it into libkdeui where it belongs. Until then, however, we're following the New KDE Library API guideliness (which were written alongside the development of libknotification, actually, with input gathered up on kde-core-devel), and shipping a separate library for it that doesn't carry the hard API/ABI requirements of kdelibs proper. It's a balance between "releasing late and getting next to no testing" and "releasing early so we get testing but without endangering the API quality in kdelibs".

As a recap, the main benefits of the new system are:

• Speed: icons appear "instantly" rather than taking user-noticeable amounts of time to display in the tray


• Beauty: they can be properly themed, resized and painted flawlessly on a canvas; none of this was possible with the old system.


• Alternative display: I expect this to be a nice win for accessibility in that we can now make non-22-pixel-icon system trays. They don't even have to be icons, in fact. They could be text only, audio or even just REALLY REALLY BIG.


• Multiple hosts: one entry can now be shown in multiple places; this not only means things like being able to have a tray on each screen in a multiscreen setup, but also things like being able to integrate entries with their taskbar icons without giving up the old tray or "welding" the system tray and tasks widgets together in Plasma. It also opens the way to divide up the system tray into different widgets specific to a given category of icon, e.g. an area of messaging (and without having to patch all the apps for that specific use case).


• Interaction: the interaction is now completely defined by the host visualization. So, for instance, instead of "middle click" we now have "secondary activation". This allows the application side to provide the functionality but the host environment to decide what triggers it. End result: greater consistency.


• Application information: applications can now say "this entry is about hardware" or "this entry needs attention!" Now that the host can know the type and state of a given entry (and, really, any other piece of information we might find useful) we can finally provide things other systems have had "forever" like intelligently showing/hiding icons based on their usefulness to the user at that point (and yes, this will remain configurable :).


• Backwards compat: it still works with the old xembed system :)

I sent a preliminary email a week or two back to the freedesktop.org xdg list on it where it received some feedback. I really hope to see some uptake on this from other projects as a result, especially as we publish more formal specifications based on the DBus interfaces.

As this plays rather nicely into Canonical's "rethink notifications" activity I'm hoping they might pick it up and work on an upstream-able implementation for the GNOME desktop. In fact, I think the introduction of the messaging indicator library is a misstep in terms of cross desktop usefulness (what happens when you run a messaging indicator enabled gwibber in KDE, XFCE, or whatever other desktop?) and application patching efforts. Everything they have done there is (quite intentionally) 100% possible with the new notification area spec we're introducing by simply marking the entries in the application as type "Messaging". Then there is no need on the application side to figure out when to switching between the "traditional" system tray / notification area approach or the messaging indicator approach, it will work with all older (or just different) systems, etc.

Read More