Posts Tagged ‘kdevelop’

kDevelop 4.2 Debugging

November 7th, 2011 No comments
    When I was using KDevelop 4.2 for debugging a process, I got perplexed having the inferior application closing down whenever I was setting a breakpoint on the fly.  On the contrary, the breakpoints there were setup before the start of the inferior application, things behave as expected.  With little bit of digging, it is found that whenever a new breakpoint is setup or removed (Toggle Breakpoint), kDevelop inherently issues a SIGINT to the inferior application, which in turn stops the application from debugging.  To handle this problem, setup a signal handler for SIGINT, to consume the Interrupt signal (Ctrl+C, Ctrl+Break).  But once the debugging is over, don’t forget to reset the SIGINT handler.

kDevelop Editing Freezes Problem

August 20th, 2011 No comments
While working with KDevelop 4.2, I was quite disturbed by suddenly freezing of editing window. In the sense, the opening file is uneditable, “find” strings does not work and literally kDevelop becomes unusable. I had to restart kDevelop 4.2 to resume editing the code. I believed that kDevelop is going into Vi mode and was trying to undo that. But that’s not the problem.

When kDevelop loses focus, somehow the editing capability is disabled temporarily. When you switch context a couple of time by Alt-Tab and land is kDevelop again, the editing capability is resumed. I don’t know whether this is a bug, but context-switching has been my breather for now.

Converting KDevelop3 project to KDevelop4

June 15th, 2011 1 comment
    KDevelop4 has adopted CMake build system over AutoMake build system of KDevelop3. So, projects that are hosted on KDevelop3 environment cannot work seamlessly on KDevelop4 environment, which makes is practically impossible to migrate to KDevelop4 which is far superior in terms of functionality and usability.  Moreover, all latest Ubuntu flavors (Linux Mint 10 x64) give KDevelop4 as the default IDE under KDE.

    CMake is more powerful build system than Automake.  A very nice comparison of CMake and Autotools is found here.  The reason for KDevelop moving over to CMake is described in this article.  CMake also provides some scripts that help one to migrate the KDevelop3 projects to KDevelop4 CMake projects.  Once such script is am2cmake, which is written in Ruby.  If you run this script from the root directory of the KDevelop3 projects folder, the ruby script automatically reads and traverses through the directory to convert to CMakeLists.txt.  But there is a small bug in that.  While running the script on StaticLib directory, one might get the following error message:

converting PROBLEM: target not found:  libanalyzer_server_a_SOURCES = Admin.cpp Admin.hpp AnalyzerC.cpp AnalyzerC.h     AnalyzerS.cpp AnalyzerS.h CmdInfo.cpp CmdInfo.hpp Config.cpp Config.hpp     Manager.cpp Manager.hpp ModelTask.cpp ModelTask.hpp

The original that was converted is:

INCLUDES = -I$(top_srcdir)/config -I$(top_srcdir)/idls -I$(top_srcdir)/libs \
    -I$(top_srcdir)/libs/bgtLicensing -I$(top_srcdir)/libs/hmm -I$(STL_ROOT)/stlport -I$(DEV_ROOT)/idls/src \
    -I$(TAO_ROOT)/orbsvcs/orbsvcs -I$(TAO_ROOT)/orbsvcs -I$(TAO_ROOT) -I$(ACE_ROOT)
lib_LIBRARIES = libanalyzer_server.a
libanalyzer_server_a_SOURCES = Admin.cpp Admin.hpp AnalyzerC.cpp AnalyzerC.h\
    AnalyzerS.cpp AnalyzerS.h CmdInfo.cpp CmdInfo.hpp Config.cpp Config.hpp\
    Manager.cpp Manager.hpp ModelTask.cpp ModelTask.hpp

Basically, while translating the Makefiles for static libs, am2cmake script does not know how to extract the target name from the Makefile.  By applying the below patch the problem was fixed.  Basically, a rule is added to addTarget function to handle lib_LIBRARIES = line from

>       elsif line =~ /^\s*lib_LIBRARIES\s*=\s*(\S+.*)/
>          targets=$1
>          type=StaticLib

[Updated 04/07/2011: A more or less completed script is available here for converting non KDE projects, which should transform all the projects from kdev3  (native c++ projects that are non-kde) to CMakeLists.txt format. Use ruby am2cmake.rb –no-kde to run the script.]

Developing GUI Applications in C++ with wxWidgets

July 17th, 2008 No comments

Who said C++ cannot be used for Rapid
Application Development (RAD) ? There are many GUI frameworks for C++,
which are even portable across Unix, Windows and others. One such
framework is wxWidgets.

wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more using one codebase. It can be used from languages such as C++, Python, Perl, and C#/.NET. Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform’s own native controls rather than emulating them. It’s also extensive, free, open-source, and mature.

is not just a GUI framework. It provides native support for threads,
sockets, database connectivity, synchronization and what else. Qt also
provides such support, but I like wxWidgets for its simplicity is
programming use.

There is a RAD development tool called wx-devcpp
hosted at sourceforge, which helps faster creation of Frames, Controls,
Dialogs and more. wx-devcpp has support for Visual Studio 2005
compilation as well along with MinGW compilation in Windows. I use
wx-devcpp for forms creations and import the generated source to VS6.0
in Windows and KDevelop in my Fedora 7. The surprise is, the code
compiles with very minimal changes from VS6.0 to KDevelop environment.
I have used wxWidgets with STLport 5.1 for my development purposes.