Showing posts with label en. Show all posts
Showing posts with label en. Show all posts

Wednesday, May 12, 2010

Plasma Applet Development Walk-through

 

Episode 2: Qt Creator Steps In

Preface

This article opens (yes, with episode 2) a series of mini-howtos describing various actions related to the development of custom plasma (KDE4 desktop) components (applets/data engines) in C++. Some of the information presented could be found elsewhere; other bits are almost trivial. If you are a programmer new to KDE4 development as I am, these articles may be of some help. The main idea is to show how purely technical stuff could be accomplished in some reasonable way without heavy thinking and head-scratching. Developer should focus on the stuff that is essential for his/her project: architecture, code structure, usability, documentation etc.

I am currently using Ubuntu Lucid (10.04) distribution with KDE 4.4 and Qt Creator 1.3.1; I believe my description should need only minor modifications if any at all for other distros.

Choosing the destination

We have our plasmoid project initialized and populated with .desktop, .cpp, and CmakeLists.txt files. Now is the time for compile-run-modify interactive development cycle.

Monday, January 11, 2010

Plasma applet development: adding icons micro-HOWTO

The introduction to Plasma applet development on the KDE TechBase site describes the contents of CMakeLists.txt file used for compilation  and installation of a plasmoid. The installation of corresponding icon(s) is not covered there.

Actually, the process is rather simple

  1. Create an icon, or an icon set
  2. Name icon file(s) correctly
  3. Add an icon reference to the .desktop file
  4. Put an installation line to CMakeLists.txt
  5. Run cmake && make && sudo make install

Tuesday, January 5, 2010

Inside Ruby 1.9 interpreter: Threading in Ruby 1.9.1

Ruby 1.9 implements Thread objects with native OS threads. There is always a native thread allocated behind the scenes when an instance of Thread class appears in Ruby program. But there is a twist: actually at most one Ruby thread is allowed to run at any given time during program execution.
Ruby multi-threading programs will not gain real advantage when executed on multi-core CPUs.