wxWidgets: memory of a month(+list of complaints)

Recently, with some motivation, I left Qt and used wxWidgets for a while. I used Code::Blocks, applied Bind<>(), and so on. I enjoyed the coding, but eventually I returned to Qt. During the time, I experienced......:

• If the application is frozen, task switcher doesn't work at all, whatever it is - Alt-Tab, Windows-Tab, taskbar click..... Nothing works. This is first time I've ever seen something like this
•  You need some time to be accustomed to properly use wxDateTime. On calculation you use wxDateSpan, and its structure is confusing
• In wxGrid, if you have too many rows ans set the layout side to 1 or higher, the grid wraps the entire window(......). The widget seems to calculate its size based on the sum of column widths and row heights. It must be a bug
• Unicode adoption seems not working properly. I converted interface strings to UTF-8 using wxConvUtf8 and tried to put the string via SOCI, and Firebird complained whenever the string has some Chinese characters
• It seems to be due to Windows control itself, but it's too slow. The fame of GDI is not void.

And above all, Code::Blocks broke down from time to time, and well, just guess what it would feel like if you experience all above.
For your reference, my development environment was as follows:

• wxWidgets 3.1
• MinGW-w64 6.3.0 release 1
• Code::Blocks rev10922(built at Nov. 20th. 2016)

Now I'm back to Qt, and I'm porting all my wxWidgets apps to Qt now. The apps are faster, and it's more convenient. Viola!

wxWidgets: 한 달간의 추억(+투덜투덜 목록)

근저 약간의 계기로 Qt를 버리고 한동안 wxWidgets를 사용했더랬습니다. Code::Blocks를 사용하고, Bind<>()도 좀 쓰고, 뭐 기타등등 그랬습니다. 한동안 꽤 즐겁게 코딩을 했는데, 결국에는 Qt로 돌아오게 되더군요. 그러니까 그동안 무슨 일을 겪었는가 하니......

• 프로그램이 freezing 상태가 되면 task switcher가 동작하지 않습니다. Alt-Tab이고 Windows-Tab이고 작업표시줄 클릭이고 뭐고간에 하나도 동작하지 않아요. 시스템이 통째로 얼어버리는건 처음 봤습니다
• wxDateTime은 익숙해지는데 시간이 꽤 오래 걸립니다. 연산에 wxDateSpan이라는 별도의 클래스를 사용하는데, 이게 구조가 좀 그렇더군요.
• wxGrid의 열의 갯수가 너무 많은 상태에서 layout 크기를 1보다 크게 잡으면 grid가 창 전체를 뒤덮어버립니다(......). 아무래도 widget의 크기를 widget의 기본 크기가 아니라 내부 행/열의 크기의 합계로 계산하는 것 같습니다. 아무리 봐도 버그인데요. -_-
• 유니코드 제어가 완전하지 않은 것 같습니다. wxConvUtf8으로 인터페이스의 글자를 UTF-8으로 변환한 뒤 SOCI를 통해 UTF-8 DB에 넣으려고 해봤는데, 글자에 한문만 들어가면 Firebird가 잘못된 글자라면서 오류를 뱉어내더군요
• 이건 Windows 컨트롤의 한계인 것 같은데, 컨트롤이 꽤 느립니다. GDI의 명성은 헛된 것이 아니었어요. -_-

여기에 Code::Blocks의 툭하면 죽는 현상까지 가세하니 대략 난감하더군요(-_-).

참고로 개발환경은 아래와 같습니다.

• wxWidgets 3.1
• MinGW-w64 6.3.0 release 1
• Code::Blocks rev10922(2016년 11월 20일 빌드)

참고로 지금은 Qt로 돌아왔고, wxWidgets로 만들었던 프로그램도 모두 Qt로 porting하고 있습니다. 속도도 빨라지고 위에 이야기했던 불편함도 없고...... 훨씬 쾌적하네요. Viola!

QSqlQuery vs. SOCI: inserting 1000 times

Recently I'm using QtWebApp to develop an application, and I did some performance benchmark to select a database library in the backend.  I selected QSqlQuery and SOCI as candidates, and tried to insert 10,000 rows at once. The result is as follows:

• Repeating single query
• QSqlQuery: 10000ms
• SOCI: 2500ms
• Prepared statement
•  QSqlQuery: 7000ms
• SOCI: 750ms(?!)

In any situation, SOCI takes far less time than QSqlQuery. QSqlQuery seems to be really a bad choice for server applications. I suspect the bottleneck is the loooooong processing time for QString.

QSqlQuery vs. SOCI: 1000회 연속 insert

최근 QtWebApp을 기반으로 프로그램을 개발하고 있는 바, backend에서 사용할 DB 라이브러리를 써보려고 성능 테스트 비슷한걸 해봤습니다. 후보로는 QSqlQuery와 SOCI를 선택했고, 연속으로 10,000회 insert를 시도했습니다. 결과는 아래와 같습니다:

• 단일 쿼리 반복
• QSqlQuery: 10000ms
• SOCI: 2500ms
• Prepared statement
• QSqlQuery: 7000ms
• SOCI: 750ms(?!)

어떤 상황에서든, SOCI가 QSqlQuery를 훨씬 뛰어넘는 처리속력을  보여주고 있습니다. 아무래도 QSqlQuery는 서버 상황에서는 썩 좋은 선택은 아닌 것 같습니다. 아무래도 쿼리를 구성하는데 사용되는 QString 특유의 비대함(?)이 문제가 아닐까 하는 생각이 드네요.

Recent trends in inflight entertainment system development

Recently I had some chance to use a lot of airlines, and I found some airlines have inflight entertainment system with quite remarkable user interface/experience. I tried to find out who was behind, and all of them were found to be developed by Panasonic Avionics. And what? The company is one of the protagonists in "customer success stories" from Qt Company.

Man, in the world of C++, Qt becomes the de facto standard.

최근의 inflight entertainment system 개발동향(?)

근저 비행기를 많이 타봤기에, 몇몇 항공사의 간지나는 인터페이스를 가진 inflight entertainment system들을 좀 수소문해봤더니 개발사가 모두 Panasonic Avionics더군요. 그리고 Panasonic Avionics는 Qt의 가장 대표적인 customer success story입니다.

......C++의 세계에서 대세는 역시 Qt인가 봅니다.

The case of linker unable to find symbol for QtService in MinGW-w64 when developing a Windows service based on QtWebApp

QtWebApp includes QtService for developer's sake when developing Windows service or Linux daemon. QtService is quite well made in many sense, but it's also "abandoned" by Qt Company for years.

I'm using mingw-builds, one of personal builds in MinGW-w64 project, to use the same compiler between Windows and Linux, as well as make use of easy portability. In recent development with QtWebApp I found out that if I dynamic-link QtWebApp the linker cannot find symbol for QtService<QCoreApplication>. As the version for GCC shipped with Qt 5.7 is 5.3 so it's not due to older compiler...... And I found a solution.

Open QtWebApp/qtservice/qtservice.h and find the line below.

template <typename Application>
class DECLSPEC QtService : public QtServiceBase

And I changed the line like this:

template <typename Application>
class /*DECLSPEC*/ QtService : public QtServiceBase

The DECLSPEC changes library header structure using #define. That is changed into either Q_DECL_EXPORT or Q_DECL_IMPORT, and unless it's the time to build the library itself, the value is always Q_DECL_EXPORT. The problem is that QtService is a template class, meaning that the symbol should be changed according to the template details, but if the function is declared as Q_DECL_EXPORT, the compiler assumes that necessary symbols are already built. If you see comment out that DECLSPEC and review the result of the compilation, you can see object file for the header file named qtservice.o.

Well, I had hard time to find this small thing, but I'm relieved that I found it quite quicker than expected. Now I can respect LPGL once again. :)