Lazarus+Firebird+ZeosDBO: Cannot read files in Hangul

When connecting to Firebird using ZeosDBO in Lazarus, if the filename contains Hangul(Korean), the database file cannot be read. Using UTF8ToSys() or Utf8ToAnsi() was of no use. The error occurs when Firebird calls CreateFile(open), though with TIBConnection the file can be read if I apply UTF8ToSys() to DatabaseName.

I liked ZeosDBO as it seems faster that TSQLConection, but now is the time to turn off autocommit and manually do it. Well, considering the origin(a component for Delphi), support for Lazarus is ought to be limited.

Found in following environment:
Lazarus 1.2.4, ZeosDBO 7.1.3a, Firebird 2.5

P.S:Considering the case, the same would happen to files with Chinese or Japanese characters in the name. Pity to CJK users!(including me)

Lazarus+Firebird+ZeosDBO: 한글 파일명 읽기 불가능

Lazarus에서 ZeosDBO를 사용해서 Firebird에 접속할때 파일명이 한글로 되어있으면 파일을 읽지 못하는 문제가 있습니다. UTF8ToSys()나 UTF8ToAnsi()를 사용해도 마찬가지였습니다. 정확히는 Firebird가 파일을 읽기 위해 CreateFile(open)을 호출할때 오류를 일으킵니다. 하지만 TIBConnection은 DatabaseName에 UTF8ToSys()를 적용해주면 정상적으로 동작하더군요.

ZeosDBO가 TSQLConnection보다 속도가 빨라서 좋아했는데, 이젠 TIBConnection에서 autocommit 끄고 돌린 다음에 수동으로 commit하는게 나을 것 같습니다. 아무래도 델파이용으로 만들어진 컴포넌트다보니 Lazarus 지원은 썩 좋지 않은 듯 하네요.

Lazarus 1.2.4, ZeosDBO 7.1.3a, Firebird 2.5에서 확인했습니다.

First Impression after Third Attempt for wxWidgets

wxWidgets is like….. awkward and inconvenient to use. I think now I know why so many projects are moving from wxWidgets to Qt.

As determining to go with Qt for big projects and go with Lazarus for small projects from now on.

Qt에 대한 단상 몇가지

1. 바이너리 크기가 생각보다 큽니다: Qt Quick Controls 기반의 GUI 프로그램을 만들려면 이정도는 갖고 있어야 합니다:

• Qt DLL(22MB: Core, GUI, Network, QML, Quick, Widgets)
• ICU(26MB)
• Qt Quick Controls QMLs and support DLLs(20MB)
• 그리고 기타 필요한 것들

뭐 이쯤 되면 DLL hell은 당연히 열리고도 남게 마련입니다. 특히 Qt Quick Control을 쓰게 된다면요. ;)
몇몇 기능을 제거하면 프로그램 크기를 줄일 수는 있겠지만, 가장 간단한 “hello world”급 프로그램을 띄우는데만 해도 15~20MB정도가 필요합니다. 몇몇 경우, 특히 간단한 업무용 프로그램용으로는 배보다 배꼽이 더 큰 경우가 발생하기도 하죠(파일 의존성 관리라던가, 유지보수라던가……).

2. 상용 라이선스 구매자들에 대한 혜택 증가: 이를테면 Qt Quick Charts나 Qt QML compiler같은 것들이 예시가 될 수 있겠습니다. 물론 상용 라이선스 구매자들에게 더 좋은 서비스를 제공하는 것은 당연한 일입니다만, 물론 Digia가 Qt의 개발에 꽤 괜찮은 성과를 보이고 있긴 하지만, 때로는 너무 돈 낸 사람들만 신경쓰고, 오픈소스 커뮤니티는 홀대하는 건 아닌가 하는 생각도 듭니다.

3. Digia는 Qt 프로젝트에서는 꽤 좋은 성과를 보여주고 있지만, 재무상태가 생각보다 썩 좋은 것 같진 않습니다. 이 포스팅(http://worldcadaccess.typepad.com/blog/2011/03/nokia-sells-qt-cad-vendors-hearts-go-pitter-patter.html)과 회사의 재무현황 지표를 참고해보세요(http://www.digia.com/en/Company/Investors/Financials/Key-Figures-Monitor/).

4. Model-Delegate-View Framework는 생각보다 손이 많이 갑니다: Qt의 model-delegate-view framework는 QAbstractItemModel의 사용을 강제하는 경향이 있고, 이 모델은 구조상 복잡성 때문에 간단한 데이터 표시용으로 쓰기에는 너무 복잡한 경향이 있습니다. 데이터 추출이나 가공이 복잡하다면 이 프레임워크는 꽤 유용한 도구와 인터페이스지만, 대부분의 경우 저는 LCL(Lazarus Component Library)에 있는 TStringGrid가 그리워지더군요.

5. Qt Quick Controls는 아무리 봐도 뜨거운 감자일 뿐: Qt Quick은 위대한 기술입니다. Qt Quick Controls는 widget처럼 생긴 화면을 Qt Quick 위에서 사용할 수 있게 해주는 또다른 기술개발의 결정체입니다. 문제라면…… 라이브러리가 너무 크고, Qt Quick의 JIT 컴파일러 기동때문에 시작이 늦고, Digia가 꽤 여러가지로 신경을 쓰긴 했지만 C++쪽과의 통신도 그렇게 썩 매끄럽지는 않은 것 같습니다. 그렇다고 이걸 안 쓰자니 Qt Quick의 무한한 확장성을 버리는 꼴이 되고…… 최근 추가된 QQuickWidget이 이런 부분을 어느정도 상쇄해 주긴 하지만, 그렇다고 본질적인 문제가 완전히 해결되지는 않아 보입니다.

6. 기능-성능 tradeoff: Qt는 GUI 라이브러리가 아니라 응용프로그램 개발용 종합 프레임워크로 보는게 옳을 것입니다. Qt에는 프로그래머를 편하게 해주는 다양한 기능이 있지만, 이들 기능을 위해 성능을 희생하게 되는 경우를 종종 보게 됩니다. 저도 제가 직접 만든 linked list가 QLinkedList에 비해 5배 이상 빠르게 움직이는걸 경험했고, Google에서 잠깐만 검색해보시면 STL이 Qt보다 더 빠르다는 이야기를 쉽게 찾으실 수 있을겁니다.

Qt가 대단한 기술임을 부정하고 싶지는 않습니다. 저는 Qt를 매우 좋아하고, 지금도 수많은 프로젝트들이 Qt로 돌아서고 있습니다(특히나 wxWidgets에서 오시는 분들이 많더군요). 하지만 Qt를 선택하기 전에 몇몇 생각해봐야 할 부분이 있는 것 또한 현실입니다. 한 1년여 Qt를 특히나 최신버전 중심으로 사용해보니 몇몇 어두운 부분이 보이더군요.

저요? 전 가끔 제 생각에 ‘이건 아니다’ 싶으면 주류를 화끈하게 벗어나는 경향이 있고…… 그래서 전 이번에도 Qt에서 wxWidgets로 이전해 보려고 합니다. 제가 만든 단순한 프로그램들의 배포를 위해서 수십개 파일의 의존성을 관리하기에 저는 너무 게을러요. :(

Some thoughts about Qt nowadays

1. The size of the binary is too large: to open a GUI application with Qt Quick Controls, you should have

• Qt DLLs(22MB: Core, GUI, Network, QML, Quick, Widgets)
• ICU(26MB)
• Qt Quick Controls QMLs and support DLLs(20MB)
• And anything you want

And of course, the DLL dependency hell is open to you, especially if you use Qt Quick Controls. ;)
You can minimize the application size by deactivating some features but still it’s about 15~20MB for simple “hello world” application. Sometimes it’s too heavy to bring all the files for only simple tasks.

2. More benefits to commercial licensees: Qt Quick Charts, Qt QML compiler, and so on. It’s of course fair to give more to commercial licensees but I’m afraid their(Digia’s) efforts ar skewed too much to its customers, though I know that they did quite good job on developments of Qt.

3. The financial status of Digia seems not as good as its leadership in Qt project. Check this post(http://worldcadaccess.typepad.com/blog/2011/03/nokia-sells-qt-cad-vendors-hearts-go-pitter-patter.html) and the financial status of the company itself (http://www.digia.com/en/Company/Investors/Financials/Key-Figures-Monitor/).

4. Model-Deligate-View Framework, overcomplicated: the model-delegate-view framework of Qt seems to make the data represntation overcompilcated as it forces to use QAbstractItemModel deligates to display items. If the data gathering and manipulation is complicated the framework provides useful tools and interfaces to interact, yet most of the time I long for my beloved TStringGrid in LCL(Lazarus Component Library).

5. Qt Quick Controls, a hot potato: Qt Quick is a great technology and Qt Quick Controls is yet another great creation as programmers can make use of Qt Quick technology inside what seems to be the legacy widget-looking interfaces. Yet the size of support library is too big, startup is slow as Qt Quick JIT compiler needs some time to initialize, and it’s still a bit painful when communicating from/to C++ side though Digia did good job in interface handling. Of course you can use Qt Widgets but in this case you lose the unlimited extensibility and power Qt Quick has, though recently added QQuickWidget class complements things a bit.

6. Feature-performance tradeoff: Qt is not just yet another GUI library. It’s rather an application framework from the bottom. It has so many features which makes the programmer convenient, but to support many features it had to sacrifice some performance. Among my personal experiences, I found out my own linked list worked about five times faster than QLinkedList. Or, just google it and you can read so many articles that performance of STL is similar or better against Qt ones.

I don’t want to deny Qt is great technology. I really enjoy using Qt, and even now more and more projects turn to Qt(especially from wxWidgets), meaning there are more programmers who feels like me. But there are things you should consider when choosing Qt. I just wanted to describe some “dark side” stuff against Qt after using the technology for about one year or so, chasing the upstream.

My answer after all those situations? Sometimes I was against the mainstream if I think so. I’m moving from Qt to wxWidgets. I’m too lazy to manage tens of files for only simple applications I make.

Qt WebKit: 사라져가는 위대한 프로젝트를 바라보며

작년 11월에 Digia는 Qt WebEngine이라 불리는 새로운 프로젝트를 시작했습니다. Google의 Chromium에 기반한 이 프로젝트는 현재의 Qt WebKit을 대체할 목적으로 만들어졌습니다. 대부분의 사람들은 Chromium을 쉽게 자신들의 프로젝트에 도입할 수 있게 된다는 사실을 크게 반겼습니다. Digia는 Qt WebEngine이 Qt WebKit과 가능한 한 최대한 호환되도록 만들겠다고 약속하였고, 당대에서는 Nokia의 환경에서도 Digia가 꽤 좋은 평가를 받았던지라 많은 사람들이 그 약속을 믿었습니다.

지난주에 Qt WebEngine 팀이 새로운 블로그를 올렸고, 저는 그 글의 댓글에서 API에 대한 약간의 “불평”을 발견했습니다. 위키를 확인해본 결과, 제가 web crawler 개발에 사용하는 핵심 기능인 QWebElement는 사용 불가로 낙인이 찍혀 있더군요 - 위키에 따르면, Chromium 자체가 멀티프로세스 기반이다보니 이 기능 자체가 비동기적으로 구성되어야 하는데, Qt WebEngine의 디자인은 동기화 구성이 기본이라 더이상 지원하지 않는다고 합니다.

QWebElement뿐만이 아닙니다. 제가 컨텐츠의 정상 여부를 활용하는데 사용하는 QNetworkAccessManager도 사용되지 않습니다. Qt WebEngine은 Chromium의 자체 네트워크 스택을 사용하며, 이렇게 되면 전 엔진의 네트웍에서 무슨 일이 벌어지는지 가늠할 수 있는 방법이 없어집니다.

덕분에 전 제 개발품에서 일부 기능을 부득이하게 삭제해야 되는 상황에 처했습니다. 일단 예측 가능한 미래만 놓고 본다면, Qt WebKit 자체는 9월 발표 예정인 Qt 5.4가 나오는 11월까지는 어떻게든 생존하겠지만, Qt 5.5 오픈소스 에디션이 발표되는 순간 무슨 일이 생길지는 아무도 모릅니다.

그간 WebKit이 유지보수에 손이 좀 많이 갔다고 하기도 하고, 저는 Digia의 개발팀을 좀 더 “효율적으로” 관리하고자 하는 의지 또한 존중합니다. 허나, 지난주 블로그 포스트에 달린 댓글들마냥 Qt WebEngine이 기대와 다르게 훨씬 더 적은 기능만을 갖고 출시된다면 아마 실망하는 사람이 적잖을 것 같아 우려됩니다.

현재 저는 현재의 개발환경을 대체할만한 무언가를 찾고 있습니다. Qt가 그동안 버전업을 하면서 셋업은 복잡해지고, QML 시작은 느려지고(빈 창 하나 띄우는데 최고 10초까지 소요) 하는 등의 상황을 보면서 뭔가 제 마음에 들만한 대체요소를 찾고 있긴 했습니다만, 울고 싶던 차에 Qt WebEngine이 뺨을 제대로 때려주는군요. 일단 현재는 wxWidgets+wxWebConnect(아니면 wxWebView) 컴보를 대체품으로 생각하고 있습니다.

어쨌든, Qt WebKit은 꽤나 위대한 프로젝트였습니다만, 이 프로젝트가 역사 속으로 사라질걸 생각하니 참 가슴이 아픕니다. 특히나 그렇게 사라지는 행위가 제 뒤통수를 크게 때리는 경우에는 더 그렇습니다.

Seeing the Doomed, yet Great Project: Qt WebKit

Last November, Digia announced the start of the new project named Qt WebEngine. Based on Google Chromium, it is a drop-in replacement of Qt WebKit. Most of the people welcomed the project, as they can easily use Chromium and Blink to their own environment. Digia said that Qt WebEngine will be as compatible as possible against Qt WebKit, and everybody belived in the promise, as Digia had a good reputation against Nokia, as they were practically leading the project well even in Nokia days of Qt.

Last week, I read a new blog article from Qt WebEngine team, and I saw some “complaints” about APIs for the new module. I jumped to the wiki and found out that my beloved QWebElement, which is the most needed core feature for my web crawler engine, will be unavailable in Qt WebEngine - according to the wiki, due to multi-process nature of the Chromium the feature should be designed asynchronously, but the design of Qt WebEngine is synchronous, it is not supported anymore.

Not only QWebElement. It also doesn’t integrate QNetworkAccessManager, which is another thing I use to check sanity of the content. Qt WebEngine uses Chromium’s own network stack, meaning I cannot review any network action from the Engine.

Thanks to the changes, my product won’t be able to support some of the features it currently has. From the foreseeable future, Qt WebKit will survive until Qt 5.4, which is expected to be released at this September, but there’s no guarantee what’ll happen when Qt 5.5 open source edition is released.

Of course there are be some reasons beyond giviing up WebKit as it requires more manpower for maintenance and I respect their decision to manage their development team in “more efficient” way. Yet I’m afraid there will be more who’re frustrated against new Qt WebEngine for its limited features as I read from some replies for Qt WebEngine blog article last week.

Well, now I search for some alternative development environment. I was already searching for a replacement of Qt itself as I see it become feature-bloat, resulting in more complicated setup environment, slow startup time in QML(up to 10 seconds for showing blank window), as I adopt new version of the library. And Qt WebEngine accelerated my move. Currently I consider wxWidgets+wxWebConnect(or wxWebView) combination as a replacement for current development environment.

Anyway, Qt WebKit was a great project, yet seeing one of the greatest development projects fade out to the history is quite a pain. Especially if the fadeout directly hits me hard.