The completness

The completness of the Richard Stallman's conference is amazing. It has laughs, tears, drama, religion and even music. You name it.

Why isn't there a problem to be Konquered

Recently there's been a couple of posts by Kyle Cunningham suggesting, for the n-th time, that KHTML should be dropped.
That seems to be a recurring topic in the planet, and already some answers have appeared to the most recently discussion, both of which shows that people is tired of that topic, of course by people I mean, in this case, Benoit Jacob the writer of both posts and also those who have answered the very same question in the past. Of course I must disagree with him in one central point: every opinion should be heard and as such no policies should be applied to the PlanetKde.
So in my opinion, why isn't there a problem to be konquered? well simply because Konqueror, and KHTML by extent, is being maintained. So?, that's it?, yes, basically. We can elaborate it more: Konqueror and KHTML offer the integration with KDE that Webkit lacks, and, if we can believe the opinion of a KHTML developer whom I discussed during the last akademy, actually has a cleaner codebase.
I'm not saying that the points raised by Kyle Cunningham aren't valid, but they've been answered over and over in the past. And, to be honest, this is Open Source Software after all, not because someone decide to let die a project it will actually die. In the end, those who code have the last word, and are those who decide whether to continue or drop the towel. Right now the KHTML developers have decided to continue, and actually I'm trying to join them, but I should tell you in a later post; so please stop trying to hurt the community. Either that or work in your own alternative, if such a project is proven to be more viable, then the community will stand by it. Yes, in that aspect I agree with Benoit Jacob.
So I'm left with nothing more to say other than: please stop trying to kill good, and mantained, projects.

Another new Arch user

I wasn't going to blog about it but once I saw Rob Scheepmaker's post about his change of distribution I couldn't resist myself.
I was dragged towards the FOSS world by OpenOffice.org. It was the very first Open Source program I ran, later I installed firefox and was still a happy Windows user. Surfing through the Web I found an announcement about this thing called Ubuntu which used Linux, I always saw Linux as a geeky thing and as such I was very curious and wanted to use it. This one promised to be easy. I downloaded the Ubuntu CD and very excited I proceeded to install it, it was the 6.04 version, the 6.10 was still beta and I didn't want to take any chances.
I loved it, I mean it, I had a feeling of freedom I couldn't describe. Although a few days later I got a little bored of Gnome (I couldn't play much with it) and decided to give KDE a shoot. Again, I was so excited when I was writing those commands "apt-get install kde".
Needless to say I was blown away by KDE and reinstalled using Kubuntu 6.10 (if I recall correctly) and I had been a happily kubuntu user eversince... till a few months ago.
It all started when I upgraded to the beta of Kubuntu 9.04... everything began to feel slow, very slow, I was puzzled because I hadn't installed anything new, but I said "it's a beta, it's normal", so I disabled composition and seemed to help performance,although I loved KWin's new effects, I lived with that... then I started to have problems with the painting of windows, a lot of garbage was being painted on my windows, I said "What? this is an Intel system, I've never had any troubles with it" then I looked and yes, was a known problem for Intel-based video cards. And I thought "it's beta, it's normal"... and I lived with that.
Later when I fired up OpenOffice I had no spell checking!. Had to look and ask at IRC, yes the maintainer had forgotten to provide the right name for the package, a symlink and problem solved. And I thought "it's beta, it's normal"... and I lived with that.
Then What really pushed me beyond the edge was that I plugged a mouse device and it froze the system!, I was shocked. When it happened again I thought "it's time for a change".
So I started looking. I had the idea of using Arch for some time now and with the pain of first configuring it gone thanks to the Chakra project I went for it.
So far I've had some minor issues which I've been able to tackle. And besides that I have to customize it to use the packages I use I'm a very happy new user. It's fast and it's nearly vanilla KDE, so what else can you ask for? =D.

All I want to say is that I have nothing against Kubuntu and its fillosophy, it was there for me to make the switch and I'm sure it'll help others to do it. But please, can QA be taken more seriously?.

How to assert and still have your compiler happy.

I've been questioning whether to post this or not, since may be there are a more than a dozen ways to solve this problem and I might just be overcomplicating a simple meter. In the end I decided to ask and expose my ignorance because that's the only way you can learn =).

Recently, relatively of course, a new problem has arose in the KDevelop mailing list. In essence the problem lies in code like this:

bool check = foo.doSomething();
Q_ASSERT( check )

or

bool check = foo.property()
foo.doSomething()
Q_ASSERT( check == foo.property() )
You get the idea.

Which is better than what it used to be:

Q_ASSERT( foo.doSomething() )

very effectively making the project not work on release mode =D.

However the first statement, while correct, creates noise in the form of compiler warnings about unused variables. A solution that somebody proposed was just:

#ifndef QT_NO_DEBUG
bool check =
#endif
foo.doSomething();
#ifndef QT_NO_DEBUG
Q_ASSERT( check )
#endif

or
#ifndef QT_NO_DEBUG
bool check = foo.property()
#endif
foo.doSomething()
#ifndef QT_NO_DEBUG
Q_ASSERT( check == foo.property() )
#endif

Legibility suffered so it was reverted, at least it was asked to be reverted, not sure if the reversion was made.
As a solution I proposed just wrapping the variables in a Q_UNUSED macro but I got in response that that's the wrong message in the second case since they are used, only not in release mode. So the question is, how to solve the problem?.
While I want to hear what you can come up with here's a thought:
For the first case we could create a new assert, name it K_ASSERT for originality sake, and have it like this:
K_ASSERT( bool check, foo.doSomething();, Q_ASSERT(check) )

which might be expanded as:
bool check = foo.doSomething();
Q_ASSERT(check)

on debug mode and just:
foo.doSomething();

on release mode.
And for the second case we would need a macro which allows us to run code only in debug mode:

K_DEBUG_MODE( bool check = foo.property(); )
foo.doSomething();
Q_ASSERT( check == foo.property() )

which, if I'm correct, would be expanded as:
bool check = foo.property();
foo.doSomething();
Q_ASSERT( check == foo.property() )

on debug mode and
foo.doSomething();

On release mode.

All in all I need that in essence what's needed is a macro which let you separate release and debug contexts allowing you to execute code in debug but not in release mode.

After thinking it further I believe that no K_ASSERT is needed but K_DEBUG_MODE can be used instead and then the first case might be written as:

K_DEBUG_MODE(bool check = foo.doSomething(); Q_ASSERT(check) )

As a disclaimer I haven't played enough with Macros to tell whether it'll work or not but what you guys think? am I taking the long route?, is there something already thought for these cases?.

The good, the bad and the ugly

The good: I couldn't resist myself to post this, my proposal for the GSoC was accepted! yay!. Thanks KDE and Google.
The bad: this is my first post in the last 3 months!, 3 months!, that's a lot actually. Now I remember another reason why I didn't get a blog before.
The ugly: I haven't helped to the FOSS community as much as I would like to, I've helped a bit, but that will be said in another post; my classes are more than enough to keep me very busy. Just as an example: I have to finish off a lexical analyzer, a quot of prices for an hypothetical computer, investigate about microcontrollers and study for an Accountancy exam which will occur in exactly 3 hours and a half.
So, just a normal busy life as any other.
See you later guys.

Hello planet!

Hello everyone. For some unknown reason I didn't get the mail in which i was notified that my blog was syndicated to the planetkde. However I just noticed I have been added!. So here I am to introduce myself.
My name is Carlos Licea, I live in Mexico, am a student of Computing Science and I worked for marble as my GSoC, recently I joined the KOffice team helping with KPresenter. I hope I can showcase some of the development I'll be doing in both projects, although I was a little distant because of Christmas and family I'm back to hack :).

Quick reminder

Here's my first update which i did in '/marble/projects/flatproj', that was before I decided to move to a blog, and my decision to move to a blog was mainly done because of the 'blogish' style it had:

Hello everyone, this is a quick update in the development of the 2D projection of Marble.
The first week of the project wasn't very productive. It wasn't until the second week that this project took off, the next two weeks were very productive indeed. We've been working since then in the mapping of the texture for the flat projection. Finally we arrived at a point in which I think that part is almost ready, so for now we can paint the background of the map, other layers will be ready in a very near future.
In the current approach I totally reused the painting method that was already built in Marble named pixelValue, in which basically, I just calculate: the point in the screen what I want to paint and the longitude and latitude it must be representing so that i just send it to the pixelValue method and it automatically loads the needed tile and paints it accordingly.
Currently the zooming and moving of the map is already done so I can show you, this wouldn't be a good update without a screenshot, so please visit http://developer.kde.org/~tackat/marble/marble_flat0.png to see how's already done. What we see there is the texture being loaded but nothing else.
This used to only work on my PC because it was not a method by itself but most like a patch, now it's fully integrated with Marble's SVN, anyone who compiles marble can chose whether it paints the earth as a globe or as a flat map. So what was just done? well we changed the classes so that we could split them in different methods. The old class was TextureMapper which (as all other classes) assumed that we are painting a sphere, so we changed that behavior to ask how are we painting instead.
For that end, Andrew Manson introduced a new class named AbstractLayer so that any layer (and hence any painting method) can be inherited from that class. So I introduced another class which inherits from AbstractLayer: AbstractScanlineTextureMapper which will provide the methods or 'tools' and the basic values (such as the center point, the height and the width of the painted area...) needed to paint a map using an Scan-line approach (basically this means that we go scanning every pixel in every line of the painting area and calculate what longitude and latitude it must represent).
Once I did that, we inherited 2 classes from it: FlatScanLineTextureMapper and GlobeScanLineTextureMapper, booth have a self-explanatory name, but in case you don't get it we made our two methods for our two projections: Flat and Globe.
This is done and I only have to solve some medium (such as mouse detection, which still thinks that the globe is being painted) and minor problems.
So what will happen next? (hopefully a lot :D) well the first half of the GSoC project will be finished by fixing the mouse behavior and allowing place-marks to be painted as well as the vector map (rivers, countries, and so on...), and hence giving a full useful flat projection for marble.
In the next half of the project we will be working in another approach for the mapping method which will hopefully improve performance, my guess is that we will have a minor or medium, at most, performance gain because what will be changed is basically that we will no longer use the method pixelValue to look for the tiles needed and hopefully reduce HD seeking.
Carlos

I post the image so that you don't have to follow the link, nor waste kde bandwith ;), so here is it:



After 'publishing' the post I was corrected by my mentor, Torsten, that the HD seeking is not the problem that we want to avoid but the fact that we recalculate and repaint everything again when we move the map. This is not needed in a flat projection, as the viewpoint doesn't change. So this will be solved in the next half of the project.

I'm not very versed in this topics, but according to my mentor what we will do is upload the map to the X server and then just repaint the areas which are missing when we move the map (or at least that i understood). That way we will vastly improve performance as we will not waste cycles in parts of the map that we already know.

And remember,this post it's outdated, and is merely an introduction, I will post another one in a couple of days in which I'll show you that the placemarks and the grid are coded.