We have just recently started to use Kanboard, but still not sure how to apply our projects in the Kanboard system. We have a couple of major software projects contains sub-projects such as Delphi components, Lazarus components, Windows version, Linux version, Innosetup maker, documentation, etc. We would like to know how to initially create the structure of the projects/swimlanes/categories in the Kanboard to start using it. Could anyone explain the usage of and the difference between swimlane and category in Kanboard? How should we fit the mentioned sub-projects in a project, swimlane or category?
I would recommend you make separate boards for the independent projects unless the same team is working on all the parts simultaneously, which doesn't make much sense to me based on your short post. If you are using the same board, then color code the different parts. If you are using an electronic board, then you can use tags or labels.
Your swim-lanes must not represent components but your progress towards output of value. Its all about staying lean and mean when using Kanban and minimizing waste, which includes spending a lot of time writing the requirements and categorizing them. Instead, let your Product Owner (Service Request Manager) move things between the swim-lanes based on the business needs and priorities.
Your swim lanes could be something like:
Ideas | Ready for Development | In Progress | In Test | In Staging | In Production
In any case, it sounds to me that there is a signifiant misunderstanding of Agile and Kanban so I strongly recommend you spend more time reading or hire a qualified coach. Kanban isn't something you switch on and get results. You don't need a "Kanban Board" to be agile or to follow Kanban. I would argue they can do more harm than good for new teams.
Moving to agile is tough, especially since many educational institutes around world talk about SDLC and Waterfall when they discuss project management. Agile is a completely different paradigm, almost an opposite paradigm, to the traditional prescriptive paradigm of software development.