There are lots of reasons to using C++’s bit field feature. Perhaps you need a more compact way to represent your data structures, maybe you need to use them interact with hardware, or if you’re writing an emulator, maybe you want to use them to efficiently represent the hardware that you’re emulating. The list goes on…
Most of the time, it makes the most sense for our dialogs to be designed with layouts such that it looks good with just about any width or height. But there are a few cases where locking in the size makes sense. The most classic example I can think of is an “about this application” dialog box.
When you are editing a dialog window in the Qt designer, there is a
sizePolicy property which among other things can be set to
Fixed. And while you may assume like I did that this would create a fixed sized dialog, sadly, this is not the property we’re looking for.
Fortunately it’s a one liner to get the behavior we want, so I figure I’d share my findings :-).
We can simply add the following to the constructor of
our dialog class after the call to
This will make the dialog non-resizable. I would have expected that a
Fixed size policy to make our dialogs fixed size. Unfortunately, this doesn’t seem to be the case. For a while I had hoped to find a solution would could be implemented in the designer itself, but to no avail.
A few years ago, I was asked to add “theme” to a Qt project of mine. I wasn’t fully aware of the power of Qt’s style system, so I did it the hard way. I created a configuration file which contained the theme-able attributes of just about everything I could think of. And when the application started, I parsed it, and applied the colors, fonts, etc. After a short bit, I noticed things I had overlooked and added them. It wasn’t amazingly hard, but it sure could have been easier. Today I’d like to discuss the easy way :-).
As developers, we all have an editor of choice. We all have one that we consider to be “perfect for our way of working” and no others will do. Sure, in a bind we can make do with alternatives, but they never seem to “feel” right. For me, this editor is nedit. I guess it’s because it was the graphical editor suggested by my professor in school. But I often feel crippled when I have to use something else. Unfortunately, nedit is showing its age. It was made in a time before Unicode was even a concept, using a widget toolkit that has simply not kept up with the times.
Sadly the developers do not seem to be working on it anymore, the last update was version 5.5 in 2004, nearly a decade ago :-(. Often I am still able to make use of nedit on my Linux install, but I’d love to see a spiritual successor developed using a modern toolkit. I’ve looked, nothing quite fits the bill. gedit comes close, but I find its keyboard bindings awkward and it is completely lacking some advanced features such as regular expression based search and replace, and rectangular selection. So I’ve decided in my spare time time to try to develop an editor using Qt, that is a work-alike for nedit and a spiritual successor. For now, the working title is “nedit2“. I make no promises on timeline, but I plan to do my best to create modern maintainable code resulting in an editor that any nedit user will feel comfortable using.
So why I am talking so much and not showing code yet? Well, this task is all about the details. In my initial tests I encountered something which was driving me a bit batty, and I wanted to share with you my findings :-).
Qt has a wonderful way of dealing with memory management. The core idea is simple. Most objects have a parent, and when the parent gets destroyed, it will first destroy all its children. Using this technique, you can often write your Qt applications with little to no concern for memory management. Often, you literally don’t have to have a single
delete in your entire application. That’s pretty sweet!
In addition, since Qt 4.5
QSharedPointer was introduced, which is very similar in concept to
boost::shared_ptr (and thus
std::tr1::shared_ptr). I have long been a huge fan of the idea of smart pointers. They solve the need to worry about memory management for almost all usual cases. Unfortunately, when you combine these two concepts, sometimes you can go awry. I was surprised by this one, so I figured I’d shared my findings :-).
Qt is a fantastically designed library. However, every now and then I think of something that I wish they offered that they don’t. It’s almost always something small and easily worked around, but it would be nice if it were just there. This time around, that feature is the ability to connect a signal to a function which is not a member of a class/struct. Specifically, I think it would be really cool if I could connect it to a c++0x lambda! Especially now that the ISO C++ committee approved the C++0x final draft.
The GNU Multiple Precision Arithmetic Library (GMP) is a wonderful library. It offers arbitrary precision math in a relatively simple, easy to use package. It is currently used in kcalc as the core for all basic math operations. The only problem is, the error handling it offers, is broken by design.
The concept of a default browser on linux is a complete mess. There doesn’t seem to be any central, agreed upon method of defining what the default browser is. First there is the
$BROWSER environment variable. This seems like a good idea, it can be set globally, and on a per user basis. On the command line, all you need to do is type
$BROWSER http://... and you on your way to the website of your choice. If only it were that easy…
I recently submitted a bug report to Qt software, the results were less than impressive. One thing I’d like to make clear though is that Qt is an amazing library that I would recommend to any c++ software developer, I truly mean that. It is well designed, well documented and generally works as advertised. On top of all of this, it is portable! It really just gets better and better. Which is why I found the handling of my bug report so… underwhelming.
Pretty much all of the popular browsers now support a “private browsing” mode. The whole concept of this mode is to prevent any history of your browsing activities from being recorded. The problem is that there is nothing forcing browser extensions to respect this mode of operation.