Saturday, August 27, 2005

Malaga, kdelibs, kregexp, and more!

Today is the first fun day here at Malaga and even though we were told to be here at 9 many didn't arrive till 9:30. Oh well, at least we showed up. As allready reported the network is capped. The keyboards are not American so as long as I don't look down I am ok :) Unfortunettly in the main room many of the computers network (i.e. icecream boxes) have been hijacked for the laptop users. Hopefully this will be resolved tomarrow. I have my laptop loaded with OS X Tiger so any KDE developers that want to check it out can stop by. At some point in the next few days (tomarrow evening?) I plan on having a meeting for those who want to work on KControl. So we don't leave anyone out if you are interested please let me know. (Trying to track down everyone manually right now)

Monday, August 22, 2005

Lessons Learned in Software Testing book review

Picked up "Lessons Learned in Software Testing" by Cem Kaner, James Bach, and Bret Pettichord. At Trolltech I have recently written some unit tests for some Qt classes and some code I have worked on so I thought it would be interesting to see what the book would have to say about testing. It is a fairly large book I couldn't quite figure out at first who it was suppose to be sold to. A developer? A manager? Support? Little of everything person? After reading about quarter way through the book I realized that this book is for those who are hired for the testing position, the full time tester. Once I figured that out then the book made a lot more sense.

The book covers covered a lot of interesting topics from a testers perspective.

-What is a tester
-How to write tests (testing techniques)
-How to write up reports
-How to deal with management
-How to deal with developers (and their weird behavior)
-Automation and automating your testing and when not to
-Unit Tests
-Managing testers
-Hiring testers
-Growing your career in Testing

I picked up the book hoping it would cover a lot of strategies for testing my code (being a big book and all). I got a few good ideas that I will use, but most of the book was not directly about code. On the other hand I got an interesting inside into a testers world. A lot of it a testers world deals with interacting with others and how to best do that. From not giving vp's hard numbers because then they will just want more to understanding that when you write a bug report you need to sell it to the developer to get them to want to fix it. Similar to the development world the book had tips about reusing code and techniques such as working in pairs. Overall I think this book was well written and covers all the topics of being a tester. If you are only looking for a book full of tips on how to write some tests for your code then you could probably find a smaller book that covers the same or a larger book that covers more. For a view into a world that in very similar to being a developer, I would recommend this book. If you are interested in spending more of your time (or all of it) testing, you will probably get a good deal out of this.

Thursday, August 18, 2005

KDE Auto Tests is live again

The computer that was running the automated tests for all of trunk and uploading them finally made its slow boat trip over to Norway. I ran it manually this morning, but starting tomarrow it will run nightly so you can watch any issues you fix dissappear. Head over to here and see what you find:

You can also bookmark you application like so:

For those who will not read the big read box at the top of the web page here it is again:

WARNING: These test scripts are not the most intelligent things and should only be used as guides for code to investigate! They might have false positives. Make sure you understand the problem that each script is looking for to be able to determine if the script is wrong. If any listed description or resolution is incorrect or you don't think has enough information please contact me.

Crossing The Chasm book review

Finished reading "Crossing the Chasm" by Geoffrey A. Moore. It was an interesting book about how to grow a company from its initial cool new product stage to selling to your average corporate middle manager. A good book that builds upon the fundamentals of the adoption life cycle. It concentrates on the change from early adopters to the early majority. This would be the opposite of "The Innovators Dilemma" which concentrated on when your technology reaches the laggard stage. I would have to say that this is a very good book for a lot of people. You could even apply it to many smaller Open source projects (assuming you want it to grow). You only have so many resources to grow your project with and as exciting as it is to try to do everything and port it everywhere it is much better to concentrate on a target audience and grow it from there.

Nothing was better then a little list of desired features in the book that shows just how different the two worlds are:

Early Adopters:
-Elegant architecture
-Unique functionality

Early Majority:
-Largest install base
-Most third party supporters
-De facto standard
-Cost of ownership
-Quality of support

It was a pretty easy read. So if you have a free evening I would recommend picking up this book.

Sunday, August 07, 2005

How I sold a million copies of my software... book review

Todays book review is: "How I sold a million copies of my software... and how you can, too!" By Herbert R. Kraft. I saw this in the Trolltech library and picked it up for some evening reading. This book presents an amusing look into making software from the pre internet boom. It was published in 1997 and so I can guess that it was written in 1996. Much of the book deals with how to get your software on the shelfs of retailers and all of the details surrounding that. What interested me in the book was the first chapter where there were a list of applications that you shouldn't write along with some reasoning behind each one. Unfortunately I didn't find much more in the book that was interesting once I read it. There was a chapter that talked about some basics that a professional application should have such as documentation and useful error messages. At the end of the chapter I felt let down. One chapter is hardly long enough to cover that topic. Another chapter talks about software management, design etc. Maybe the author felt that he needed to include these topics to be well rounded, but personally I think he would have been off recommending that that reader check out books such as "Code Complete" rather then giving such inadequate advice. There is a chapter about the internet, but due to the horrible timing of this book you can probably guess just how out of date this book is on that advice. Back then software really was mostly bought in stores and so the advice in the rest of the book probably applied, but these days I doubt that the rules still apply. Though-out the book I was trying to figure out the target audience of the book. My only guess can be the amateur programmer who has written a few small applications for their own use and thinks they can make a lot of money selling them at CompUSA. The one topic that should have been touched on more is how most applications wont be successful and how you need have more then one idea. Unfortunately the person who would buy this book is probably the type of person who has one sole application that they think everyone wants and will to try to sell. Because it is their first pro application they will be lucky to break even, wont have another app to sell, and have lost all their free time. This book takes an amusing perspective. It assumes that no matter how bad (or good) your software is you can make money if you play the market and retailers correctly. At the end of the day this book's main purpose really doesn't apply much anymore because of all the changes in the industry so I can't recommend it.

A few of the applications you shouldn't write:

Games: Most don't make anything
Childrens software: Other then "where in the world is carmen sandiago" very few games for children every are successfull financially
Programming tools: We all give them away, hard to compete
Office Suites: Is this even neccesary?
Screen Savers: Too many free ones
Word Processors: no explination needed

Thursday, August 04, 2005

The Design Of Everyday Things book review

I finished reading "The Design Of Everyday Things" By Donald A. Norman last night. Another short book (two evenings of reading). Throughout the course of the book the author shows product after product (in many cases, doors) that were designed horribly and thus confuse users when they attempted to operate them. This is typical of most user interface books, but unlike others throughout the book the author explains in the most well written manner I have read about why designers think their designs are self explanatory when they are just wrong. Most other books gloss over this fact hoping you will memorize their rules. Another idea which is much more prominently talked about in the book is the idea of blocking, or removing features from the users when the option wont do anything or cause harm. Even though computer GUI's aren't mentioned, many of the ideas presented can be quite easily mapped to computer gui's. Overall the book is well written and has a lot of good ideas and would recommend this book.

Nine things KDE should learn from OS X

Note: This article was written in 2005 and it is commenting on KDE3.

Two years ago I got the opportunity to get a Mac laptop for work. At the time what my job didn't require Linux, but just an Unix environment so I took advantage of the opportunity to learn more about OS X. The more I looked around the more that surprised I became. Yes I had things I don't like, but every day it seemed I was discovering some sort of killer feature that I hadn't seen in any Linux or Windows environment. Rather then loaning out my laptop for a few weeks to every KDE developer I thought I would write out some key things. If you have never truly played with OS X I would invite you see if you can barrow one for a week to expose yourself to it first hand or just visit an Apple store.

1) Users have an address book entry

The first time you log into OS X it asks you to fill in a form with your information. I figured it was for registration and just put in my name, selected and icon and then clicked that I didn't want it to be sent to Apple. I didn't think about it much until later when I started using iChat and noticed that it had used my icon and had my real name. Then when I opened the address book I found an address book entry for me with the information I had entered. The idea of using your addressbook entry everywhere might seem like a simple idea, but it is not one that has caught on in KDE.
  • Games shouldn't prompt you with a blank name dialog when you get a high score.

  • IRC/chat/aim/kopete should know your name, your nick name, and icon.

  • KMail should already know your name (and pgp key!) when setting up an account.

  • KDM shouldn't need to have a separate configure spot for the user icon.

  • If you update your user information it should update the system.

  • Digikam can mark each photo you download as taken by you.

  • KWord and the other office applications can mark that you edited/authored the file rather then a blank field.
You can probably think of more examples where having a users address book information would make for a better user experience in your application. I have suggested to a number of existing applications to try to use the addressbook entry if it exists the past year.

For KDE 4 I think that when a user first logs into KDE it should be prompted to make an adderessbook entry so that applications can take advantage of this information.

2) Single Toolbars

All through out OS X you will find that application typically only have one toolbar and the vast majority of the time there are around seven actions displayed with large icons and text underneath. Don't think it is possible? Lets take a very complicated application, a development IDE. On top is XCode and on the bottom is KDevelop after creating a project named "foo".

I figured there must be a some large set of rules in OS X for what should be in the toolbars. But when I looked it up in Apple's user interface guildlines Window Appearance section
and I found this: "Toolbars are useful for giving users immediate access to the most frequently used commands." So if you are making a media player just because you have the actions cut, copy and paste does not mean they should be in the toolbar, but Play, Pause and Next should be.

This particular issue has already been brought up several times on the kde mailinglists and for KDE 4 it is almost certain that this is going to be changing to follow this rule. You can set large icons with text by default in KControl today to see how your application will look. Right now the easiest thing to do is to remove non essential actions and to shorten the really long names. You might have noticed me doing this from time to time in applications. As a bonus you will find that you have less code, icons, etc to maintain.

3) Applications present simple default views

Compare the difference between OS X's addressbook on the left and KDE's on the right. A very common desire for addressbooks is the ability to create groups of friends, coworkers, etc. If you wanted to make a group of all of your coworkers in your addressbooks what would you do? In OS X's you just click add in the group box and then drag any entries over. In KDE's you have to edit each user, click on select categories and check the category they are in. To add a category from the same dialog click, edit categories, and after typing in the text then click Add. Of course in KDE I can't see any easy way to view all the users in one group. Editing a user is also simpler in OS X, you just click on edit and then the field you want to change, in KDE you have to click edit which brings up a five page dialog and find the field that you want to change. Probably worst of all is that most of the space in KDE's addressbook is taken up by a resource widget which to this day I still don't know what as a user I would do with it. This really should be part of the configure dialog as it is not something you do every day. One final thing: notice how my name in OS X's addressbook is highlighted with the little icon showing that it is "my addressbook", KDE's doesn't have that.

In fact the above OS X addressbook screenshot isn't even the default view! The default addressbook is what you see below:

When I first saw this I laughed at it because I thought this addressbook must not be able to do half of what KDE's can, but it can and in this view it was perfectly usable. You search for someone and their name pops up, click the "+" to add someone. Click the multi-column button for multiple views and you can add groups (and smart groups, aka searches). Adding an LDAP server is in the configure dialog just like in KAddressBook

Lets taking a look at another KDE application. The other day I loaded up Quanta so I could see what has changed sense I last used it. Notice how much of the window is actual productive space where you can work on your document. A quick list of actions presented to the user:
  • 13 different top menus!

  • 34 toolbar buttons in the primary toolbars

  • 5 left sidebar things

  • 2 bottom sidebar things

  • 2 right sidebar things

  • 6 tabs of toolbars on top of the edit window each with around 10 toolbar items

  • Tabs for each open file

Granted this isn't as bad as KDevelop, but still it feels like the developers tried to cram everything on the main screen to the point that I as a user have absolutely no idea where to look for things. I personally hate the idea of the sidebars and find it way to confusing, and to have them on every side of the screen is too much. Application do not need to present this much to the users on the default view and in many cases it is redundant. When I started clicking on buttons the entire screen started changing (as things showed and hid) and after ten minutes I gave up and quit.

This issue is different for each application. Typically the default configuration and view of open source application don't get much attention because the developers never have a clean install :) Hopefully developers will take a minute to look at their appliciation and make some large changes for the better.

4) Drag And Drop

Unlike the promises that Windows had and the lackluster support in Linux OS X really does have drag and drop support.

  • Installing most applications is not harder then dragging the application (folder) to where you want it to be

  • If you are viewing/editing a document it shows up in the caption bar as a little icon, just drag that icon to make a shortcut

  • Can't forget that to eject your CD you drag it to the Eject button (formally the trash)

  • I typically open files, import, and extract from application using drag and drop.

Part of the problem why Linux doesn't take advantage of drag and drop as much is that we developers have a right mouse button. Simple things such as selecting, right clicking and choosing and action you don't do in OS X because you can just drag the objects around. Because we have a right click we don't get around to implementing the drag and drop. The problem comes when there are options in the right click menu that arn't anywhere else. It would be better to think of the right click menu as a toolbar, and use the rules that apply.

For akadamy it might be fun to go out and buy a bunch of single button mice and put them on every computer and see how the developers fair and discover what actions are impossible with a single button mouse.

5) Integration

Closely related to drag and drop is desktop integration. Beyond the fact that every application uses ctrl-q to quit I am talking about:

  • Utilizing the addressbook to get the current users information.

  • Playing a song/playlist from the media player in the photo album application when doing a slideshow.

  • A photos screensaver uses your photo application to select an album.

  • A screensaver that uses album covers.

These are just a few things that I have seen in OS X. When writing your application think about how it can be utilized elsewhere on the desktop. For example digikam could also include a screensaver in its source tree. In Tiger OS X took this to the next level with Automator. A small application that lets you build scripts in a gui environment. A wonderfull example was a script that got all new mail and put them on your ipod. Providing ways for other applications to hook into your is important. Unfortunately querying applications just isn't implemented. For example I can not query kmail for all unread mail or kaddressbook for users in my family group. This might be fantastic project for someone to start for KDE4.

If an application can be converted to a web application (hint: KColorEdit, KTuberling (Potato Guy), KDict) without any loss of functionality then either that application really should be a web application, kpanel applet, or it should be improved to take advantage of KDE better.

6) The Window Manager has planes

Application such as Photoshop or Qt Designer 4 display a number of windows up on the screen at the same time. After launching them in KDE if I brought KMail on top I would have to then manually bring each Designer window up top. In OS X clicking on one window will bring every window in that application to the top. I wrote a small patch for kwin so that KWin will behave this way. Although simple it is quite amazing when used.

I hope to get this in KWin for KDE4 as a configure option. Perhaps the default?

7) Application Folders

Unless you have been living under a rock you already know that applications distributed in OS X can just be folders with a .app extension. I have seen a number of small projects start to enhance the file ioslave to give it this capabilities, but nothing has really come out of it. Someone should take the time to add the support officially to KDE. At the bare minimum written in Python (or javascript, bash/kdialog, ruby, etc) would be able to work and developers could even release KDE applications. That would create a fantastic little sub community that could easy pass around their applications. Users would just love this feature. I have written a small script which will generate app folders of all of the existing KDE applications (those that have .desktop files) for the KDE-darwin project which can be fun to play around with.

8) A Common Viewer

Apple includes an application called "Preview". In essence it does something very similar to Konqueror. It can open any file that I give it. It doesn't let you edit it, but simply view it. It is a small application that can view images, pdfs, but not html, Safari is used for that. For KDE 4.0 Konqueror should be split into three different application. A web browser (Konqueror), a viewer (Viewer) and a File Browser (Browser, ok you can come up with a better name). The backend for these three different applications might be very similar, but their user interfaces should be different so that they can best serve users.

With this viewer then KDE wouldn't need to have all these separate applications:

  • Fax Viewer (KFax)

  • KView

  • KGhostView

  • KPDF

  • KDVI

Update: recently a new project was started to do just this: Okular

Heck you could really remove most of KDE Graphics for this one application. Which brings us to the next section.

9) The number of core applications

When you first use OS X you might be a little annoyed that there isn't a Start Menu (or equivalent) to let you explore the list of all installed applications. Part of the reason is because in Finder when you click on Applications there are around only twenty application installed. Combined with twenty more in the Utilities Folder. This might not blow your mind until you start to count how many there are in KDE and we don't even provide all of the same functionality (no DVD player, Automator, Dictionary and manu of the utilities). Ok yes they only include one game, an opengl chess game, but still the numbers don't look good. There is a lot of duplication in KDE that can be trimmed down.

  • KEdit should have been removed long ago.

  • CD playing and ripping should be in Juk or [insert your favorite music player].

  • Adding the above KViewer will "remove" a lot of applications.

  • Konversation, KOpete, KSirc, only one is needed.

  • KAppfinder really shouldn't exist at all, applications should have a desktop file and if not a bug should be opened against them.

  • kget shouldn't be listed as an application, but just something that shows up from within Konqueror.

On the personal side I am working on improving audiocd so that it can be very easily intigrated into Juk or any other application and when that is done i'll move KAudioCreator either to kdeextragear or to my own person website for archive purposes depending upon demand.

10) Where is number 10?

I didn't want to mention the panel or the file browser to much because there are already efforts underway with Plasma and some thoughts on Konqueror. Because these two are so heated and quickly take over any sane topic those two could easily overwhelm any feedback from this article. When discussing this article please refrain from branching too much into them. There will be many discusions on them at akadamy.

Hopefully you have learned some new things about OS X. I know that most Linux developers come from the Windows world so you know exactly what you are completing against there, but take the time to check out your competition on the OS X side. Not just from Apple. For example I recently downloaded the application "Colloquy" which is a third party IRC client. After using it for a few minutes my impressions were that it was a better application that anything that we had. You might find that in OS X they are doing something you have never seen in Windows or Linux.

Popular Posts