(Un)Selecting groups of elements in Dolphin (Part II)

March 8th, 2010 ereslibre 13 comments

/me loves constructive criticism and nice ideas. I think I have several times guided some development through my blog in order to try to accomplish the maximum number of people ideas and suggestions.

This time is not an exception. Eike put onto the table something I was already aware, and something I wanted to fix, so his comment just pushed me what needed.

However I feel the need to explain why I won’t make headers clickable as before (unless you have a very good reason that will convince me :) .

1. On the rewriting of KCategorizedView now the “header” is “everything”. Have  a look at System Settings. You will notice the “header” is covering the whole area of elements in that block. In case we have such a “category drawer” (as it is called in the code itself), how can we “draw” it to say “hey you are going to select the whole group”. Imagine you could select several items in System Settings (you shouldn’t, despite in 4.4 SC it is possible), how could you notify that in a visible way to the user ?

2. I felt showing the same icons as Dolphin does was a nice idea. Dolphin has this icons for individual selection of items, and I think that was the best way to go.

3. For this improvement (still not in trunk) I have gone through the path of “disabling” plus and minus signs, instead of making them disappear. From some UI classes taken I have learnt sudden visibility changes on elements are not good for the average user.

So here you have got the video. As always, please feel free to comment, give ideas, suggestions…

Categories: KDE Development Tags:

(Un)Selecting groups of elements in Dolphin

March 7th, 2010 ereslibre 10 comments

I am very happy to blog again about KDE. Here I come with an old feature with a new face. I will hopefully come soon also with some Bluetooth updates, since I am working on a KCM for it, but it deserves another post entry when it is in shape and happy with it.

In KDE SC 4.3 I did some work for KCategorizedView to select several items by clicking on the header of the group. You could also unselect items, but that wasn’t so easy to discover. I later rewrote KCategorizedView internally to have a much better and clear structure. It was missing one feature: this kind of “grouping” selection. Todd wrote a patch for not losing this feature for KDE SC 4.4, which got into the review board and got into trunk. Nowadays KDE SC 4.4 has this patch.

I really had no time to review this patch, and I am the only guilty for this patch not being ’so good’. And I say this because of two main reasons:

1. It does not check whether the model allows multiple selections or not. You can check this problem by clicking on System Settings group headers.

2. There is no indicator that “something is going to happen if you click here” to the user, what can feel like kind of magic if you click on the view randomly and suddenly all those items become selected, when you really wanted to clear your selection.

Actually, this feature and collapsing and expanding blocks was somehow in shape with the rewriting. I had that thought, and some pieces of the puzzle were there, but I was missing the actual time that took writing it.

So, I got hands to work today that I had “some free time”. Here is the video result:

PS: This is still not in trunk. Finishing it and I hope very soon it will be all yours :)

PS2: If you feel curious about it, give it a try locally (kdelibs, and kdebase patches).

PS3: Do not misunderstand my words please, I deeply thank Todd for the patch since he introduced a feature that was lost.

Categories: KDE Development Tags:

Dreaming on bugtracking

December 30th, 2009 ereslibre 2 comments

It has been a while since my last post. I have been working mostly for University, and now I got a job offer to work for very little time (even from home) on a new business that is emerging here in Madrid, Spain. I think is a good chance to get things done (R), and finish my studies at the same time that I am working. Hopefully we will be doing some Qt stuff, so I am glad after all. However dreams are still there.

In case you don’t know, I have been working in a library, called the ‘Ideal Library‘. The idea was to create something similar to Qt (obviously million years behind in size and features), but with the advantages of the nowadays compilers improvements (c++0x in particular).

While I was setting up the Mantis bugtracker I thought that git, mercurial, bazaar are great tools. They allow you to work even offline among other really great features. However, there is a small problem here: what matters if you can work offline, having access to the full history of a project if you can’t access the bug tracking system because you need connection.

Here is when the idea came up. Why not having a bugtracking system that is also distributed. Why not even hook it up with git, being it a really great “one thing”. You can close bugs from your commit message, everything locally, and then, push those changes on bug reports state when you get connection.

And yes, bugs.kde.org database is actually huge. It would be a matter of just keeping the last 6 months attachments (or even older if you explicitly ask the system to do it for a certain bug report, because you are very interested in that one).

So to finish this blog entry, I’d like to wish you all a really great 2010 year, and I am looking forward to finish my studies and work hard on KDE. Really. There’s nothing I expect more than that, being back with this great community that I love so much.

Categories: KDE Development Tags:

KDE Spain (KDE España) is now legal

September 25th, 2009 ereslibre 5 comments

I am very pleased to announce that I managed to get all KDE Spain (KDE España) association papers in shape. We are now officially registered in the association list at national level in Spain.

Now it’s time to get a CIF (a number that will allow us to have a bank account) and keep working as we always have done, focusing on spreading the word about free software in general and KDE in particular, going to parties where we have something to tell, and something to show.

I feel lots of people will join and this will be a very productive relationship between the association and the associates.

Note that we believe KDE Spain is some kind of “sister association” related to KDE e.V, and some kind of work is going to go in that direction. Nothing much I can say.

So I really hope this will be the start of a very productive association, that will always look for the best of KDE project, and provide really positive commitment to the community.

If you are curious and feel like reading the website in spanish, give it a try: http://www.kde-espana.es.

PS: you can usually find us on #kde-devel-es channel at irc.freenode.org. So if you want to chat with us, and give feedback, as well as other matters, please join, or check the mailing lists listed on the website.

Categories: KDE Development Tags:

Research time

December 31st, 2008 ereslibre 7 comments

First of all… HAPPY NEW YEAR ALL !!

I felt I had to do some research… and I did for couple days till yesterday morning I felt ill as hell. Now, I’m getting better, and it seems the “virus” that hit spain got me too… Anyway, I’m winning the battle to my flu.

So, before getting ill, I had a look at Qt’s signals and slots, and wondered if I could do something similar myself. Well, I called this tiny library “Ideal”, and till now it only has signals/”slots” (there are no slots, we’ll see later) and a small timer for testing purposes…

I don’t mean this thing to be huge, but I guess I will be working on it from time to time. However, it was a great thing for me seeing it working. The “bad” thing: it uses c++0x stuff to work.

Let’s see a small usage example:

#include <object.h>
#include <iostream>

using namespace Ideal;
using namespace Ideal::Core;
using namespace std;

class MyObject
: public Object
{
public:
MyObject(Object *object = 0);

IDEAL_SIGNAL(mySignal); // signal with no parameters
IDEAL_SIGNAL(pushed, bool); // signal with a bool parameter
};

MyObject::MyObject(Object *object)
: Object(object)
, IDEAL_SIGNAL_INIT(mySignal)
, IDEAL_SIGNAL_INIT(pushed, bool)
{
}

class OtherObject
: public Object
{
public:
OtherObject(Object *object = 0);

void receivedSignal(Object *sender);
void buttonPushed(Object *sender, bool param);
};

OtherObject::OtherObject(Object *object)
: Object(object)
{
}

void OtherObject::receivedSignal(Object *sender)
{
cout << "received a signal ! (from object: " << sender << ")" << endl;
}

void OtherObject::buttonPushed(Object *sender, bool param)
{
cout << "button pushed ! (from object: " << sender << " and param " << param << ")" << endl;
}

int main(int argc, char **argv)
{
MyObject object;
OtherObject otherObject;
object.mySignal.connect(&otherObject, &OtherObject::receivedSignal);
object.pushed.connect(&otherObject, &OtherObject::buttonPushed);

// simulate that something happened, and see how slots become called
object.mySignal.emit();
object.pushed.emit(true);
object.pushed.emit(false);
object.pushed.disconnect(&otherObject, &OtherObject::buttonPushed);
object.pushed.emit(true); // this two calls won't have any effect (no "slots" called)
object.pushed.emit(false);
object.mySignal.emit();

return 0;
}

This is the general look of this stuff… the pros:

  • Signal/Slot type safe at compile time, not runtime.
  • No external tool like ‘moc’ needed for signals to work (also a weak point, see later)
  • You know in which order “slots” will become called. Planned also a way to “reorder” the way they will. At this very moment, they are called in the exact order they are connected.
  • Slightly faster than Qt’s signal/slot callings (based on a test that was doing 1.000.000 calls).
  • Don’t know if a strong point: there is no slot concept. They are callbacks, you can call the method you want using signals without mattering if it was declared as a slot or not. I can see the use case where you would have expect something to have been a slot but it isn’t, so you can’t call it easily with Qt’s signals/slots.

Weak points:

  • Tiny tool. At this very moment, this library only contains a timer and the signal/”slot” thingy.
  • Because no tool like ‘moc’ is needed, I haven’t got that cool meta object information that Qt has.
  • It uses a new feature from c++0x.

The philosophy:

  • Won’t be public until I have something more to show.
  • One-way-of-doing-it principle. Will try to KISS by letting the library user doing a certain thing in a certain way.
  • Correction. As everything… on the real paper this is much more difficult than in the theory :)
  • There is no interest in having this library built with old compilers and other systems than GNU/Linux (or better said, POSIX compliant). I mean, we all can get a free operating system which builds this library, so I don’t find the reason for making this library build for, say Solaris 2. However, the way it is going to be written allows it to be also expandable for other operating systems. Based on conditional d pointers where there is a d pointer for system doing the nasty job behind the cool scenes of the nice API.
  • C++ on steroids usage.
  • Obviously, this will be free software. At this very moment I have licensed the very small work as (LGPLv3), but well, I need to really study better all the licenses and decide.
Categories: KDE Development Tags:

Still moving… in the right direction ?

December 16th, 2008 ereslibre 31 comments

The more you get comments and the more you study something, the more lost you feel, at least where there’s really a few number of people that seem to agree.

This is what I currently have for System Settings, because I was asked to “columnify” elements. This is the first approach we can give, which consists on setting a grid, being its size the biggest width & height in all elements in the view:

This is what the current System Settings (in 4.0, 4.1 and 4.2) does. It maybe leads to really huge spacings between small elements because of only one item being specially big, because of its string. The other solution is to wrap the text at items:

I also have rewritten the way Dolphin draws the category, since it seems that almost nobody liked it. I want to say that accepting a gradient in Dolphin is a plain mistake from my point of view because of two reasons: performance and accessibility. Since I agree that maybe a lateral line there was not very useful, I have tried with this approach:

Update: as requested I add the screenshot when sorting by name :)

Categories: KDE Development Tags:

Little update

December 16th, 2008 ereslibre 44 comments

I just wanted to post the new look of both System Settings and Dolphin with their new drawing code. Note this is still not the definitive version, because they are still subject to change if someone points out good improvements. I want to remind the mockups Nuno did draw: this one for System Settings, and this other one for Dolphin.

Now, what we have at this moment (still not on SVN) is:

Update: I have removed a bit of blank unused space. How about this one?

As always, comments are really welcome =)

Categories: KDE Development Tags:

KCategorizedView – a polite approach

December 12th, 2008 ereslibre 20 comments

So many time without blogging… For being honest I have been really busy with university (still hell busy), and I have had time for coding mostly, without blogging on recent work I have been doing. Anyway, the short story, didn’t find the time to blog.

At this point, I am really happy to show you the new shiny KCategorizedView. It is not still on KDE’s SVN, but it will soon hit it. This new implementation will make it for 4.3, and is the implementation I was dreaming about.

When I was rewriting it from scratch, I could read Celeste’s post, and wrote it down deep in my mind. This was all about KCategorizedView and I had to fix all those problems now that I was on it.

That’s the time I asked Nuno to design a mockup (talking with Celeste also, to have the usability team approval). He sent me this two mockups:

This one is meant for systemsettings, while the next one is meant for Dolphin:

Until now, the “category drawer” was the header of the category. This means, it could say: my height is 15 pixels. The view would ask it to be drawn on a rect of height 15 at the beginning of the category. I understood at this point that this wasn’t enough. So, after looking at both screenshots I understood the category drawer should be able to draw everywhere on that category bounds (imagine if you want to draw a big folder on the bottom right part of the category ‘folders’ when sorting by type). Nowadays, on the new implementation, the category says: my height is 15 pixels. Then the view can do some operations to know the size of the whole block (say, 100 pixels height), and then when the category is asked to be drawn, it gets a 115 pixels height rect where it can draw. Of course is its own decision to only draw on the first 15 pixels if it wants so.

After so many talking, on a first approach of drawing and trying to get those mockups right, I have something like this:

Note that the alternate block coloring is not on the mockup, and probably will be removed, it was just for testing purposes.

Note also that this is not even on KDE subversion repository, and even when it gets to it, the way things are drawn can radically change if someone has objections and they are well based.

Please also note that screenshots are not very close to mockups in certain places. Just be patient, they will =)

I really love to see this on KDE SVN soon, since internally it got amazingly polite from my POV, what makes it really easier to maintain than the older view, and also to contain no hacks internally, what is very important.

If you feel like it, you can find all the work I am doing separately here for kdelibs, and here for kdebase.

Categories: KDE Development Tags:

QTreeView fixing rampage – KDirOperator

October 25th, 2008 ereslibre 1 comment

I have submitted 3 new reports to qt-bugs… One of them affecting bug 171436. This is a general bug that affects all applications (not only Amarok). Let’s go by parts on the submitted bugs to Trolltech:

  • Calling to selection() from the selection model contains duplicate ranges. Why ? This is easy: if you have a detailed view (or the tree detailed view), there are hidden columns (like owner, group and permissions). When there are hidden columns, the ranges are wrongly calculated (I proposed a fix). (selection mode ExtendedSelection)
  • When clicking down on the blank viewport and dragging for selecting several items you expect the rubberband to be drawn. It isn’t. (selection mode ExtendedSelection)
  • When you click on the blank viewport you expect the current selection to be cleared. It isn’t. (selection mode ExtendedSelection).

The cool thing is that for those three issues I a Qt example and adapted it a bit. So, those three issues can be experimented with the same test case.

Note: tomorrow I will move the proposed fix to qt-copy patches… now I have to leave =)

Categories: KDE Development Tags:

Intense hacking session – The ultimate screencast ! ;)

October 3rd, 2008 ereslibre 15 comments

So I decided to go for all the missing features of the Open/Save dialog, and everything is in SVN now. I have also added support for having filenames below icons or previews (as we had on kde3 too). I have been told several times about this lack of functionality.

Everything works like a charm in KFileWidget/KDirOperator. It is stunning fast and take in count the screencast has been recorded with everything compiled in debug mode (what makes it slightly slower, and sometimes, very slower), but still like a charm.

So, I have played around to show all the functionality of the new features and how to mix them.

Download the screencast here.

PS: I have tried to upload the video to vimeo, but it was hanging somehow. I have seen that I have to convert ogv since they don’t seem to support it. I am pretty tired today… so I will update this post tomorrow if I manage to upload the video on vimeo ;)

Categories: KDE Development Tags: