Stupid Application

Let's start with some boil­er­plate code: A main script that opens a win­dow.

As you can see, all this does is open a win­dow, lit­er­al­ly. And it as­sumes there is an­oth­er mod­ule, called win­dow.py, con­tain­ing a Win­dow class.

Well, that's boil­er­plate al­so (and very sim­ple one, too):

So, we have a pro­gram that, when called, dis­plays a blank wid­get. When you close that wid­get, it dies. Not too in­ter­est­ing, that one.

So, let's make it do some trick­s.

Choosing the Widget

It turns out Qt has a wid­get called QI­con­View, de­scribed in the man­u­al as:

A QIconView can display and manage a grid or other 2D layout of labelled icons. Each labelled icon is a QIconViewItem. Items (QIconViewItems) can be added or deleted at any time; items can be moved within the QIconView. Single or multiple items can be selected. Items can be renamed in-place. QIconView also supports drag and drop.

Looks like a file man­ag­er to me. So, we change our Win­dow to in­her­it from QI­con­View.

Now, that's an un­in­ter­est­ing white win­dow ;-)

Of course, to make it use­ful, we need to be able to fill it with the con­tents of a fold­er.

Well, let's add an ar­gu­ment to the con­struc­tor, called fold­er, that is the fold­er that should be dis­played, and add a method, called change­Fold­er, that fills the QI­con­View with the con­tens of that fold­er.

It­er­at­ing over the con­tents of a fold­er in Python is easy enough, us­ing the os mod­ule. Adding icons to a QI­con­View is most­ly a mat­ter of cre­at­ing a bunch of QI­con­ViewItem­s.

Now, this is some­what bet­ter :-)

That the icon seems right for what is there is just a co­in­ci­dence.

So, let's use two icon­s, one called "fold­er" and the oth­er called "file", and stat the con­tents of the fold­er, as­sign­ing the right icon­s.

It re­al­ly shoud have a bet­ter cap­tion, re­flect­ing what you are see­ing in the win­dow, too.

Break

Times­tam­p: 29/05/04 16:20

Turns out I don't have the python docs in­stalled here. Nev­er pro­gram Python with­out the li­brary ref­er­ence at hand. So, I'm build­ing them now (I had the TeX sources in­side the Python sources). Should on­ly take a few min­utes

I would nor­mal­ly just use the ver­sion at www.python.org, but this is at home, with­out In­ter­net.

Times­tam­p: 29/05/04 17:00

The rea­son I need the li­brary ref­er­ence is that I don't re­mem­ber what the val­ues re­turned by os­.s­tat() mean.

Turns out what I want­ed was not os­.s­tat(), but os­.­path.is­dir() and com­pa­ny. See why the li­brary ref­er­ence is your friend? ;-)

I have vis­i­tors. Be back lat­er.

Times­tam­p: 29/05/04 17:05 Times­tam­p: 29/05/04 19:25

So this is how the Win­dow class looks now:

It's ba­si­cal­ly the same, ex­cept that now, when I cre­ate the QI­con­ViewItem­s, we try (fee­bly) to use the right kind of icon.

And it looks a lit­tle bet­ter now:

No­tice how it us­es dif­fer­ent icon­s. It turns out you can even move the icons around, too :-)

So, right now, I think I am close to the first mile­stone (cre­at­ing a wid­get that can show a fold­er). Of course, it's not a good wid­get, but it has po­ten­tial.

Some of the prob­lems with the cur­rent code, like load­ing the right icon, will be solved when this is turned in­to a PyKDE app lat­er.

The sec­ond mile­stone was "make it con­fig­urable". Well, let's.

Showing (or not) hidden files

Let's add an­oth­er ar­gu­ment to change­Fold­er, called showHid­den, de­fault­ing to false. Then ig­nore (or not) hid­den files in the loop over os­.list­dir().

Should be sim­ple. I will not hide ".." be­cause it is the nat­u­ral way to go up.

Times­tam­p: 29/05/04 19:40

Here is change­Fold­er ig­nor­ing (or not) hid­den files. Do you no­tice how each thing I do is a 5, maybe 10 line change? I like to pro­gram in very small in­cre­ments. But that's just per­son­al pref­er­ence.

Now, I want this to fol­low, as far as I know about it, the dog­ma of spa­tial file man­age­men­t, so a set­ting such as showHid­den should be stored and re­mem­bered.

It should al­so, of course, be pos­si­ble to change, and to be changed on a per-­fold­er ba­sis.

So, what UI should the us­er have to change this stuff: I like di­rect ma­nip­u­la­tion of ob­ject­s, which in this case prob­a­bly means a RMB pop­up on the fold­er it­self.

So, let's add that menu, and make "Show Hid­den" a tog­gle in it. The right way is to cre­ate an ac­tion and stuff.

In the Win­dow con­struc­tor, we add a chunk of code to cre­ate the showHid­de­n­Ac­tion, which will be a tog­gle. Al­so, we cre­ate a pop­up menu, and put the ac­tion in it.

As you can see, ac­tions are pret­ty damn sim­ple. Now, we need to con­nect the ac­tion to a slot that tog­gles the dis­play, and make the pop­up menu show on right-but­ton-click.

To make the pop­up ... well, pop up, we need to con­nect the right­But­tonClicked() sig­nal of the QI­con­View, and con­nect it to a slot that pops the menu.

This is the slot we add to the Win­dow class:

As you can see, there is a glar­ing lack of func­tion­al­i­ty. But that's ok, we are just build­ing up stuff here, the holes can be filled lat­er.

To con­nect the sig­nal to this slot, we add this line to Win­dow.__init__ :

And lo and be­hold, we have a con­text menu, and it has a tog­gle say­ing "Show Hid­den Files". Now, we have to make it show (or not) ac­cord­ing to the tog­gle.

Sim­ple: we add a mem­ber called showHid­den to the Win­dow class, re­move the showHid­den ar­gu­ment from change­Fold­er, and make it use the vari­able. Then, we add an ac­ces­sor called set­ShowHid­den which tog­gles and re­dis­plays. And we con­nect that to showHid­de­n­Ac­tion.

Al­so, I re­named change­Fold­er to set­Fold­er, to be a bit con­sis­ten­t.

Here's the new win­dow.py:

The app looks ex­act­ly the same, al­though it has a lit­tle func­tion­al­i­ty ex­tra, so no screen­shot for you! ;-)

Times­tam­p: 29/05/04 20:15

Now, let's see how it looks with a back­ground pixmap. There is a set­Palet­te­Back­ground­Pixmap() method, so it should­n't be hard...

I say it looks good:

Again, I cre­ate an ac­tion, called set­Back­groundAc­tion, con­nect it to a slot called set­Back­ground­Slot, and slap it on the con­text menu:

The ac­tion and the con­nec­tion (for Win­dow.__init__):

The slot:

Ok, that is get­ting bor­ing. So let's just say it is con­fig­urable enough for a while, OK?

And then we are at a new mile­stone. We made it con­fig­urable , now we must make it con­fig­urable per-­fold­er. That should be a bit trick­i­er.

The context popup

I hooked the pop­up to the right­But­tonClicked sig­nal. It turns out that it's a bet­ter idea to hook con­textMenuRe­quest­ed, be­cause it will be more portable, and prob­a­bly will han­dle things like call­ing the con­text menu us­ing the key­board.

Triv­ial to change, just switch the sig­nals on the con­nect cal­l.

The opening of items

I hooked it to the clicked sig­nal. That sucks be­cause it means you can't ev­er se­lect any­thing. Which for the next mile­stone will be nec­es­sary. If I want it to act like KDE in sin­gle-click mod­e, I will have to check if the us­er has ctrl or shift pressed while click­ing.

That is some­what hard. So for now, re­luc­tant­ly, I will switch it to dou­bleClicked, so clicked will just se­lec­t.

The .. folder

os­.list­dir does­n't in­clude ".." by de­fault. So what, I'll just add it ;-)

The error reporting

Right now, when some­thing hap­pen­s, it prints the er­ror mes­sages (ex­cep­tion­s, what­ev­er) on stder­r. So, you won't see any­thing, un­less you are run­ning be­to from a ter­mi­nal. This is im­por­tant be­cause it hap­pen­s, for ex­am­ple, if you open a fold­er that you can't en­ter or read.

There is a some­what dirty gener­ic so­lu­tion for this, which I have used in the past. I can do this for ev­ery method where I sus­pect ex­cep­tions may be thrown by re­al life. Or, to be neat, on ev­ery method ;-)

First, I cre­ate a Er­ror­Dia­log class, us­ing de­sign­er. This is how it look­s:

Then wrap the method in stuff like this, grab­bing the ex­cep­tion data:

And this is show­Er­ror:

And presto, the us­er can see the ex­cep­tion­s. Of course a re­al er­ror mes­sage should be cre­at­ed for the stuff that hap­pen­s, but this lets you see where you should cre­ate them :-)

And here is the er­ror han­dling in ac­tion:

Normalizing paths

If you are in /fold­er and choose .., you get /fold­er/.. which is of course, not the same as / lit­er­al­ly, but it is in re­al­i­ty. So, the path should be nor­mal­ized, so that you don't open the fold­er twice (I in­sist, don't ask me why). But of course python has os­.­path.ab­spath() which is ex­act­ly what I need.

More item positioning problems

When you change some set­tings (right now, showHid­den), it calls set­Fold­er(). Since the win­dow is al­ready dis­played, and set­Fold­er clears the icons and reloads them, it is still nec­es­sary to move the items around as they are cre­at­ed. So, some stuff I had delet­ed, had to get back in set­Fold­er.

Al­so, since set­Fold­er reloads the set­tings, which con­tain the po­si­tion­s, it is pos­si­ble to do this:

• move stuff around
• change showHid­den
• it reloads po­si­tions
• clears
• recre­ates item­s... and for­gets the stuff you moved at the be­gin­ning.

To solve this, I moved the po­si­tion-mem­o­riz­ing log­ic in­to saveSet­tings, and made sure saveSet­tings is called be­fore call­ing set­Fold­er. Prob­a­bly would make sense to call saveSet­tings at the beg­gin­ing in­side set­Fold­er, in­stead.

Al­so, make the QI­con­View not au­toAr­range.

ShowHidden initial state

Sil­ly bug: the tog­gle should match the state of the set­ting. So, set it when set­tings load.

The new item problem

When a new item ap­pears for some rea­son, ar­rangeIt­em­s­In­Grid will lay it just fine. But... then we move all the old items in­to the old grid po­si­tion! So, we step all over it. In fac­t, it gets worse: be­cause of a bug­fix de­scribed be­fore, which re­quired dis­abling au­toAr­range, ev­ery­thing ap­pears piled on the top-left cor­ner.

Here's all I came up with, but I don't quite like it. If some item has a known po­si­tion, then I put them there.

All the items with­out known po­si­tions go be­low that fol­low­ing a grid. Hope­ful­ly ;-)

I al­so changed how things align. For some rea­son, even when us­ing a grid, Qt aligns the texts, but not the icon­s?

It's far from per­fec­t. But at least items don't over­lap by ac­ci­den­t, even if they have very long names.

The code to do this is at the bot­tom of set­Fold­er in the next list­ing. It ain't pret­ty. And it's way too sim­plis­tic.

A Featurette

If you try to open some­thing al­ready ex­ist­ing, it will rise. It's just a one­lin­er in open­Item­Slot