Going Native

A lot of things happened behind the scenes. Due to some unflexible cash flow my company closed Korea branch, and I moved to a small company and got dual role of system engineer and developer. Well, the company first expected to do engineering and development works in 50:50 manner, but in practice I concentrate on development itself. I think it's a good start for a ex-hobbiest-programmer where the customer changed their feedback from negative to positive after my application is delivered to them.

And, during the time I thought of the techonlogy stacks I should bring with myself. Though Qt can cover everything from desktop to mobile, and is equipped with a lot of powerful features, after applying the tool to the work situation things dragged me of my legs. For example:

1. It's BIG. HUGE. OK. It's good to have a lot of things, but the size of library grows bigger with any new addition of the features. For simple tasks, I can't avoid the feeling of using zweihander to grass cutting.
2. SLOW. From Qt Model-View framework which is a failure and needs restructuring, to container classes like QList or QLinkedList saying "we're concentraing on convenience while STL stresses on raw speed," and the speed of database manipulation is not that good eighter. For databases, I found out it's far faster to use SOCI after converting things from QString to std::string. From my experience, for the same task Qt took about twice or more time to perform the same task against others(e.g. STL or wxWidgets).
3. Developer is "locked" into the Qt ecosystem. Well, I admit its rich feature gives developers more development convenience, but after adopting to Qt I don't feel good with using it with other libraries or environments. Sometimes I feel I'm working on Java instead of C++, in terms of not only structue but also running performance of the system(meaning that it's slow, unlike C++). During coding, I'm not sure whether I'm using Java or c++. Ah, of course signal-slot mechanism and QString is such a technologicla advance in a decade.
4. It has some holes here and there, for example, Qt Quick. I love the approach and structure of Qt Quick and I admit it's such an accomplishment, I see occasional "broken" frames on Windows/Intel environment, or I see too long time for the first run on Andorid(they existed until Qt 5.9. I heard that the bytecode compilation in Qt 5.11 resolved the slow first start a lot, but I had no chance to test it). Or, for me a MinGW user, in Qt 5.10 qdoc(and that Qt documentation) suddenly became unavailable because MinGW 5.3 couldn't compile libclang(......). And the new autompletion with libclang in Qt Creator is said to be toooooo slow....... And so on and on and on. 
5. Sometimes there are things infeasible to programmers. Qt hides the implementation details in its private layer, which makes it too difficult to debug when some bad things happen, especially when it's related with some specific feature of Qt itself. What's more, due to the behavior of QURL to force percent-encoding(and which is malfunction in specific context), I had to give up QNetworkAccess and adopt libcurl(with additional coding where I had to implement about 3/4 of my network coding again......).

Well, anyway it's BIG enough to be tackled from anywhere, but you know, now I can say there's no one library/framework that fits too all. So I looked for any alternatives and asked for help from my close friends. And guess what? Now I'm dropping the dependency against Qt and bringing development staks close to native "recommended" environment.

1. C++ / wxWidgets & more: whoever says what, C++ is my main development platform. And I concluded wxWdigets, thin wrapper of native widgets, can replace Qt Widgets. Thinking of my past experience, I had to save my time so that I had to use Qt Widgets anyway(and Qt Quick took relatively too much time to develop). wxWidgets consumes less memory and bootstrapping is faster, which fits to my philosophy of "relatively fast running."
2. Ah. I changed my compiler from MinGW to VC++. I was using MinGW to expect consistency against platforms, namely Windows and Linux, but nowadays I had to use some Windows API which doesn't exist in MinGW(:P). And it looks like VC++ looks good from VC++ 2017. I think I should conquer the differences between compilers with some nuts.
3. Javascript: Javascript is the language of web! As soon as I'm done with my current project, I'd like to start learning vue.js and node.js(especially Express.js) and apply them to the work.
4. Kotlin: OK. Now the desktop is done, but still "mobile" remains. Kotlin is native in Android(and I strongly feel that Google pushes it harder than ever after it lost the case against Oracle), and when Kotlin/Native is copmlete iOS can be "natively" supported. It's a good choice for me, who won't touch Apple ecosystem for a few years but no idea after that.

Originally I added Python and Rust to the list, but I found out that I don't have to dig deep Python though it's used in the product I currently engineer, and I concluded that from Rust I can adopt the structure to C++ so I don't have to worry much. And I also considered Go but its structure was not of my taste......

So that's all. At present, I just want to close the current project and have some time to learn Javascript.

네이티브로 가자!

조용했던 그동안 많은 일이 있었습니다. 다니던 회사가 자금사정이 악화되어 한국지사가 폐쇄되었고, 여차저차해서 작은 회사의 모 제품 시스템 엔지니어 겸 개발자가 되었습니다. 그리고 원래대로라면 엔지니어링과 개발이 50:50이 되어야 하는데, 또 어쩌다보니 엔지니어링보다는 개발에 집중하고 있습니다. 뭐, 제 개발품으로 인해 그간 계속 부정적이기만 했던 고객사의 피드백이 최초로 긍정적으로 바뀌었다고 하니, 20년동안 취미로만 프로그래밍을 하던 사람의 실적치고는 꽤 괜찮은 출발인 것 같습니다.

그리고 그동안 제가 가져가야 할 개발환경에 대해 많이 생각했습니다. 비록 Qt가 데스크탑에서 모바일에 이르기까지 다양한 플랫폼을 지원하고 매우 강력한 기능들이 많다지만, 실제로 업무현장에 적용해보니 확실히 몇가지 문제들이 제 발목을 잡더군요. 몇가지를 예로 들자면......

1. 덩치가 큽니다. 기능이 많은건 좋은데, 그 반대급부로 라이브러리의 크기가 계속 커져가고 있습니다. 닭 잡는데 소 잡는 칼을 쓰는 듯한 느낌을 지울 수 없습니다.
2. 느립니다. 많은 사람들로부터 전면 개보수가 필요하다고 평가받는 Qt Model-View framework부터 시작해서, QList, QLinkedList 등 container class들은 아예 "STL이 속도라면 우린 편의성"이 모토고, 데이터베이스 처리도 썩 그렇게 좋은 성능을 보여주지 못하고 있습니다. DB는 Qt datbase framework보다는 QString을 std::string으로 변환한 뒤에 SOCI를 쓰는게 훨씬 빠르더군요.
3. 개발자가 Qt의 개발환경에 '갇힙니다.' Qt가 다방면으로 매우 많은 기능을 지원하고, 그로 인해 개발 편의성이 올라가는 것은 누구나 인정하는 바입니다만, 한번 Qt의 개발환경을 사용하고 나게 되면 다른 라이브러리나 환경을 접목시키기가 쉽지 않다는 느낌을 받습니다. 가끔씩은 매우 Java같은 느낌의 C++ 프레임워크라는 느낌이 들더군요. 구조만 그러면 모르겠는데, 프로그램의 수행속도도 C++보다는 Java에 더 가깝다는 느낌을 많이 받습니다(즉, C++답지 않게 느리게 느껴집니다). 개발을 하고 있다보면 내가 C++을 쓰는지 Java를 쓰는지 살짝 헷갈리기도 합니다(......). 아, 물론 signal-slot 매커니즘과 QString은 인정합니다.
4. 꼭 뭔가 하나씩 빵꾸가 납니다. 가장 대표적인게 Qt Quick입니다. 비록 Qt Quick은 기능과 접근방법 모두 훌륭하고, 대단한 기술적 성공이긴 합니다만, Windows/Intel 비디오카드 환경에서 화면 크기 변경시에 프레임이 깨져서 눈에 거슬린다던가, Android로 빌드할 경우 최초 실행시 boottime이 너무 길어진다던가 하는 등의 문제점이 있습니다(최소한 5.9까지 상존했던 문제입니다. 5.11에서는 bytecode compilation 덕에 많이 좋아졌다고는 들었습니다만, 테스트는 못해봤네요). 아니면 저의 경우 플랫폼간 컴파일러의 일관적 행태를 위해 MinGW를 쓰는데, Qt 5.11의 경우 현재 지원하는 MinGW 5.3에서 libclang이 빌드되지 않는다는 이유 하나만으로 qdoc을 빌드하지 않게 막았다던가(......) 하는 등의 자잘한 건들이 생깁니다. 아울러 Qt Creator의 autocompletion을 libclang 기반으로 바꾼다고 선언했는데, 너무 느리다고 말이 많기도 하고...... 
5. 가끔 뜬구름 잡는 듯한 느낌이 있습니다. Qt가 개발을 편하게 하게 하기 위하 많은 기능을 지원하긴 하는데, 이게 프로그램 동작의 많은 부분을 숨겨놓은 터라 가끔 문제가 생기면 어디서 뭘 봐야 할지 감이 안 잡히는 상황들이 발생합니다. 특히 그게 Qt의 특정 기능과 직접적으로 연관된 경우는 더 그렇습니다. 심지어 최근에는 QURL에서 퍼센트 인코딩을 강제하는(문제는 이게 특정 상황에서는 적용되기가 어렵다는) 특징때문에 그 편한 QNetworkAcccessManager을 쓰지 못하고 libcurl을 써야 했던(그리고 네트웍 코드의 3/4을 갈아엎어야 했던......-_-) 상황도 있었습니다.

뭐, 프레임워크의 덩치가 워낙 크다보니 말이 많긴 하겠습니다만, 하여간 실무에 적용하다보니 이런저런 문제점들이 보이더군요. 그래서 여러가지 대안도 찾아보고, 주변 분들의 조언도 구한 끝에 Qt에 대한 의존성을 버리고, 네이티브에 가까운 개발환경을 가져가는게 좋겠다는 결론을 내렸습니다.

1. C++ / wxWidgets & more: C++은 제 메인 개발환경이니 필히 가져가야 하고, GUI는 네이티브 위젯의 thin wrapper인 wxWidgets를 쓰면 되겠다는 결론을 내렸습니다. 시간이 없어 급하게 개발하다보면 Qt Quick은 항상 그림의 떡이고, 맨날 Qt Widgets만 쓰던 입장에서는 차라리 네이티브라 RAM도 덜 먹고 bootstraping도 빠른 wxWidgets가 답이겠더군요.
2. 하는 김에 컴파일러도 MinGW에서 VC++로 변경했습니다. 그동안에는 Windows와 Linux 사이에서 컴파일러가 일관적으로 돌아가는걸 감안하느라 MinGW를 썼는데, 가끔 Windows API를 쓸 일이 생기면 꼭 MinGW에는 없는 헤더만 찾게 되더군요(-_-). VC++2017 자체도 많이 좋아진 듯 하고...... 컴파일러간 차이는 그냥 근성으로 극복해봐야 할 듯 합니다.
3. Javascript: Web은 역시 Javascript가 native입죠(......). 일단 현재 프로젝트가 어느정도 정리되면 vue.js와 node.js(Express.js)를 중심으로 천천히 실무에 적용해볼 계획입니다.
4. Kotlin: 맨날 desktop에서 놀다보니 모바일은 어떻게 가져가야 하는가 하는 문제가 남는데, Kotlin은 일단 Android에서는 native고(특히나 Google이 Oracle과의 소송에서 패한 뒤로는 더 화끈하게 밀어주고 있다는 느낌을 많이 받았습니다), Kotlin/Native가 완성되면 iOS도 네이티브로 개발이 가능해지는 만큼 꽤 괜찮겠다는 결론을 내렸습니다. 특히나 저처럼 앞으로 근 몇년간은 Apple쪽 생태계를 건드릴 일이 없지만 언제가 건드릴지도 모르는 경우에는 더 그렇고요.

원래는 여기에 Python과 Rust가 추가되어 있었습니다만, Python은 현재 엔지니어링을 진행중인 제품에서 쓰고 있긴 하지만 그렇게 깊게 들어갈 필요가 없고, Rust는 C++에서 약간만 조심하면 되는터라 당장 큰 문제는 되지 않겠다는 결론이 나서 일단은 버리기로 했습니다. 그 외에 Go도 후보선상에 살짝 올라와 있었지만 언어 구조가 영 제 취향이 아니라 포기했고......

오랜만에 잡생각을 정리할 겸 해서 올려봤습니다. 지금은 하던 일 잘 마무리하고 Javascript 공부에 할애할 시간을 확보했으면 좋겠네요.

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!

On site development and Qt

Recently I had a chance to develop some applications on site. I used the greatly-productive Qt and Qt Creator, Application was built in an instant, and result was satisfactory. But the experience remained me some uncomfortable memory.

Except for skeleton codes, I put only 10 to 20 lines. I had to find out DLLs with more than 20MB, put them all to USB thumb drive, and I put the drive to PCs here and there. In each run I had to wait for 2~3 seconds more after starting running, and the delay became a burden as I repeated the job.

On Windows, Qt initiates DirectX and OpenGL, regardless of whether those modules are actually used in the application of not. My application was based fully on Qt Widgets and GDI, so that there's no way DirectX or OpenGL would be involved, but Qt initialized those stuff anyway. And to initialize, you have to wait for two or three seconds. If your system was already using those that's no problem, but in office environment, chances are that they'll be used only when you play video games, avoiding eyes of your boss.

Of course if the application is big enough to show splash screen saying "WAIT!" waiting for two or three seconds is no problem, but for apps quickly developed on site and run instantly, it's like forever - when you're busy and quick-tempered, chances are that you hit enter key a lot of times, resulting in starting a lot of instances at once, delaying the actual start more than ever(well, sometimes you experience Windows eats your keyboard or mouse input. don't you?).

Nowadays I feel that the high productivity and abundant features of Qt has its own tradeoff - e.g. performance issue(not only startup time, but also performance of features, like QLinkedList against similar others) and shared library. Of course in Linux the situation can be different, but in Windows it has its own story(if you're a GTK user that's yet another different story, but it's out of scope as for now).

Anyway, after experiencing this and that, I moved again from Qt to wxWidgets. I love the instant startup at cold start and freely available static link thanks to its license policy, resulting in easier deployment. There are, of course, some(expected) productivity losses or features not existing, but it can be overcome with the power of will(.....) and my own development.

I don't want to open the flame - Qt is really a great product and I totally agree. But there's no such thing as one size that fits to all. For some time being, I'll have fun with my wxWidgets and Code::Blocks.

필요한 application의 현장 내 즉각적인 개발과 Qt

최근 현장에서 즉석으로 프로그램들을 만들 일이 있었습니다. 생산성 와방(......)인 Qt에 Qt Creator를 대동했습니다. 프로그램은 순식간에 만들어졌고, 원하는 결과를 정확하게 도출해냈습니다. 하지만 제게 그 경험은 일부 불편함을 남겼습니다.

Skeleton code를 제외하고 제가 작성한 핵심 코드는 약 10~20줄 남짓이었습니다. 그리고 전 20MB가 넘는 DLL들을 일일이 찾아 넣었고, 한데 모인 프로그램 패키지를 USB 메모리에 담아 각 PC에 꽂아가며 일일이 실행했습니다. PC에서 프로그램을 실행할 때마다 약 2~3초간의 지연이 있었고, 실행이 반복될수록 저 지연이 제게는 큰 부담으로 다가왔습니다.

Windows에서 Qt는 실행시 DirectX와 OpenGL을 기동시킵니다. 프로그램이 실제로 이 모듈들을 사용하는지의 여부는 상관없습니다. 제가 만든건 GDI 기반의 Qt Widgets 기반 프로그램이라 DirectX나 OpenGL이 끼어들 틈이 없었습니다만, Qt는 어쨌든 실행만 했다 하면 저 양대 그래픽 가속 시스템을 기동시킵니다. 그리고 저 모듈들은 최초 기동할때 최고 2~3초 정도를 잡아먹습니다. 이 모듈들이 이미 기동중이었으면 상관없지만, 사무용 PC 환경에서 저들 모듈이 기동하는건 팀장님 몰래 게임할 때(......) 빼고는 거의 없죠.

물론 splash screen을 띄워놓고 "기다리쇼"라고 할 정도의 큰 프로그램이라면 2~3초정도의 delay는 큰 문제가 되지 않습니다만, 현장에서 즉석에서 만들어져서 간단하게 쓸 프로그램에게 2~3초는 꽤 긴 시간입니다. 특히나 바쁜 상황일 경우, 성질 급한 사람들은 그 시간을 못 기다리고 엔터키를 연발하다가 instance를 수십개 넘게 만들어내는, 덕분에 프로그램의 실행이 더 지연되어 귀중한 시간을 낭비하는 상황까지 발생할 수 있습니다(뭐 사실 이런 사람들이 이해가 가기도 하는게, 가끔 보면 Windows가 키보드나 마우스 입력을 먹어버리는 경우가 있기도 하죠).

요즘 들어서 느끼는 거지만, Qt가 높은 생산성과 다양한 기능을 제공하는 이면에는 군데군데 발생하는 성능 이슈(꼭 cold start time이 아니더라도, linked list나 다른 여러 부분에서 미친듯이 속도가 느립니다)와 거대한 shared library가 있다는 생각이 듭니다. 일종의 tradeoff로 보고 있습니다만...... 물론 리눅스에서는 상황이 다릅니다만, Windows에서는 또 Windows만의 이야기가 있는 법이지요(GTK+ 계열 사용자시라면 또 다른 문제가 있을 것 같기도 합니다만, 그 부분은 다른 문제이니 여기서는 다루지 않겠습니다).

하여튼, 저런 상황을 겪고 난 이후 저는 또다시 Qt에서 wxWidgets로 옮겨왔습니다. Cold start시에도 instant로 번쩍하고 뜨고, 라이선스 정책 덕분에 static link에 대한 제약도 없어서 배포도 편합니다. 물론 구조적 특성상 생산성이 살짝 떨어진다거나 일부 기능이 없다거나 하는 문제도 있긴 하지만, 그 부분은 근성(......)과 직접 개발로 충분히 벌충할 수 있는 수준인 것 같습니다.

Qt는 정말 좋은 라이브러리입니다. 하지만 평양 감사도 저 싫으면 못하는 법이고, 모든 몸에 딱 맞는 하나의 치수를 가진 옷같은건 어디에도 존재하지 않지요. 당분간은 wxWidgets와 Code::Blocks로 연명하게 될 것 같습니다.

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 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.