Mozilla는 늘 새로움을 추구한다. 이제는 Shockwave/Flash(SWF) file을 HTLM/CSS/JavaScript로 렌더링하는 시도를 하고 있다. Plug-in 없는 세상을 만들겠다는 Mozilla의 노력이기도 하고 Adobe가 더 이상 Linux에서 NPAPI기반 Flash를 업데이트하지 않겠다는 발표 때문인 것 같다. 프로젝트 이름은 Shumway이며 이번에 lwn.net에 자세하게 소개되었다. JavaScript만으로도 게임 에뮬레이터가 나오고, 이미 PDF.js로 pdf출력도 가능하니, 기술적으로 불가능해보이지는 않는다. Firefox mainline에 반영되었고 내년초에 Firefox에 포함되어 릴리스될 것 같다.
분명히 Canvas를 사용했을 것이고, 방대한 Flash spec과 ActionScripts는 어떻게 지원했을까? 여러가지 기술적으로 재밌는 부분이 많은 듯 보인다.
2013년 10월 25일 금요일
2013년 4월 3일 수요일
구글과 모질라의 새 브라우저 렌더링 엔진
만우절이 지난 것이 확실한데, webkit-dev mailing list로 부터 "Thank you"라는 메일이 하나왔다. Eric이 WebKit일을 그만두나 싶었는데, 구글이 Blink라는 새로운 WebKit기반의 엔진의 시작을 알리는 메일이였다. 사실 Google과 Apple은 WebKit의 WebCore만 공유한채 서로 다른 JavaScript엔진과 서로 다른 Multi-process archicture를 가져갔다. WebCore에 새로운 feature 추가를 두고 서로 논쟁도 많았는데, 드디어 다른 프로젝트로 독립한다니 무척 슬프다. 사실 WebKit은 여러 경쟁 회사가 서로 협력하는 성공적인 오픈소스 프로젝트였다. 최근 Apple의 WebKit2 리뷰 정책때문에 불만이 높기는 하지만, 따로 독립한다는 결정은 그리 쉽지 않다. 오직 Google만이 가능한 결정 같다. 하여간, 이제 WebKit를 사용하는 다른 오픈소스 커뮤니티나 회사들의 이후 움직임이 궁금해진다. 일부는 Blink로 갈 수도 있을 것 같다.
Mozilla는 좀 더 혁신적인 프로젝트를 진행중에 있다.
정말 Mozilla 다운 생각이다. Chrome브라우저가 브라우저 기술의 혁신을 주도하면서 Firefox는 다소 주춤한 상태이다. 특히, Multi-process지원은 Firefox가 빨리 수용해야 할 기술인데, Mutil-Core 지원을 중점으로 새로운 브라우저 엔진인 Servo를 개발한다니, 기대가 크다.
지난 몇 년간 Mozilla와 WebKit기반으로 여러 프로젝트를 진행해 온 개발자로서 현재 상황이 상당히 혼란스럽기는 하지만, 오픈소스 개발자로 꿈을 키우는 사람들에게는 새로운 기회가 될 것 같다.
2009년 9월 9일 수요일
미래 웹포럼 2009 후기
지난 9/4(금)에 미래 웹 포럼 2009 워크샵 행사가 성황리에 끝났습니다. 많은 웹 개발자, 기획자, 학생 분들이 참석하셨고, 패널 토의까지 많은 분들이 남아서 눈 앞에 등장한 HTML5와 모바일 웹에 대한 관심을 보여주셨습니다.
이번 행사에서는 저는 "Fennec의 현재와 미래" 제목으로 Fennec 개발 진행 상황에 앞으로 계획에 대해 소개하였습니다. 그 동안 Fennec 개발에 참여하면서 얻은 정보와 주요 Fennec 개발자 블로그를 참고해서 가능한 모질라의 개발 의도를 잘 전달하려고 노력하였습니다. 더불어 Samsung Windows Mobile SDK도 소개하였습니다. (다른 분들의 발표 내용은 여기에)
참석자 분들이 대부분 웹개발자인데, 너무 Fennec 구현에 대한 기술적인 내용을 많이 언급하지 않았나 싶습니다. Device API도 웹개발자 보다는 Add-ons이나 XUL 애플리케이션 개발자에게 관심가는 주제가 아니였나 생각합니다.
부족하지만, 그날 참석을 못한 분은 동영상과 발표 자료를 보시면 Fennec의 개발 진행 상황을 이해하는 도움이 될 것 같습니다.
아울러, 이번에 공개된 Fennec 1.0 beta3 for Windows Mobile를 옴니아를 비롯한 국내에 출시된 Windows Mobile 단말에 설치해 보시고 테스트해서 버그를 올려주시면 좋겠습니다. 특히, 국내 옴니아는 해외 옴니아와 사양이 달라서 Fennec 개발자들이 문제를 잘 모를 수 있습니다.
옴니아2는 이미 해외에서 출시되어 bugzilla에 버그가 등록되고 있습니다. 국내에도 출시되면 Fennec의 사용자가 많이 늘어날 것 같습니다.
패널 토의에서는 HTML5에 대한 많은 이야기가 오고 갔습니다. 과연 앞으로 HTML5를 무장한 웹이 Mobile Application Platform이 될 수 있느냐가 큰 관심이였습니다. 웹개발자에게는 모바일에서 widget뿐만 아니라 애플리케이션 개발까지 관심 영역을 확대할 수 있는 기회가 될 수 있기 때문입니다.
시기는 무르익었다고 생각합니다. Widget은 그 다리 역할을 할 것이고, Palm Pre와 앞으로 출시될 Goolge Chrome OS에 볼 수 있듯이 HTML5가 모바일 애플리케이션 개발에서 큰 역할을 하게 될 것입니다.
Samsung Mobile Innovator에서 이번에 공개한 Widget 개발툴도 좋은 예인 것 같습니다. 아직은 해외 삼성 단말만 적용되지만, 이런 Widget 개발툴을 미리 경험하는 것도 앞으로 다가올 미래를 대비하는 좋은 방법이 될 것 같습니다.
이번 행사에서는 저는 "Fennec의 현재와 미래" 제목으로 Fennec 개발 진행 상황에 앞으로 계획에 대해 소개하였습니다. 그 동안 Fennec 개발에 참여하면서 얻은 정보와 주요 Fennec 개발자 블로그를 참고해서 가능한 모질라의 개발 의도를 잘 전달하려고 노력하였습니다. 더불어 Samsung Windows Mobile SDK도 소개하였습니다. (다른 분들의 발표 내용은 여기에)
참석자 분들이 대부분 웹개발자인데, 너무 Fennec 구현에 대한 기술적인 내용을 많이 언급하지 않았나 싶습니다. Device API도 웹개발자 보다는 Add-ons이나 XUL 애플리케이션 개발자에게 관심가는 주제가 아니였나 생각합니다.
부족하지만, 그날 참석을 못한 분은 동영상과 발표 자료를 보시면 Fennec의 개발 진행 상황을 이해하는 도움이 될 것 같습니다.
아울러, 이번에 공개된 Fennec 1.0 beta3 for Windows Mobile를 옴니아를 비롯한 국내에 출시된 Windows Mobile 단말에 설치해 보시고 테스트해서 버그를 올려주시면 좋겠습니다. 특히, 국내 옴니아는 해외 옴니아와 사양이 달라서 Fennec 개발자들이 문제를 잘 모를 수 있습니다.
옴니아2는 이미 해외에서 출시되어 bugzilla에 버그가 등록되고 있습니다. 국내에도 출시되면 Fennec의 사용자가 많이 늘어날 것 같습니다.
패널 토의에서는 HTML5에 대한 많은 이야기가 오고 갔습니다. 과연 앞으로 HTML5를 무장한 웹이 Mobile Application Platform이 될 수 있느냐가 큰 관심이였습니다. 웹개발자에게는 모바일에서 widget뿐만 아니라 애플리케이션 개발까지 관심 영역을 확대할 수 있는 기회가 될 수 있기 때문입니다.
시기는 무르익었다고 생각합니다. Widget은 그 다리 역할을 할 것이고, Palm Pre와 앞으로 출시될 Goolge Chrome OS에 볼 수 있듯이 HTML5가 모바일 애플리케이션 개발에서 큰 역할을 하게 될 것입니다.
Samsung Mobile Innovator에서 이번에 공개한 Widget 개발툴도 좋은 예인 것 같습니다. 아직은 해외 삼성 단말만 적용되지만, 이런 Widget 개발툴을 미리 경험하는 것도 앞으로 다가올 미래를 대비하는 좋은 방법이 될 것 같습니다.
2009년 8월 31일 월요일
Fennec 1.0 beta3 for Maemo 소개
지난 8월 20일날 Fennec 1.0 beta3 for Maemo가 출시되었습니다. 6월 26일날 beta2가 나왔었으니까, 3개월만에 새로운 버전이 공개된 것입니다.
앞으로 beta4가 한 번 더 공개되고 연말에 정식 버전이 나올 예정이라고 합니다. Windows Mobile버전은 그 보다 느려서 내년초에 정식 버전이 공개될 것 같습니다.
이번 beta3의 가장 큰 특징은Flick/ Panning속도의 증가와 관성 스크롤 기능의 향상입니다. 이를 위해 타일 방식으로 한번 화면에 노출된 영역을 Cache하여 관리하는 렌더링 방식을 도입했습니다. 이제 Fennec에서도 iPhone 처럼 flick 속도에 맞추어 페이지가 스크롤되는 모습을 볼 수 있게 되었습니다. 자세한 구현 방법은 아래 글을 참고하세요.
자, 그럼 새롭게 변경된 UI를 살펴볼까요? 기능적으로 추가된 부분은 없지만, 전체적으로 UI가 모양이 조금씩 변경되었습니다.
Awesome Bar와 도구모음에 적용되었던 그라데이션이 사리지고 UI은 짙은 회식으로 변경되었고, 전체보기 상태에서만 종료 단추가 추가되었습니다.
메모리 절약과 성능향상을 위해 Windows Mobile 버전에서 적용된 Theme가 Maemo까지 동일하게 적용된 것입니다.
우측 도구 모음에 있는 별 단추를 누르면 "Page Bookmarked"라는 메시지 상자가 나타납니다. 이 때, Edit 단추를 누르면 아래와 같은 Bookmark편집 대화 상자가 나타납니다.
사이트 제목, URL을 변경할 수 있고 태그도 입력할 수 있습니다.
Awesome Bar 모습입니다. 입력하는 텍스트에 해당하는 추천 URL을 화면에 보여줍니다. 이 상태에서 하단에 있는 검색 사이트 단추를 누르면, 입력한 키워드에 대한 검색 결과를 보여줍니다. Mobile에서 작은 화면을 효과적으로 활용한 예라고 할 수 있습니다.
이 상태에서 "See All Bookmarks"를 선택하면 아래와 같이 등록한 모든 Bookmark를 볼 수 있고, 편집 및 폴더 관리를 할 수 있습니다.
모바일 환경에서 꼭 필요한 패스워드 저장 기능입니다.
다운로드 링크를 클릭하면 위와 같이 다운로드할 파일을 어떻게 처리할지 물어봅니다.
그런데, 다운로드한 이후, 다운로드 리스트 보면 항목이 보지 않습니다. 버그일까요?
Add-ons은 URL Fixer가 유일하네요. Fennec의 코드가 계속 변경되면서 기존 Add-ons가 호환되지 않는 것 같습니다.
URL Fixer를 설치하면 Firefox처럼 Fennec을 다시 시작해야 합니다. 재시작하는데, 약간의 시간이 걸립니다. 그 후 URL창에 "google.con"이라고 입력하면, 아래와 같은 대화상자가 나타납니다.
당연히 google.com을 입력하려고 했던 것이므로, "Yes"를 선택하면 google.com을 접속을 합니다.
Preferences모습입니다. 기본적인 옵션 설정이 제공되고 있습니다.
이상으로 Fennec 1.0 beta3 for Maemo의 주요 기능을 소개하였습니다. beta에 와서 특별히 추가되는 기능은 없고, 성능 향상과 UI 모습 변경이 눈에 띕니다. 현재 브라우징을 하다보면 간혹 Fennec이 이유없이 종료되는 현상이 발생하고 있습니다. 이제 어느 정도 성능 문제도 해결되었으니, 안정성에 좀 더 노력을 기울여야 할 것 같습니다.
참고
2009년 6월 3일 수요일
Fennec Architecture
지난 FOSDEM09에서 Fennec의 Front End(XUL)개발을 주도하고 있는 Mark Finkle이 Fennec Architecture에 대해 발표를 했습니다. 발표 내용을 모질라 위키에도 자세하게 설명 해 놓았는데, Fennec의 설계 철학과 동작 방식을 이해하는데 더할 나위없이 좋은 자료이므로 번역을 해보았습니다. 참고가 될 만한 링크를 넣고, 좀 더 내용을 추가해 이해를 도왔습니다.
Fennec은 특별히 터치 스크린(touch screen)를 제공하는 모바일(Mobile) 기기를 위해 설계된 XUL기반의 웹브라우저입니다. Firefox와 Mozilla 플랫폼의 많은 부분을 서로 공유하고 있는데, 같은 HTML Rendering Engine을 사용할 뿐만 아니라 확장기능(Add-ons) 지원, 다운로드 관리, 즐겨찾기 및 히스토리, 자바스크립트 엔진(JIT Support)을 공유하고 있습니다.
이렇게 플랫폼 기반은 같지만, Front-end UI는 완전히 다릅니다. Fennec은 작은 화면에 낮은 CPU와 메모리, 키보드가 없이 터치스크린을 위해 설계되었습니다. 이러한 UI 크기 차이로 Firefox UI를 오버레이(overlay)하고 있는 add-ons의 경우 Fennec에서 동작하려면 포팅 작업이 필요하고, 터치 기반의 UI를 가진 모바일 기기에서 만족할 만한 성능에 촛점을 맞춘 결과, 다소 특히한 XUL 구조를 갖고 있습니다.
Fennec과 Firefox는 HTML을 보여주는 방식이 아주 다릅니다. Firefox는 탭(tab)브라우징 환경을 지원하기 위해 <tabbrowser>라는 XUL 엘리먼트를 사용합니다. <tabbrower>는 composite control로, 수정된 <tabbox>엘리먼트 안에 포함된 <browser>엘리먼트로 구성되어 있습니다. 주요 동작은 <browser>를 통해 이루어집니다.

Fennec은 조금 다른 접근 방법을 취하고 있습니다. <browser> 엘리먼트가 여전히 HTML을 렌더링하는데 사용되지만, 숨겨진 오프스크린(offscreen) 역할을 합니다. 실제 화면에 보여지는 웹페이지는 primary display surface 역할을 하는 <canvas> 엘리먼트에 그려지며, 만족할 만한 수준의 성능으로 panning과 zooming을 쉽게 사용하도록 합니다. 탭 브라우징 환경은 현재 열린 <browser> 엘리먼트를 나타내는 썸네일 영역을 사용하기 위해 생성됩니다.

<browser>의 내용은 <canvas>로 복사되고, 탭을 나타내는 Thumbnail 속도를 위해 해당 <canvas>로 부터 업데이트 됩니다. 물론 <canvas>에 복사된 웹페이지 내용이 오래된 경우, <browser>로 부터 바로 업데이트 하기도 합니다.
Fennec은 DHTML로 인해 <canvas> display surface에 일어나는 모든 업데이트를 최적화하기 위해 MozAfterPaint 이벤트를 사용합니다. 그 결과, 웹페이지가 변경된 경우, 실제 변경이 일어난 부분만 업데이트되며, 전체 페이지를 다시 그리지는 않습니다. MozAfterPaint 이벤트의 역할은 DHTML로 인해 변경이 발생한 영역을 알려주어, 해당 영역만 <browser> 엘리먼트에서 <canvas> display surface로 업데이트가 가능하도록 합니다. 처음 Mozilla에 MozAfterPaint 이벤트가 없었을 때는, DHTML로 변경된 페이지를 반영하기 위해 특정 시간 간격으로 전체 <canvas> display surface를 업데이트 해야했습니다.

Fennec의 모든 UI 엘리먼트는 <stack>의 자식입니다. 이로 인해 각 UI 엘리먼트가 <canvas> display surface를 기준으로 서로에 관하여 고정된 위치를 갖게 합니다. (즉, 위 그림에서 볼 수 있듯이 좌우측 도구 막대와 URL바가 가운데 <canvas> display surface를 기준으로 고정된 위치를 갖습니다)
Fennec은 각각의 UI 엘리먼트의 좌우 움직임(panning) 효과를 주기 위해 WidgetStack.js라는 JavaScript Helper 오브젝트를 사용합니다. WidgetStack.js는 또한 Content 영역에 대한 크기를 관리합니다. 대부분, 좌우 도구 막대는 content display surface 양변에 붙어 있습니다. 웹페이지는 각각 서로 다른 width와 height값을 갖습니다. 그래서 웹페이지 폭이 변함에 따라 오른쪽 도구 막대도 함께 이동합니다. 이는 웹페이지가 넓은 경우, 도구 막대를 제대로 위치시키기 위해 좀 더 좌우로 이동(panning)시킨다는 것을 의미합니다.
Fennec은 대화상자를 가능한 사용하지 않고 있습니다. 플랫폼에 의해 사용되는 경우도 있지만, 모두 제거할 예정입니다. 대화상자 대신에, Fennec은 사용자와 상호 작용할 수 있는 UI를 사용합니다. Firefox가 modeless notificaton box와 content내 에러 페이지를 보여주는 것과 비슷합니다.
대화상자 또는 또 다른 창이 사용될 수 있는 상황에서, Fennec은 대체로 pseudo-panel을 화면에 보여줍니다. Fennec은 성능상의 이유로 실제 <panel> 엘리먼트를 사용하지 않습니다. 대신, <vbox>에 원하는 UI를 포함시켜 화면에 보여줍니다. 이와 같은 <vbox>는 <stack>엘리먼트의 자식으로 관리되어 필요한 곳에 위치시킬 수 있으며, 브라우저의 시작 성능 향상을 위해 필요할 때까지 숨어있을 수 있습니다.
몇몇 예로, 즐겨찾기 리스트, 즐겨찾기 편집기, 툴 패널(Add-ons, Preferences, 다운로드)이 그런 방식으로 구현되어 있습니다. 이들 엘리먼트는 도구막대와 매우 유사하지만, WidgetStack.js에 의해 관리되는 것은 아닙니다.
Panning은 단지 Content 영역이 아닌 전체 UI를 이동시켜, 도구막대와 Content는 별개가 아닌 하나로 움직입니다.마치 손가락으로 전체 브라우저를 움직이는 것 같은 느낌을 받게 됩니다.
<canvas> display surface에는 전체 웹 페이지에서 화면에 보여지는 부분만 나타납니다. 하지만 실제로 화면에 보여지는 부분 보다 조금 더 많이 <canvas>에 그려지게 됩니다. 이것은 panning을 할 때, content영역이 움직임에 따라, 화면 밖의 부분을 바로 보여주도록 합니다.
Panning이 전체 UI를. 움직이는 동안, zooming은 단지 content영역에만 영향을 줍니다. 그러나, zoom될 때, content가 커지고, 그래서 오른쪽 도구막대는 오른쪽으로 더 멀어져 보입니다.
메인창 위에 크롬 UI를 띄우기 위해 <panel>엘미런트를 사용하는 것은 자칫 성능 저하를 부를 수 있습니다. 사실, OS의 네이티브 창을 생성하는 XUL 엘리먼트는 느리게 동작합니다. Firefox경우, awesomerbar의 자동 완성 리스트는 현재 <panel>을 사용하고 있습니다. 자동완성 리스트를 메인 <stack>안에 <vbox>로 다시 구현하였더니, 그 결과는 드라마틱합니다. 리스트가 정말 빠르게 나타나지요.
상태를 기반으로 변경되는 UI를 만드는 간단한 방법은 하나의 엘리먼트가 아닌 두개 또는 그 이상의 엘리먼트를 겹쳐 놓고 전환하여 보여주는 것 입니다. 유용하긴 하지만, 보여주고 감추는 작업이 느릴 수 있습니다. 그래서 가능한 이런 방법은 피하고 같은 기능을 구현할 수있는 다른 방법을 찾는 것이 좋습니다.
Firefox의 URL바가 좋은 예입니다. 현재 웹페이지를 보여줄 떄, URL 바는 <description> 엘리먼트입니다. 하지만 사용자가 새로운 URL을 입력할 때는 <textbox>엘리먼트가 됩니다. 이렇게 XUL 엘리먼트를 보이고 감추는 작업에는 느낄 수 있을 정도의 시간이 걸리고, 페이지 로딩 시간에 영향을 줄 수 있습니다. Fennec에서 URL바는 언제나 <textbox>이며, "caption"모드로 전환하기 위해 readOnly property가 사용됩니다.
유사한 상황이 favicon indicator(웹사이트 아이콘)에서도 있었습니다. Fennec은 초기에 throbber(로딩 애니메이션)과 website의 favicon을 위해 두개의 <image>엘리먼트를 갖는 <stack>를 사용했습니다. 다시 말해, 상황에 따라 이미지를 보여주거나 감추었는데, 당시에는 <stack> 엘리먼트가 느렸습니다. 그래서, 제거하니까, 페이지 로딩이 좀 더 빨라보였습니다. 하지만, favicon 이미지를 throbber 이미지로 교체하는데, 로딩 시간이 걸리기 때문에, show/hide 코드를 제거해서 얻는 이득이 별로 없었습니다. 결국, 두 <image> 엘리먼트는 유지되었습니다.
앞에서 설명했듯이, Fennec은 <browser> 엘리먼트의 컨텐트를 <canvas> dispay에 복사합니다. 브라우저 컨텐트를 Canvas에 업데이트하는 것은 모바일 기기에서는 그렇게 싼 비용이 아닙니다. 각각의 drawWindow 호출에 약 300~400ms 이내의 시간을 소요합니다. 반면, drawImage는 보다 빨라서 약 100ms 이내 입니다. Fennec은 탭 thumbnail을 업데이트 하기 위해 가능한 drawImage를 사용합니다.
Fennec은 또한 메인 Canvas Display surface에 대한 모든 DHTML 업데이트를 최적화하기 위해 MozAfterPaint 이벤트를 사용합니다. 이는 drawWindow 함수의 호출을 최소화하고, 전체 canvas를 다시 그리지 않게 합니다.
브라우저가 페이지를 로딩하는 동안 처리할 어떤 작업이 발생하면 잠재적으로 성능에는 좋지 않습니다. 이는 페이지 로드 이벤트가 처리되면서 또 다른 일에 시간을 소모하기 때문입니다. 사용자는 가능한 빨리 웹페이지를 사용하려고 합니다. 그래서 Fennec은 심지어 웹페이지 로딩이 완료될 때까지 favicon 업데이트를 지연시키기도 합니다.
또한, Fennec은 페이지가 로딩되자 마자, 전화번호 텍스트를 tel: 링크로 변경하는 작업을 수행하고 있는데, 시간이 약간 걸렸습니다. 이 작업 때문에 사용자는 일정 시간 동안 웹페이지를 사용하지 못하게 되었고, 이 기능은 다시 구현되어 좀 더 빨라졌습니다. 현재 더 이상의 지연 현상은 존재하지 않으며, 사용자는 좀 더 빠르게 웹페이지를 사용할 수 있게 되었습니다.
모질라 플랫폼에서 사용하는 몇몇 file I/O 코드 중 Fennec에서 느린 부분이 있었는데, 보통 시작할 때 문제가 있었습니다. 모바일 기기에서 file I/O는 보통 milisecond 단위로 측정하는 것을 잊어서는 안됩니다. 그러므로, 가능한 불필요한 I/O를 줄이도록 노력해야 합니다. Fennec은 Alpha2에서 cold start 하는데 7~8초 정도 걸리는데, Alpha1보다 30초 정도 향상된 것 입니다.
번역후기
Fennec은 참 고집스럽게 모질라의 기술적 이상(?)을 따르고 있습니다. 기술적 이상이라고 하는 것이 맞는 표현인지는 잘 모르겠습니다. 당장 성능 최적화를 위해 빠를 길을 선택하기 보다는 플랫폼 관점에서 Firefox와 다른 XUL 애플리케이션이 함께 좋아질 수 있도록 개선하려고 노력하는 것입니다. 문제를 피해 가기보다는 문제를 전체 모질라 개잘자들에게 이슈와 시키고 이를 합리적으로 해결합니다.
MozAfterPaint 이벤트가 대표적인 예입니다. 이것은 Layout엔진에도 변경이 일어나므로 Gecko을 담당하는 해커의 도움으로 개발되었습니다. 사실 웹페이지 렌더링을 Canvas를 사용하는 부분도 처음에 논란이 많았습니다. 하지만 Panning이나 Zooming을 제대로 구현하려면 Canvas 이외에는 방법이 없었습니다. 이것은 iPhone도 마찬가지입니다. iPhone도 웹페이이지를 이미지로 렌더링해서 빠른 Panning이 가능한 것입니다. 현재 Fennec이 느린 부분도 Canvas가 HW가속을 받으면 많이 해결될 것입니다.
그리고 XUL UI를 포기하지 않고 모질라의 장점인 Add-ons에 큰 투자를 하는 부분입니다. 사실 일부 UI는 네이티브 UI를 사용하면 쉽게 기능을 구현할 수 있습니다. File Open이 대표적이라 하겠네요. 하지만 이도 XUL로 구현하려고 합니다. 아무래도 여러 플랫폼을 지원하다 보니, UI 일관성을 위해서도 필요할 것입니다.
하지만 이상이라고 표현한 것은 현실은 좀 다르다는 것입니다. 좀 더 많은 사람들이 Fennec을 이용하려면 좀 더 저 사양의 모바일 기기에서도 Fennec을 사용할 수 있어야 합니다. 이를 위해 각 모바일 플랫폼에도 좀 더 최적화되어야 합니다. 하기만 아직 적은 인력으로 모든 것을 다할 수 없는 것도 현실입니다.
Fennec의 개발 배경
Fennec은 특별히 터치 스크린(touch screen)를 제공하는 모바일(Mobile) 기기를 위해 설계된 XUL기반의 웹브라우저입니다. Firefox와 Mozilla 플랫폼의 많은 부분을 서로 공유하고 있는데, 같은 HTML Rendering Engine을 사용할 뿐만 아니라 확장기능(Add-ons) 지원, 다운로드 관리, 즐겨찾기 및 히스토리, 자바스크립트 엔진(JIT Support)을 공유하고 있습니다.
이렇게 플랫폼 기반은 같지만, Front-end UI는 완전히 다릅니다. Fennec은 작은 화면에 낮은 CPU와 메모리, 키보드가 없이 터치스크린을 위해 설계되었습니다. 이러한 UI 크기 차이로 Firefox UI를 오버레이(overlay)하고 있는 add-ons의 경우 Fennec에서 동작하려면 포팅 작업이 필요하고, 터치 기반의 UI를 가진 모바일 기기에서 만족할 만한 성능에 촛점을 맞춘 결과, 다소 특히한 XUL 구조를 갖고 있습니다.
애플리케이션 구조
브라우징
Fennec과 Firefox는 HTML을 보여주는 방식이 아주 다릅니다. Firefox는 탭(tab)브라우징 환경을 지원하기 위해 <tabbrowser>라는 XUL 엘리먼트를 사용합니다. <tabbrower>는 composite control로, 수정된 <tabbox>엘리먼트 안에 포함된 <browser>엘리먼트로 구성되어 있습니다. 주요 동작은 <browser>를 통해 이루어집니다.

Fennec은 조금 다른 접근 방법을 취하고 있습니다. <browser> 엘리먼트가 여전히 HTML을 렌더링하는데 사용되지만, 숨겨진 오프스크린(offscreen) 역할을 합니다. 실제 화면에 보여지는 웹페이지는 primary display surface 역할을 하는 <canvas> 엘리먼트에 그려지며, 만족할 만한 수준의 성능으로 panning과 zooming을 쉽게 사용하도록 합니다. 탭 브라우징 환경은 현재 열린 <browser> 엘리먼트를 나타내는 썸네일 영역을 사용하기 위해 생성됩니다.

<browser>의 내용은 <canvas>로 복사되고, 탭을 나타내는 Thumbnail 속도를 위해 해당 <canvas>로 부터 업데이트 됩니다. 물론 <canvas>에 복사된 웹페이지 내용이 오래된 경우, <browser>로 부터 바로 업데이트 하기도 합니다.
Fennec은 DHTML로 인해 <canvas> display surface에 일어나는 모든 업데이트를 최적화하기 위해 MozAfterPaint 이벤트를 사용합니다. 그 결과, 웹페이지가 변경된 경우, 실제 변경이 일어난 부분만 업데이트되며, 전체 페이지를 다시 그리지는 않습니다. MozAfterPaint 이벤트의 역할은 DHTML로 인해 변경이 발생한 영역을 알려주어, 해당 영역만 <browser> 엘리먼트에서 <canvas> display surface로 업데이트가 가능하도록 합니다. 처음 Mozilla에 MozAfterPaint 이벤트가 없었을 때는, DHTML로 변경된 페이지를 반영하기 위해 특정 시간 간격으로 전체 <canvas> display surface를 업데이트 해야했습니다.
크롬(Chrome) 엘리먼트

Fennec의 모든 UI 엘리먼트는 <stack>의 자식입니다. 이로 인해 각 UI 엘리먼트가 <canvas> display surface를 기준으로 서로에 관하여 고정된 위치를 갖게 합니다. (즉, 위 그림에서 볼 수 있듯이 좌우측 도구 막대와 URL바가 가운데 <canvas> display surface를 기준으로 고정된 위치를 갖습니다)
Fennec은 각각의 UI 엘리먼트의 좌우 움직임(panning) 효과를 주기 위해 WidgetStack.js라는 JavaScript Helper 오브젝트를 사용합니다. WidgetStack.js는 또한 Content 영역에 대한 크기를 관리합니다. 대부분, 좌우 도구 막대는 content display surface 양변에 붙어 있습니다. 웹페이지는 각각 서로 다른 width와 height값을 갖습니다. 그래서 웹페이지 폭이 변함에 따라 오른쪽 도구 막대도 함께 이동합니다. 이는 웹페이지가 넓은 경우, 도구 막대를 제대로 위치시키기 위해 좀 더 좌우로 이동(panning)시킨다는 것을 의미합니다.
Fennec은 대화상자를 가능한 사용하지 않고 있습니다. 플랫폼에 의해 사용되는 경우도 있지만, 모두 제거할 예정입니다. 대화상자 대신에, Fennec은 사용자와 상호 작용할 수 있는 UI를 사용합니다. Firefox가 modeless notificaton box와 content내 에러 페이지를 보여주는 것과 비슷합니다.
대화상자 또는 또 다른 창이 사용될 수 있는 상황에서, Fennec은 대체로 pseudo-panel을 화면에 보여줍니다. Fennec은 성능상의 이유로 실제 <panel> 엘리먼트를 사용하지 않습니다. 대신, <vbox>에 원하는 UI를 포함시켜 화면에 보여줍니다. 이와 같은 <vbox>는 <stack>엘리먼트의 자식으로 관리되어 필요한 곳에 위치시킬 수 있으며, 브라우저의 시작 성능 향상을 위해 필요할 때까지 숨어있을 수 있습니다.
몇몇 예로, 즐겨찾기 리스트, 즐겨찾기 편집기, 툴 패널(Add-ons, Preferences, 다운로드)이 그런 방식으로 구현되어 있습니다. 이들 엘리먼트는 도구막대와 매우 유사하지만, WidgetStack.js에 의해 관리되는 것은 아닙니다.
Panning/Zooming
Panning은 단지 Content 영역이 아닌 전체 UI를 이동시켜, 도구막대와 Content는 별개가 아닌 하나로 움직입니다.마치 손가락으로 전체 브라우저를 움직이는 것 같은 느낌을 받게 됩니다.
<canvas> display surface에는 전체 웹 페이지에서 화면에 보여지는 부분만 나타납니다. 하지만 실제로 화면에 보여지는 부분 보다 조금 더 많이 <canvas>에 그려지게 됩니다. 이것은 panning을 할 때, content영역이 움직임에 따라, 화면 밖의 부분을 바로 보여주도록 합니다.
Panning이 전체 UI를. 움직이는 동안, zooming은 단지 content영역에만 영향을 줍니다. 그러나, zoom될 때, content가 커지고, 그래서 오른쪽 도구막대는 오른쪽으로 더 멀어져 보입니다.
성능 관련 코딩 가이드라인
패널(Panels)
메인창 위에 크롬 UI를 띄우기 위해 <panel>엘미런트를 사용하는 것은 자칫 성능 저하를 부를 수 있습니다. 사실, OS의 네이티브 창을 생성하는 XUL 엘리먼트는 느리게 동작합니다. Firefox경우, awesomerbar의 자동 완성 리스트는 현재 <panel>을 사용하고 있습니다. 자동완성 리스트를 메인 <stack>안에 <vbox>로 다시 구현하였더니, 그 결과는 드라마틱합니다. 리스트가 정말 빠르게 나타나지요.
엘리먼트 보이기/감추기
상태를 기반으로 변경되는 UI를 만드는 간단한 방법은 하나의 엘리먼트가 아닌 두개 또는 그 이상의 엘리먼트를 겹쳐 놓고 전환하여 보여주는 것 입니다. 유용하긴 하지만, 보여주고 감추는 작업이 느릴 수 있습니다. 그래서 가능한 이런 방법은 피하고 같은 기능을 구현할 수있는 다른 방법을 찾는 것이 좋습니다.
Firefox의 URL바가 좋은 예입니다. 현재 웹페이지를 보여줄 떄, URL 바는 <description> 엘리먼트입니다. 하지만 사용자가 새로운 URL을 입력할 때는 <textbox>엘리먼트가 됩니다. 이렇게 XUL 엘리먼트를 보이고 감추는 작업에는 느낄 수 있을 정도의 시간이 걸리고, 페이지 로딩 시간에 영향을 줄 수 있습니다. Fennec에서 URL바는 언제나 <textbox>이며, "caption"모드로 전환하기 위해 readOnly property가 사용됩니다.
유사한 상황이 favicon indicator(웹사이트 아이콘)에서도 있었습니다. Fennec은 초기에 throbber(로딩 애니메이션)과 website의 favicon을 위해 두개의 <image>엘리먼트를 갖는 <stack>를 사용했습니다. 다시 말해, 상황에 따라 이미지를 보여주거나 감추었는데, 당시에는 <stack> 엘리먼트가 느렸습니다. 그래서, 제거하니까, 페이지 로딩이 좀 더 빨라보였습니다. 하지만, favicon 이미지를 throbber 이미지로 교체하는데, 로딩 시간이 걸리기 때문에, show/hide 코드를 제거해서 얻는 이득이 별로 없었습니다. 결국, 두 <image> 엘리먼트는 유지되었습니다.
캔바스와 썸네일 (Canvas and Thumbnails)
앞에서 설명했듯이, Fennec은 <browser> 엘리먼트의 컨텐트를 <canvas> dispay에 복사합니다. 브라우저 컨텐트를 Canvas에 업데이트하는 것은 모바일 기기에서는 그렇게 싼 비용이 아닙니다. 각각의 drawWindow 호출에 약 300~400ms 이내의 시간을 소요합니다. 반면, drawImage는 보다 빨라서 약 100ms 이내 입니다. Fennec은 탭 thumbnail을 업데이트 하기 위해 가능한 drawImage를 사용합니다.
Fennec은 또한 메인 Canvas Display surface에 대한 모든 DHTML 업데이트를 최적화하기 위해 MozAfterPaint 이벤트를 사용합니다. 이는 drawWindow 함수의 호출을 최소화하고, 전체 canvas를 다시 그리지 않게 합니다.
Post-Pageload Work
브라우저가 페이지를 로딩하는 동안 처리할 어떤 작업이 발생하면 잠재적으로 성능에는 좋지 않습니다. 이는 페이지 로드 이벤트가 처리되면서 또 다른 일에 시간을 소모하기 때문입니다. 사용자는 가능한 빨리 웹페이지를 사용하려고 합니다. 그래서 Fennec은 심지어 웹페이지 로딩이 완료될 때까지 favicon 업데이트를 지연시키기도 합니다.
또한, Fennec은 페이지가 로딩되자 마자, 전화번호 텍스트를 tel: 링크로 변경하는 작업을 수행하고 있는데, 시간이 약간 걸렸습니다. 이 작업 때문에 사용자는 일정 시간 동안 웹페이지를 사용하지 못하게 되었고, 이 기능은 다시 구현되어 좀 더 빨라졌습니다. 현재 더 이상의 지연 현상은 존재하지 않으며, 사용자는 좀 더 빠르게 웹페이지를 사용할 수 있게 되었습니다.
File I/O
모질라 플랫폼에서 사용하는 몇몇 file I/O 코드 중 Fennec에서 느린 부분이 있었는데, 보통 시작할 때 문제가 있었습니다. 모바일 기기에서 file I/O는 보통 milisecond 단위로 측정하는 것을 잊어서는 안됩니다. 그러므로, 가능한 불필요한 I/O를 줄이도록 노력해야 합니다. Fennec은 Alpha2에서 cold start 하는데 7~8초 정도 걸리는데, Alpha1보다 30초 정도 향상된 것 입니다.
번역후기
Fennec은 참 고집스럽게 모질라의 기술적 이상(?)을 따르고 있습니다. 기술적 이상이라고 하는 것이 맞는 표현인지는 잘 모르겠습니다. 당장 성능 최적화를 위해 빠를 길을 선택하기 보다는 플랫폼 관점에서 Firefox와 다른 XUL 애플리케이션이 함께 좋아질 수 있도록 개선하려고 노력하는 것입니다. 문제를 피해 가기보다는 문제를 전체 모질라 개잘자들에게 이슈와 시키고 이를 합리적으로 해결합니다.
MozAfterPaint 이벤트가 대표적인 예입니다. 이것은 Layout엔진에도 변경이 일어나므로 Gecko을 담당하는 해커의 도움으로 개발되었습니다. 사실 웹페이지 렌더링을 Canvas를 사용하는 부분도 처음에 논란이 많았습니다. 하지만 Panning이나 Zooming을 제대로 구현하려면 Canvas 이외에는 방법이 없었습니다. 이것은 iPhone도 마찬가지입니다. iPhone도 웹페이이지를 이미지로 렌더링해서 빠른 Panning이 가능한 것입니다. 현재 Fennec이 느린 부분도 Canvas가 HW가속을 받으면 많이 해결될 것입니다.
그리고 XUL UI를 포기하지 않고 모질라의 장점인 Add-ons에 큰 투자를 하는 부분입니다. 사실 일부 UI는 네이티브 UI를 사용하면 쉽게 기능을 구현할 수 있습니다. File Open이 대표적이라 하겠네요. 하지만 이도 XUL로 구현하려고 합니다. 아무래도 여러 플랫폼을 지원하다 보니, UI 일관성을 위해서도 필요할 것입니다.
하지만 이상이라고 표현한 것은 현실은 좀 다르다는 것입니다. 좀 더 많은 사람들이 Fennec을 이용하려면 좀 더 저 사양의 모바일 기기에서도 Fennec을 사용할 수 있어야 합니다. 이를 위해 각 모바일 플랫폼에도 좀 더 최적화되어야 합니다. 하기만 아직 적은 인력으로 모든 것을 다할 수 없는 것도 현실입니다.
2009년 5월 19일 화요일
Fennec 1.0 alpha for Windows Mobile
드디어 Fennec 1.0 alpha for Winodws Mobile이 공개되었습니다. Nokia Maemo버전은 이미 베타를 끊었지만, Windows Mobile 버전은 좀 진도가 느립니다.
그 이유는 한 번 사용해보시면 알 수 있듯이 성능이 가장 큰 것 같습니다. 그 동안 치명적인 memory 부족 문제는 jemalloc을 enable하면서 해결되었고, 반응 속도도 많이 향상되었습니다. UI 모습에도 변화가 있습니다. CSS기반으로 변경되었다고 하는데, 다양한 화면 크기를 효율적으로 지원하기 위해 CSS를 도입한 것 같습니다. 그 이유 때문인지 몰라도, Windows Mobile용 Fennec의 화면 UI가 단순한 느낌을 주고 있습니다. Maemo에서도 그렇게 변경되었는지 확인을 못해봤지만, Windows Mobile에 다른 CSS가 적용된 것은 분명해 보입니다.
화면 갈무리한 것을 Maemo Beta버전과 비교해 보면 특별한 것은 없습니다. 단지 제가 갖고 있는 미라지 화면 크기인 SQVGA(320x320)를 지원하지 않는 문제가 있네요. 화면이 landscape형태로 옴니아나 HTC Pro단말에 맞게 구성되어 있습니다.
이번 Fennec에는 여러가지 Add-ons를 설치할 있는데, TwitterBar가 눈에 띄네요. Twitter의 인기를 Fennec에서도 확인할 수 있었습니다.
Twitter 페이지 Zoom-out 결과
한글과 소프트 키보드 문제
눈에 띄는 문제로는 한글이 깨지는 현상과 소프트 키보드 문제입니다. 현재 한글 페이지는 볼 수 없는 상태이고, 소프트 키보드 문제는 단추가 계속 화면에 남아서 브라우저를 가리는 부분이 문제입니다. 아마도 한글 소프트 키보드에서만 이런 문제가 나타나는 것 같습니다.
한글에 관한 문제는 역시 우리 개발자가 해결할 수 밖에 없을 것 같습니다. 한 번 살펴봐야겠습니다.
마지막으로, HTC Touch Pro에서 동작하는 시연 동영상을 공유합니다.
Fennec - alpha 1 for Windows Mobile from Madhava Enros on Vimeo.
2009년 3월 27일 금요일
Fennec 드디어 미라지에서 동작하다
jemalloc을 enable하고 Windows Mobile 용 Fennec을 정상 동작시켰다는 Blassey의 블로그를 보고 , trunk에 있는 코드를 업데이트 하여, 빌드를 다시 했습니다. cab installer를 만들어 설치를 했으나... 심하게 화면이 깨지는 현상이 나타났습니다. 상황이 더 안 좋아진 것이죠.
jemalloc이 아직 기본으로 enable되어 있지 않은 것이 문제였습니다. 다시 mozconfig파일에 "ac_add_options --enable-jemalloc" 옵션을 추가한 후, 다시 빌드하니 드디어 저도 삼성 미라지폰(i780)에서도 아래와 같이 Fennec이 동작하는 것을 확인할 수 있었습니다. :-)

그 동안 수 차례 미라지를 비롯한 옴니아에도 사용을 시도했으나 웹페이지가 화면에 그려지지 않는 현상 때문에 제대로 Fennec을 사용할 수 없었습니다.
하지만, 아직 alpha이기 (정식 릴리스된 Alpha는 아닙니다) 때문에 일반 사용자가 사용할 만한 수준은 못 됩니다. 특히 성능 문제가 심각한데, Launching 시간이 약 60초 정도 걸리고 여러 instance가 동시에 실행되기도 합니다.
또한, 미라지에서 URL입력할 때, soft keyboard가 귀찮게 나타나고 있고, 위와 같이 화면에 IME 버튼이 계속 남아 있는 현상도 있습니다. 보시다시피 한글도 제대로 표시가 안되고 있고요.
아직 갈 길이 멀기 때문에 열심히 bugzilla에 이러한 현상을 보고하고 문제를 해결해 보려고 합니다.
jemalloc이 아직 기본으로 enable되어 있지 않은 것이 문제였습니다. 다시 mozconfig파일에 "ac_add_options --enable-jemalloc" 옵션을 추가한 후, 다시 빌드하니 드디어 저도 삼성 미라지폰(i780)에서도 아래와 같이 Fennec이 동작하는 것을 확인할 수 있었습니다. :-)
그 동안 수 차례 미라지를 비롯한 옴니아에도 사용을 시도했으나 웹페이지가 화면에 그려지지 않는 현상 때문에 제대로 Fennec을 사용할 수 없었습니다.
하지만, 아직 alpha이기 (정식 릴리스된 Alpha는 아닙니다) 때문에 일반 사용자가 사용할 만한 수준은 못 됩니다. 특히 성능 문제가 심각한데, Launching 시간이 약 60초 정도 걸리고 여러 instance가 동시에 실행되기도 합니다.
또한, 미라지에서 URL입력할 때, soft keyboard가 귀찮게 나타나고 있고, 위와 같이 화면에 IME 버튼이 계속 남아 있는 현상도 있습니다. 보시다시피 한글도 제대로 표시가 안되고 있고요.
아직 갈 길이 멀기 때문에 열심히 bugzilla에 이러한 현상을 보고하고 문제를 해결해 보려고 합니다.
2009년 3월 22일 일요일
Fennec 1.0 beta 1 주요 추가 기능의 모습
Fennec 1.0 beta 1이 3월 17일에 공개되었습니다. 현재 Nokia N810만 지원하며 데스크탑에서 테스트 용도로 사용할 수 있도록 윈도, Mac OSX, Linux용이 함께 공개되었습니다.
beta에서 함께 공개될 것으로 기대한 Windows Mobile 6.1용 Fennec은 결국 공개가 안되었네요. 물론 현재 동작은 가능하지만, 대부분의 단말에서 메모리 부족으로 인해 웹페이지가 제대로 그려지지 못하는 문제로 아직 공개를 못하고 있습니다. Jemalloc을 활성화시키는 것 만이 유일한 해결책이라고 합니다.
jemalloc은 이미 Firefox3.1에 적용되었으며 Memory 단편화 현상을 줄여주어 오랜 시간 동안 브라우징해도 메모리가 계속 늘어나는 현상을 방지하고 있습니다. 이미 FreeBSD에서 그 효과를 인정 받았습니다.
이번 베타에서는 다음과 같은 새 Feature가 추가되었습니다.
- TraceMonkey, Mozilla's new JavaScript engine
- Faster application start-up time
- Faster panning
- Faster zooming
- Initial implementation of bookmark folders and bookmark editing
- Support for plug-ins
몇가지 Feature를 실제 구현된 모습으로 소개하면 다음과 같습니다.
TraceMonkey 지원
TraceMonkey는 이미 Firefox 3.1 Beta에서 지원하기 시작하여 벌써 그 효과를 몸소 체험한 분도 많을 것입니다. 자바스크립트를 처음 실행한 후, profiling을 하여 병목 지점을 찾아 그 부분은 네이티브 코드로 컴파일하고, 이후에는 스크립트가 아닌 네이티브 코드를 실행시켜 성능을 한 단계 끌어올렸습니다. 덕분에 XUL로 개발된 UI의 반응속도가 상당히 개선되었습니다.
플래시 지원
N810에서 이미 지원하고 있던 Flash를 Fennec에서 사용할 수 있게되었습니다. 버전이 낮아서 잘 안돌아가는 Flash도 있지만, 위와 같이 Youtube 동영상도 볼 수 있습니다. Flash는 Plug-in형태로 구현되었고, 다른 기능도 Plug-in으로 구현되어 추가할 수 있게 되었습니다.
Bookmark 편집 기능
당연한 기능이지만 베타에서 와서 지원하게 되었습니다.
암호 관리 기능
Mobile 환경에서 더 편리하게 웹서비스를 사용하게 되었습니다.
물론, 전반적인 성능 향상으로 Zooming, Panning 속도도 눈에 띄게 빨라져서 이제 어느 정도 쓸만한 수준이 되었습니다.
아직 Mobile에서 XUL UI는 다소 무리인듯 싶으나, Fennec팀이 Startup, Canvas, XPConnect 부분에 최적화를 시도하고 있으니 앞으로도 더 빠른 성능을 기대할 수 있을 것 같습니다. 특히 Fennec은 웹페이지를 Canvas 기술을 이용해서 화면에 표시하므로 Canvas가 HW 가속을 받게 되면 놀라울 수준으로 성능이 향상되리가 예상합니다.
Windows Mobile 버전도 빨리 안정화 되어 실제로 많은 사람들이 Fennec을 사용했으면 좋겠습니다.
좀 더 자세한 정보와 윈도, Mac, Linux에서 테스트 하고 싶은 분은 릴리스 노트를 보시기 바랍니다.
2009년 3월 8일 일요일
Fennec 한글화와 개발자의 유쾌한 농담
Fennec 베타 버전이 곧 나올 것 같습니다. 현재 몇 가지 남은 bug가 있긴하지만, 조만간 해결되겠지요. 이번 베타에서는 윈도 모바일 버전도 공개될 것 같습니다. 이미 nightly build로 공개되어 있지만, 아직 maemo버전 만큼 성능이나 안전성를 확보하지 못했습니다.
Localization 작업도 많이 진행되어 벌써 19개 언어가 준비중에 있습니다.
한글화는 channy님 추천으로 제가 맡게 되었습니다. Firefox나 Thunderbird에 대한 Localization 정보는 많이 있으나, Fennec에 대한 정보는 덜 정리되어 있고, 생각 만큼 쉽지 않은 작업이였습니다.

번역하다가 예전에는 미처 발견하지 못한 재밌는 사실을 발견했는데,
그림 자동으로 읽기를 "Makes websites pretty"라고,
플러그인 사용을 "Make website annoying"라고,
쿠키 저장을 "Delicious deliacies"라고 설명했습니다.
"웹사이트 보기좋게", "웹을 짜증나게 만들다", "맛있는 먹거리"라고 번역해야 할까요? 일단 저도 한글로 번역은 했습니다. 사실 이렇게까지 해야할까 나름 고민도 했지만요..
하여간 플러그인에 대한 모질라 개발자들의 속내를 살필 수 있는 유쾌한 농담을 볼 수 있어서 좋았습니다. 그런데, 이러한 농담의 시작은 꽤나 역사가 깊은(?) 것 같습니다. 아마 베타 버전이 나오면 이러한 농담도 볼 수 없겠지요. :-)
현재, Fennec의 L10n 작업은 가능한 Firefox를 참고해서 동일한 번역 결과가 나오도록 맞추고 있습니다. 더 다듬어서 베타 버전에는 한글화된 Fennec을 만날 수 있도록 노력해보겠습니다.
Localization 작업도 많이 진행되어 벌써 19개 언어가 준비중에 있습니다.
한글화는 channy님 추천으로 제가 맡게 되었습니다. Firefox나 Thunderbird에 대한 Localization 정보는 많이 있으나, Fennec에 대한 정보는 덜 정리되어 있고, 생각 만큼 쉽지 않은 작업이였습니다.
번역하다가 예전에는 미처 발견하지 못한 재밌는 사실을 발견했는데,
그림 자동으로 읽기를 "Makes websites pretty"라고,
플러그인 사용을 "Make website annoying"라고,
쿠키 저장을 "Delicious deliacies"라고 설명했습니다.
"웹사이트 보기좋게", "웹을 짜증나게 만들다", "맛있는 먹거리"라고 번역해야 할까요? 일단 저도 한글로 번역은 했습니다. 사실 이렇게까지 해야할까 나름 고민도 했지만요..
하여간 플러그인에 대한 모질라 개발자들의 속내를 살필 수 있는 유쾌한 농담을 볼 수 있어서 좋았습니다. 그런데, 이러한 농담의 시작은 꽤나 역사가 깊은(?) 것 같습니다. 아마 베타 버전이 나오면 이러한 농담도 볼 수 없겠지요. :-)
현재, Fennec의 L10n 작업은 가능한 Firefox를 참고해서 동일한 번역 결과가 나오도록 맞추고 있습니다. 더 다듬어서 베타 버전에는 한글화된 Fennec을 만날 수 있도록 노력해보겠습니다.
2009년 2월 9일 월요일
FOSDEM 2009 소식
사진: Teemu Mäntynen
FOSDEM 2009 행사가 지난주에 끝났습니다. 비록 참석은 못했지만 생생한 행사 현장을 여러 블로그를 통해 확인할 수 있었습니다. FODSEM(Free and Open Source Software Developer's European Meeting)은 말 그대로 유럽의 오픈소스 개발자가 모이는 가장 큰 행사입니다. 관련 프로젝트가 무척 다양한데, 미국에서 열리는 OSCON(O'Reilly Open Source Convention)과 비교할 수 있습니다.
Track으로 진행된 프로젝트를 보시면,
KDE, GNOME, Mozilla, X.org, Fedora+CentOS, OpenSUSE, BSD+PostgreSQL, GNUStep, Jabber, Debian, Ada, Free Java, OpenOffice, Drupal, Ruby & Rails, MySQL, Linux Kernel
기타로
OpenMoko, Maemo, CMake, Webkit, Xfce 등에 관한 Session이 열렸습니다.
특히 Mozilla 관련 Session이 많았는데,(개인적인 관심사이다 보니 눈에 띄는군요)
- Mozilla Europe
- Mozilla Foundation
- Mozilla and Universities
- What's after Firefox 3.1
- Community Sites Project
- Building XUL communities
- SeaMonky
- Overview of Mozilla QA
- Oni
- Rising to the Sun(bird)
- Thunderbird3
- Prism
- Fennec
- Embedding
- Mozilla headless back-end
- Events/EduCamp@FOSDEMa2009
사진: Teemu Mäntynen(Firefox 티셔츠를 입으신 할머니 모습. 감동적인 사진이군요..)
참고로, FOSDEM은 발표 동영상을 항상 공개하고 있습니다. 2009년은 아직 공개되어 있지 않지만, 예전 행사자료를 볼 수 있습니다.
내년에는 꼭 참가해보고 싶네요.
참고
2009년 1월 18일 일요일
Mobile Firefox Fennec의 최근 모습 (09.1/11)
올해 말 릴리스를 목표로 Mobile Firefox Fennec이 열심히 개발되고 있습니다. 최근 모습(alpha2)에서 웬만한 기능들이 구현되어 있음을 확인할 수 있습니다.
물론 성능은 iPhone Safari와 차이가 많이 나는데, 아직 N810이 HW가속을 지원하지 않기 때문입니다.
UI 자체는 Safari보다 훨씬 혁신적이라고 할 수 있습니다. Mozilla의 UX팀의 작품입니다. 작년에 Mozilla Corporation에서 UX전문가를 많이 채용했습니다. 이들 활동 덕분에 Firefox를 비롯한 Fennec의 사용성이 개선되고 있습니다. Fennec의 경우 N810의 성능은 그다지 고려하지 않은 UI로 구현된 것 같기도 한데, 앞으로 Nokia에서 HW가속을 지원하는 새로운 단말이 나오면 성능 문제는 해결될 것이라고 합니다.

처음 시작하면 위와 같은 모습으로 실행이 됩니다. 기존 브라우저에서는 볼 수 없는 모습입니다.

Fennec은 현재 Nokia N810에 최적화되어 있습니다. 해상도는 800X480에 맞추어져 있으며 Full Screen으로 동작시켜야 제대로 브라우징을 할 수 있습니다. 위 모습은 New York Times에 접속한 모습입니다. 처음 웹페이지를 열면 800px에 맞게 zoom-out이 됩니다. 이후에 iPhone처럼 원하는 영역을 두번 클릭하면 아래와 같이 확대되어 볼 수 있습니다.

속도는 좀 느립니다. 2~3초 정도, 웹페이지 복잡도에 따라 다르지만, New York Time의 경우 시간이 좀 걸립니다.
탭을 보려거나 툴바를 보려면 웹페이지를 좌우로 드래그 해야합니다. 우측에서는 탭을, 좌측에서는 툴바를 볼 수 있습니다.

탭의 모습. 탭을 추가하거나 삭제할 수 있습니다.

툴바의 모습. Preference, add-ons, plug-in을 보려면 툴바 하단에 있는 단추를 누르면 됩니다. 아래와 같이 UI가 확장되면 새로운 화면이 나타납니다.

이미 몇 개의 Fennec용 Add-on이 개발되어 있는 것을 볼 수 있습니다. Theme는 아직 지원하지 않는 것 같습니다.

이번 alpha2에 위와 같이 Preference도 구현되었지만, 아직 Proxy는 설정할 수 없습니다.

Firefox3에서 처음 개발된 Awesome Bar도 Fennec에서 잘 동작합니다.

다음에 접속해 보니, 한글도 잘 나옵니다. 물론 아직, 한글화는 되어있지 않습니다.
이상으로 2009년 1월 11일 빌드로 Fennec의 최근 모습을 살펴보았습니다. 현재까지는 N810만 지원해서 국내에서는 사용해볼 기회는 거의 없습니다. 다행히 Windows와 Linux Desktop 버전을 공개해서 테스트 용도로 사용해볼 수 있습니다. 현재 Windows Mobile용으로 열심히 포팅중에 있고 어느 정도 동작에 성공했으니 앞으로 Windows Mobile 버전도 공식 릴리스될 것입니다. 이 때가 되면 국내에서도 사용자가 점차 늘어날 전망입니다. 그런데 UI가 800X480에 맞추어져 있고, 이 보다 작은 화면을 가진 Windows Mobile을 지원하는 것이 숙제라고 할 수 있습니다.
처음 Firefox 1.0이 나올 때도 그러했듯이 그렇게 폭발적인 반응이 있지는 않았습니다. Fennec도 1.0이 올해말에 나오겠지만, iPhone Safari만큼의 성능과 사용성을 보여주려면 아직 해야할 일이 많습니다. Firefox만큼 하려면 더 열심히 뛰어야겠습니다. 많은 관심 부탁 드리겠습니다~
물론 성능은 iPhone Safari와 차이가 많이 나는데, 아직 N810이 HW가속을 지원하지 않기 때문입니다.
UI 자체는 Safari보다 훨씬 혁신적이라고 할 수 있습니다. Mozilla의 UX팀의 작품입니다. 작년에 Mozilla Corporation에서 UX전문가를 많이 채용했습니다. 이들 활동 덕분에 Firefox를 비롯한 Fennec의 사용성이 개선되고 있습니다. Fennec의 경우 N810의 성능은 그다지 고려하지 않은 UI로 구현된 것 같기도 한데, 앞으로 Nokia에서 HW가속을 지원하는 새로운 단말이 나오면 성능 문제는 해결될 것이라고 합니다.
처음 시작하면 위와 같은 모습으로 실행이 됩니다. 기존 브라우저에서는 볼 수 없는 모습입니다.
Fennec은 현재 Nokia N810에 최적화되어 있습니다. 해상도는 800X480에 맞추어져 있으며 Full Screen으로 동작시켜야 제대로 브라우징을 할 수 있습니다. 위 모습은 New York Times에 접속한 모습입니다. 처음 웹페이지를 열면 800px에 맞게 zoom-out이 됩니다. 이후에 iPhone처럼 원하는 영역을 두번 클릭하면 아래와 같이 확대되어 볼 수 있습니다.
속도는 좀 느립니다. 2~3초 정도, 웹페이지 복잡도에 따라 다르지만, New York Time의 경우 시간이 좀 걸립니다.
탭을 보려거나 툴바를 보려면 웹페이지를 좌우로 드래그 해야합니다. 우측에서는 탭을, 좌측에서는 툴바를 볼 수 있습니다.
탭의 모습. 탭을 추가하거나 삭제할 수 있습니다.
툴바의 모습. Preference, add-ons, plug-in을 보려면 툴바 하단에 있는 단추를 누르면 됩니다. 아래와 같이 UI가 확장되면 새로운 화면이 나타납니다.
이미 몇 개의 Fennec용 Add-on이 개발되어 있는 것을 볼 수 있습니다. Theme는 아직 지원하지 않는 것 같습니다.
이번 alpha2에 위와 같이 Preference도 구현되었지만, 아직 Proxy는 설정할 수 없습니다.
Firefox3에서 처음 개발된 Awesome Bar도 Fennec에서 잘 동작합니다.
다음에 접속해 보니, 한글도 잘 나옵니다. 물론 아직, 한글화는 되어있지 않습니다.
이상으로 2009년 1월 11일 빌드로 Fennec의 최근 모습을 살펴보았습니다. 현재까지는 N810만 지원해서 국내에서는 사용해볼 기회는 거의 없습니다. 다행히 Windows와 Linux Desktop 버전을 공개해서 테스트 용도로 사용해볼 수 있습니다. 현재 Windows Mobile용으로 열심히 포팅중에 있고 어느 정도 동작에 성공했으니 앞으로 Windows Mobile 버전도 공식 릴리스될 것입니다. 이 때가 되면 국내에서도 사용자가 점차 늘어날 전망입니다. 그런데 UI가 800X480에 맞추어져 있고, 이 보다 작은 화면을 가진 Windows Mobile을 지원하는 것이 숙제라고 할 수 있습니다.
처음 Firefox 1.0이 나올 때도 그러했듯이 그렇게 폭발적인 반응이 있지는 않았습니다. Fennec도 1.0이 올해말에 나오겠지만, iPhone Safari만큼의 성능과 사용성을 보여주려면 아직 해야할 일이 많습니다. Firefox만큼 하려면 더 열심히 뛰어야겠습니다. 많은 관심 부탁 드리겠습니다~
2008년 6월 22일 일요일
파이어폭스3, 오픈웹, 오픈 스탠다드
사진: intothefuzz Firefox3 출시 기념 포스터
파이어폭스3 출시와 모질라 재단 의장 미첼 베이커의 방한
지난 6월 17일 파이어폭스3가 출시되었고 이에 발 맞추어 모질라(Mozilla) 재단 의장이신 미첼 베이커(Mitchell Backer)씨가 방문하였습니다. 물론 한국에서 파이어폭스3(Firefox3) 출시를 기념하려고 일부러 오신 것은 아니고 OECD장관 회의에 참석차 오셨는데, 바로 이 때 파이어폭스3가 출시된 것입니다. :-)
덕분에 한국이 많은 파이어폭스 사용자로 부터 관심을 갖게 되었고 언론도 지면을 통해 미첼 베이커의 행보와 파이어폭스3 출시를 소개하였습니다. 아마도 파이어폭스가 메이저 언론에 주요 뉴스로 소개된 것이 처음이 아닐까 싶습니다.
사진: Gen Kanai 파이어폭스3 서울 파티
저는 이번에 미첼 베이커 의장과와 저녁식사를 함께 하는 가문의 영광을 누렸고 파이어폭스3 서울 파티에 참가하였습니다. 바로 옆자리에 앉아 그녀의 모든 이야기를 듣느라 산해진미가 귀찮게 느껴질 정도였습니다.
한국의 오픈웹 현황
현재 우리나라는 마이크로소프트 인터넷 익스플로러 없이는 금융거래와 인터넷 쇼핑을 할 수 없는 기이한 시장구조를 가진 이상한 나라입니다. 이번에 함께 방한한 Mozila Japan의 겐 카나이(Gen Kanai)씨가 그의 블로그에 이 사실이 처음 소개했을 때, 전세계 많은 사람들이 놀라움을 금치 못했습니다. 이상한 나라의 앨리스 수준이였죠. 그 이후, 독점의 폐해를 예로 들을 때, 우리나라의 윈도와 인터넷 익스플로러 독점이 자주 소개되곤 합니다.
이런 상황에 파이어폭스3 출시에 맞춘(?) 미첼 베이커의 방한은 지금 우리나라 오픈웹 상황에서는 단비와 같은 존재였습니다.
미첼 베이커는 오픈웹, 오픈 스탠다드, 오픈 소스의 전도사와 같은 역할을 수행해왔습니다. 많은 강연을 통해 오픈웹과 오픈스탠다드의 중요성 그리고 모질라와 파이어폭스가 어떤 역할을 하고 있는지 설명해주었습니다.
오픈웹, 오픈 스탠다드의 중요성
웹은 누구에게 통제를 받아서도 안되고 특정 업체, 특정 기술에 종속적이여도 안됩니다. 그 이유는 웹이 공기와 같은 공공재 역할을 하며 전세계 모든 사람이 소통할 수 있는 수단을 제공하기 때문입니다. 운영체제, 디바이스 종류, 브라우저 종류에 상관없이 관계없이 전세계 누구나 같은 웹을 접근하는데 있어서 제약이 없어야 합니다. 장애를 가진 분들이라도 웹에 접속하여 일반인과 마찬가지로 정보를 얻고 소통할 수 있어야 합니다.
현재 모질라 파이어폭스는 이런 환경을 제공하는데 있어서 매우 중요한 역할을 하고 있습니다. 특정 기업이나 기술에 종속되지 않고 비영리 재단과 수 많은 개발자, 사용자가 함께 전세계 누구나 웹을 같은 방식으로 쉽게 사용할 수 있도록 노력하고 있습니다.
우리가 브라우저를 바라볼때, 너무 기술적인 측면에 중점을 두지만, 다양한 언어를 지원하고 장애인을 배려하며 가벼운 사양의 디바이스에서 동작할 수 있는 브라우저를 만드는 것이 무엇보다 중요합니다. 현재 파이어폭스3는 45개의 언어를 지원하고 장애인을 위한 웹 접근성 기능도 제공하고 있습니다.
웹의 미래에 대한 투자
물론 좀 더 나은 사용자 경험을 위한 기술적 투자와 표준화 작업도 멈추어서는 안됩니다.
현재 여러 업체에서 보다 나은 사용자 경험을 위해 새로운 기술을 선보이고 있습니다. 플래시, 실버라이트가 대표적이라고 할 수 있습니다. 이들 기술도 좀 더 화려하고 편리한 브라우징 방식을 제공한다는 점에의 의의가 있지만 이 기술이 웹의 접근을 막고 사용자를 차별하게 된다고 오픈웹은 커다른 도전에 직면할 수 있습니다.
ActiveX 기술에서 볼 수 있듯이 누구에게는 너무나 손쉬운 접근 방식일 수도 있지만도, 리눅스나 맥 사용자에게는 정보를 차단하는 산성과 같은 역할을 합니다. 즉, 모든 기술적 발전은 표준화와 함께 하는 것이 중요합니다.
모든 정보가 제약없이 소통하는 그날까지
여전히 우리가 가야할 길은 멀고 험합니다. 모든 디바이스가 동일한 정보에 접근하기 어렵고 수 많은 장애인들 역시 정보 이용이 제한적입니다. 경제적 사정으로 저사양 컴퓨터를 보유하고 있는 가정에서는 플래시와 같은 UI로 만들어진 정보에 대한 접근에 어려움을 겪고 있습니다.
기술적인 문제 뿐만 아니라 주민등록 번호 없이 게시판에 글을 남길 수 없고 실명 사용을 강요당하고 있습니다. 이는 자칫 인터넷 검열과 정보 차단으로 이어질 수 있습니다.
웹은 단순히 정보 공유 차원을 넘어서 민주주의를 위한 소통의 장소로 발전하고 있습니다. 모질라가 추구하는 오픈웹, 오픈 스탠다드가 이러한 발전에 지금까지 많은 기여를 해왔고, 앞으로도 많은 역할을 할 수 있도록 관심과 응원을 기대합니다.
2008년 5월 17일 토요일
Fennec (Mobile Firefox)의 최근 모습
작년 10월 Mobile Firefox의 개발이 발표되고, 현재 커뮤니티에서는 열심히 Mobile Firefox를 개발하고 있습니다.
Mobile Firefox는 Fennec이라는 코드네임을 갖고 있는데, 사막 여우를 뜻합니다. 사막 여우 하면 만화에서도 본 적이 있을 것입니다. 보통 여우보다 작고 귀가 큰 것이 큰 특징입니다.
얼마전 개발 중인 Fennec의 코드와 빌드 방법이 공개되었습니다. 아직 Mozilla mainline에는 반영이 안되어서 빌드 방법이 다소 번거롭기는 합니다.
빌드한 후, 실행하면 다음과 같은 모습을 볼 수 있습니다.


현재 기본 브라우징에서 즐겨찾기 정도가 구현되어 있습니다. Panning은 속도가 좀 느리고 Zoom기능은 잘됐었는데, 최근 코드에서는 잘 안되네요.
Fennec은 Maemo Scratchbox환경에서 빌드가 가능하고 XUL Runner기반으로 실행됩니다. 현재 X86으로는 빌드가 잘 안되는 것으로 보아,N800/N810이 없다면 실행해보기는 힘든 것 같습니다. 조만간 빌드 방법을 정리해서 올려보겠습니다.
테스트 해보시고 커뮤니티에 피드백을 주면 좋겠습니다.
관련 글
Mobile Firefox는 Fennec이라는 코드네임을 갖고 있는데, 사막 여우를 뜻합니다. 사막 여우 하면 만화에서도 본 적이 있을 것입니다. 보통 여우보다 작고 귀가 큰 것이 큰 특징입니다.
얼마전 개발 중인 Fennec의 코드와 빌드 방법이 공개되었습니다. 아직 Mozilla mainline에는 반영이 안되어서 빌드 방법이 다소 번거롭기는 합니다.
빌드한 후, 실행하면 다음과 같은 모습을 볼 수 있습니다.
현재 기본 브라우징에서 즐겨찾기 정도가 구현되어 있습니다. Panning은 속도가 좀 느리고 Zoom기능은 잘됐었는데, 최근 코드에서는 잘 안되네요.
Fennec은 Maemo Scratchbox환경에서 빌드가 가능하고 XUL Runner기반으로 실행됩니다. 현재 X86으로는 빌드가 잘 안되는 것으로 보아,N800/N810이 없다면 실행해보기는 힘든 것 같습니다. 조만간 빌드 방법을 정리해서 올려보겠습니다.
테스트 해보시고 커뮤니티에 피드백을 주면 좋겠습니다.
관련 글
2008년 2월 19일 화요일
Firefox3 beta3 릴리스
Firefox3 beta3가 릴리스되었습니다.
저는 Firefox2 beta2부터 줄곧 사용해왔는데, 안정성에는 문제가 없었고, 단지 아직 Firefox3 베타를 지원하지 않는 확장들을 못쓰는 부분만 불편합니다.
beta2를 쓰고 있다면 자동적으로 beta3로 업데이트가 되는데, 처음으로 UI의 변화가 눈에 띄기 시작했습니다. 물론 그전 부터 조금씩 바뀌긴 했지만 도구모음이 바뀌는 수준은 아니였지요. 현재 beta4계획도 있기 때문에 바로 정식 버전이 나올 것 같지는 않고 아마도 늦은 봄이면 beta4테스트를 끝내고 정식 버전이 나오지 않을까 기대해봅니다.
참고로, 릴즈스 노트를 보시면 새로 추가되거나 바뀐 부분을 알 수 있습니다.
모질라 개발자라면, Mozilla Developer Center에 등록된 글을 보시면 좀 더 자세한 개선 사항을 알 수 있습니다.
2008년 2월 14일 목요일
아시아 오픈소스
Mozilla Corporation 소속 Gen Kanai씨가 Lift Conference에서 "Open Source in Asia"제목으로 발표한 내용을 정리해보았습니다. 참고로 Lift Conference는 기술이 사회에 미치는 영향에 대해 이야기를 나누는 행사입니다.
발표 내용은 크게 Mozilla Community in Asia와 Open source in Asia로 나눌 수 있습니다.
1. 아시아 모질라 커뮤니티
현재 아시아 지역에서 모질라 활동에 대해 소개하면, 중국과 일본은 Mozilla Corporation에서 공식적으로 지사를 운영 중이고, 한국과 대만은 커뮤니티에서 활동을 주도하고 있다고 합니다.
중국의 경우, 시장이 커지고 있는데, MS에서 일했던 Dr. Li Gong가 Mozilla China를 운영중입니다. 일본은 2000년 MozillaGumi라는 모질라 커뮤니티가 만들어졌고 2004년에 Mozilla Japan이 설립되었습니다. 현재 파이어폭스는 일본내에서 약 10~12% 점유율을 차지하고 있습니다.
한국은 윤석찬님께서 작지만 강한 커뮤니티를 이끌고 있는데, 사회적 영향으로 시장 상황이 특이합니다. 한국은 어디서나 브로드밴드의 혜택을 받을 수 있으며, 정부 주도로 e-Commerce, e-Goverment가 시작되었습니다. 하지만, 보안 트랜잭션이 필요한 전자상거래, 은행거래를 위해서는 반드시 인터넷 익스플로러를 사용해야 합니다. 이런 이유로 시장 환경은 제약적이며, 인터넷 익스플로러가 사실상 독점적 표준이 되었습니다.
2. 이시아 오픈소스
현재 아시아 지역의 회사과 비지니스에서 오픈소스를 잘 활용하고 있지만, 참여와 기여는 잘 못하고 있습니다.
리누스 토발즈가 최근 언급했듯이 세가지 장벽이 있다고 합니다.
1. 문화 (큰 장벽) => 온라인 커뮤니티를 통한 참여, 소스코드 제안/공유 이런 부분 좀 부족하죠..
2. 언어 => 주요 오픈소스 프로젝트가 사실상 영어를 사용합니다.
3. 교육 => ??
이외에 인도에는 수 많은 SW 개발자가 있음에도 불구하고 오픈소스 활동이 부족한 것은 대부분 아웃소싱된 프로젝트에 참여하고 있기 때문에 관련된 오픈소스 프로젝트나 기술에는 참여하기기 힘든 부분을 지적했습니다.
그러나, 자세히 보면 아시아도 나름 열심하고 하고 있는데,
1. 일본의 루비
2. 중국정부 주도의 홍기(Red Flag) 리눅스
3. 부탄이라는 나라가 자국 언어 지원을 위해 리눅스 기반 Dzongkha Debain Linux개발
예로 소개하였습니다. 특히 부탄이라는 나라는 인구가 2백만밖에 안되는 작은 국가이며, 고유의 문자와 입력체계를 갖고 있어 윈도에서 제대로 지원을 받지 못했습니다. 이러한 이유로 데비안 리눅스를 기반으로 자국어 리눅스를 개발하게 되었다고 합니다.
이는 작은 국가에서 오픈소스를 활용하여 그들의 언어로 그들을 위해 스스로 제어할 수 있는 운영체제를 만들 수 있는 좋은 예라고 할 수 있습니다.
다행인 것은 일본의 루비가 아시아를 대표할 만한 오픈소스 프로젝트라는 것입니다. 이 부분에 대해서 자세히 소개하더군요.
우리나라도 나름 열심히 하지만(태터툴스, 제로보드, 스프링노트 에디터 부분), 웹기반 위주이고 아직까지는 우리나라만 국한 된 듯 보여 아쉬웠습니다.
결론적으로, 아시아가 나름대로 오픈스소에 기여해 왔지만, 더 많은 활동이 필요하며 여러분의 참여와 도움이 필요하다며 발표를 마쳤습니다.
2008년 2월 11일 월요일
모질라 빌드에러...
개발할 때, 제일 싫은 것은 바로 "빌드 에러"다.
새해 첫날 우분투를 업데이트하고, 사실 이번 업데이트는 오래전부터 망설였는데, 지난 번 cairo업데이트 한 후, gtk+로 개발된 애플리케이션이 동작하지 않아 낭패를 본 경험때문이다. 이번 업데이트는 커널 부터 파이어폭스2.0, firefox-dev, apache까지 포함되어 있었다.
업데이트 한 후, 우려했던 것 처럼 문제가 발생하기 시작했다.
파이어폭스가 실행되지 않는 것이다.
joone@R2D2:~/mozilla/mozilla/obj_debuglog/dist/bin$ firefox
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 2377 error_code 3 request_code 20 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
다행히 firefox --sync 하니까 실행은 되지만 온갖 디버그 정보가 터미널에 주르륵 나타났다.
더 시급한 문제는 Firefox trunk 빌드가 안되는 부분이다. 간만에 mainline으로 부터 소스를 업데이트하고 빌드하려고 하니 에러가 발생했다.
../../../config/./nsinstall -R -m 444
/scratch/chen/X/mozilla/nsprpub/pr/include/md/
/scratch/chen/X/mozilla/build/dist/include/nspr
../../../config/./nsinstall: cannot make symbolic link
/scratch/chen/X/mozilla/build/dist/include/nspr/md: File exists
gmake[7]: *** [export] Error 1
gmake[7]: Leaving directory
경로는 다르겠지만 /dist/include/nspr/md 심볼릭 링크를 만들지 못해 발생한 에러였다.
이 문제는 크로스 컴파일할 때, 타겟을 못찾는 경우 발생한다고 한다. 그래서
ac_add_options --target=i686-linux-uclibc
위 옵션을 추가했더니 컴파일이 잘된다.
갑자기 멀쩡한 우분트가 업데이트 하나로 뭔가 이상하게 동작하기 시작했다.
새해 부터 삽질은 시작되는 듯 싶다.
새해 첫날 우분투를 업데이트하고, 사실 이번 업데이트는 오래전부터 망설였는데, 지난 번 cairo업데이트 한 후, gtk+로 개발된 애플리케이션이 동작하지 않아 낭패를 본 경험때문이다. 이번 업데이트는 커널 부터 파이어폭스2.0, firefox-dev, apache까지 포함되어 있었다.
업데이트 한 후, 우려했던 것 처럼 문제가 발생하기 시작했다.
파이어폭스가 실행되지 않는 것이다.
joone@R2D2:~/mozilla/mozilla/obj_debuglog/dist/bin$ firefox
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 2377 error_code 3 request_code 20 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
다행히 firefox --sync 하니까 실행은 되지만 온갖 디버그 정보가 터미널에 주르륵 나타났다.
더 시급한 문제는 Firefox trunk 빌드가 안되는 부분이다. 간만에 mainline으로 부터 소스를 업데이트하고 빌드하려고 하니 에러가 발생했다.
../../../config/./nsinstall -R -m 444
/scratch/chen/X/mozilla/nsprpub/pr/include/md/
/scratch/chen/X/mozilla/build/dist/include/nspr
../../../config/./nsinstall: cannot make symbolic link
/scratch/chen/X/mozilla/build/dist/include/nspr/md: File exists
gmake[7]: *** [export] Error 1
gmake[7]: Leaving directory
경로는 다르겠지만 /dist/include/nspr/md 심볼릭 링크를 만들지 못해 발생한 에러였다.
이 문제는 크로스 컴파일할 때, 타겟을 못찾는 경우 발생한다고 한다. 그래서
ac_add_options --target=i686-linux-uclibc
위 옵션을 추가했더니 컴파일이 잘된다.
갑자기 멀쩡한 우분트가 업데이트 하나로 뭔가 이상하게 동작하기 시작했다.
새해 부터 삽질은 시작되는 듯 싶다.
2008년 1월 8일 화요일
모질라(Mozilla) 일주일 완성 과정 소개
모질라 프로젝트(Mozilla Project)와 캐나다 Senecac 대학에서 그동안 함께 모질라 관련 연구와 Couresework을 운영해왔습니다.
그 결과물이 Wiki에 그대로 공개되어 있습니다. 현재 학생들의 창의적인 프로젝트 부터 다양한 기술 문서가 등록되어 있습니다. 특히, Real World Mozilla라는 lab도 마련되어 있는데, 실제 학생들이 수업에서 받는 실습 자료가 공개되어 처음 모질라를 접하는 개발자에게도 도움이 되고 있습니다.
이런 실습과정은 Mozilla Developer Center에서도 찾아볼 수 없었기 때문에 무척 유용한 자료가 아닐수 없습니다.
국내에도 다음에서 제주대학과 오픈소스 관련 교과목을 개설해서 작년 한 해 성공적으로 운영했습니다. Senecac 대학 처럼 직접 오픈소스 프로젝트와 연계하여 이런 결과물을 만들어 내고 공유가 된다면 국내 오픈소스 문화 확산에도 도움이 될 것 입니다.
참고
* 한국 공개 SW, 한걸음 더 나가기
그 결과물이 Wiki에 그대로 공개되어 있습니다. 현재 학생들의 창의적인 프로젝트 부터 다양한 기술 문서가 등록되어 있습니다. 특히, Real World Mozilla라는 lab도 마련되어 있는데, 실제 학생들이 수업에서 받는 실습 자료가 공개되어 처음 모질라를 접하는 개발자에게도 도움이 되고 있습니다.
이런 실습과정은 Mozilla Developer Center에서도 찾아볼 수 없었기 때문에 무척 유용한 자료가 아닐수 없습니다.
국내에도 다음에서 제주대학과 오픈소스 관련 교과목을 개설해서 작년 한 해 성공적으로 운영했습니다. Senecac 대학 처럼 직접 오픈소스 프로젝트와 연계하여 이런 결과물을 만들어 내고 공유가 된다면 국내 오픈소스 문화 확산에도 도움이 될 것 입니다.
참고
* 한국 공개 SW, 한걸음 더 나가기
2007년 12월 17일 월요일
Creative Commons Korea Hof Day & Korea Mozilla Community Party 2007
12월 15일 홍대 앞에서 한꺼번에 두 행사가 열렸습니다.
늘 그렇지만 이런 외부 행사를 통해 늘 새로운 영감과 정보를 얻고 저 자신을 발전시키기 위한 기회를 갖게 됩니다. 무엇보다 저와 비슷한 생각을 가진 사람들을 만난다는 기쁨이 더해지지요.
Creative Commons Korea Hof Day는 CC Korea의 법인화를 선포하고 CC 라이센스를 이용하고 관심을 갖는 다양한 계층의(블로거, 음악가, 법조인, 개발자, DSLR사용자, 컨텐츠 기획자... ) 사람들이 참여하였습니다. 홍대 클럽에서 열려서 분위기는 좋았고 음악(대학팀의 락 공연과 국내 최초로 CC License로 음반을 출시한 BUST THIS의 공연)과 어울어진 축제의 한마당이였습니다. 파티 전체가 전세계로 생중계되었고 멀리 해외 및 각계 인사들의 축하 영상도 이어졌습니다.
KoMoCo Party는 CC Korea Hof day가 끝날 즘에 열렸고 50여명의 사람들이 참석하였습니다. 파이어폭스 사용자, 웹개발자, 기획자 등 많은 분들이 참석해주셨습니다. 특히 올해는 몇 명의 여성 사용자의 참석이 눈에 띄었습니다.
간단히 자신의 소개와 저녁식사가 이어졌고 한국 모질라 커뮤니티 리더인 윤석찬님께서 모질라 프로젝트에서 대해서 소개해주셨습니다.
- Firefox 3.0 베타2 테스트 현재 진행 중이고
- 마운틴 뷰의 Mozilla Corporation 사무실 모습과 직원들의 자유스러운 모습이 소개되었고..
- 리트머스라는 테스트 툴 소개 (사용자의 참여로 테스트 수행)
- 요즘 매주 test day가 진행중인데, 세계적으로 1000여명(?) 참석
- 내년 다음, 네이버용 Firefox3가 나올 예정 (IE Tab과 IE 전용 사이트 DB 탑재)
모질라 재단도 국내 오픈웹 상황에 대해서 잘 알고 있다고 합니다. 한국은 특정 브라우저가 99%이상을 점유하고 있는 전세계 유일한 나라로서 심각한 폐해를 보여주는 대표적인 예이지요. 이 상황은 특정 브라우저 문제가 아니라 우리나라의 개발자들의 무개념 마인드와 정책을 결정하는 정부 관리자의 안일한 생각이 큰 문제라고 생각합니다.
석찬님이 이야기했듯이 모질라 프로젝트의 Moto가 바로 오픈웹입니다. 파이어폭스를 통해 좀 더 많은 사람이 오픈웹 운동에 동참하고 어떤 플랫폼, 어떤 브라우저에서 아무런 문제 없이 사용할 수 있는 참다운 웹 세상이 올 수 있도록 노력해야겠습니다. 모질라 커뮤니티가 그 중심에서 큰 역할을 할 수 있으리라 기대합니다.
바깥고리
2007년 12월 10일 월요일
미리보는 Mobile Firefox
얼마전 Mobile Firefox에 대한 개발 계획이 발표 된 이후, 현재 활발하게 개발이 진행되고 있습니다.
(오픈소스 프로젝트라 개발 상황을 요구사항 단계 부터 훤히 볼 수 있어 참 좋습니다)
최근 개발을 주도 하고 있는 Christian의 블로그에 Mobile Goal이라는 글이 소개 되었는데, 모바일 파이어폭스(Mobile Firefox)가 추구하는 방향과 주요 특징이 간략하게 소개되어 있습니다.
Firefox의 주요 장점(XUL, Add-on)을 그대로 가져가며 모바일 환경에 맞게 최적화하고 디바이스 특성에 맞는 사용자 경험을 제공하는 것이 주 목적입니다. 모바일 환경에서 XUL(XML User Inteface Language)을 유지한다는 것이 상당한 모험같습니다. 하지만 파이어폭스가 갖는 장점을 살리려면 XUL도 지원해야겠지요. 문제는 성능과 메모리 사용인데, 노키아가 microB를 개발하면서 어느 정도 성능 문제를 해결해가고 있고 현재도 노력중이라 합니다. 쓸만한 모바일 브라우저가 나오기를 기대해봅니다.
간략하게 소개하면 다음과 같습니다.
목표
다음 단계
타겟 플랫폼
사용자 경험(UX)
관련글
(오픈소스 프로젝트라 개발 상황을 요구사항 단계 부터 훤히 볼 수 있어 참 좋습니다)
최근 개발을 주도 하고 있는 Christian의 블로그에 Mobile Goal이라는 글이 소개 되었는데, 모바일 파이어폭스(Mobile Firefox)가 추구하는 방향과 주요 특징이 간략하게 소개되어 있습니다.
Firefox의 주요 장점(XUL, Add-on)을 그대로 가져가며 모바일 환경에 맞게 최적화하고 디바이스 특성에 맞는 사용자 경험을 제공하는 것이 주 목적입니다. 모바일 환경에서 XUL(XML User Inteface Language)을 유지한다는 것이 상당한 모험같습니다. 하지만 파이어폭스가 갖는 장점을 살리려면 XUL도 지원해야겠지요. 문제는 성능과 메모리 사용인데, 노키아가 microB를 개발하면서 어느 정도 성능 문제를 해결해가고 있고 현재도 노력중이라 합니다. 쓸만한 모바일 브라우저가 나오기를 기대해봅니다.
간략하게 소개하면 다음과 같습니다.
목표
- 모바일 환경에 최적화된 모질라 표준 기반의 오픈소스 브라우저 엔진 제공
- 파이어폭스의 기본 원칙인 사용하기 쉽고, 보안, 접근성을 제공하며 XUL기반 Add-on을 지원하는 Full 브라우저
- 모바일 영역에서의 모질라 커뮤니티 확산
- 개발자들이 모바일 웹 애플리케이션을 개발, 디버그, 구축하는데 필요한 도구와 문서 제공
- 이 모든 작업은 기본 모질라 소스코드와 공유되어 데스크탑, 모바일이 서로 도움이 되도록 함.
다음 단계
- Linux/ARM 플랫폼용 자동 빌드시스템 구축
- 노키아(Nokia) microB 패치 1.9 mainline 적용
- 리눅스, 윈도 모바일 플랫폼을 위한 빌드 타겟 생성
- 메모리와 성능에 대한 프로파일 작업 지속
- 아래와 같은 사용자경험(UX) 실험을 XULRunner기반에서 테스트
타겟 플랫폼
우선, ARM11(Arm v6)기반의 다음 두 플랫폼에 집중
사용자 경험(UX)
작은 화면에 XUL UI를 효과적으로 표현하는 방안 간구
- XUL로 이용 가능한 새로운 레이아웃 옵션(?)
- 다양한 탐색 옵션 (예: spatial navigation, directional tabbing, panning, mini map, allow extensions to control navigation, software cursor)
- Device에서 제공하는 텍스트 입력과 위젯과의 통합
- 자바스크립트를 이용한 디바이스 고유 기능(주소록, 카메라, 등) 접근
관련글
2007년 11월 22일 목요일
Firefox3.0 베타1과 Cairo
오랜 알파 테스트를 끝내고(알파8까지) 드디어 베타 릴리즈를 시작했습니다.
그 동안 성능 문제로 계속 알파를 벗어나지 못했는데, 조금씩 문제가 해결되나 봅니다.
Firefox3의 가장 큰 특징은 Cairo라는 벡터 그래픽 엔진의 사용입니다.
지금까지 SVG만 cairo를 통해 렌더링해왔고, 각 플랫폼 마다 각자 고유 그래픽 기능을 사용해왔는데, 이제부터 모든 그래픽 렌더링은 Cairo를 통해 구현됩니다. 물론 Cairo는 플랫폼 마다 각기 다른 backend를 갖게 됩니다.
Cairo를 선택하게된 이유는 폰트, SVG, Canvas에서 높은 수준 그래픽 기능을 요구했고 OpenGL을 통해 하드웨어 가속이 가능하기 때문입니다.
향후 Firefox는 플래시 수준의 벡터 그래픽 표현 능력을 갖게 되어 새로운 웹의 모습을 보여줄 것입니다.. 지금도 웹을 돌아다니다 보면 많은 예제를 볼 수 있습니다~
자세한 내용은 아래글을 참조하세요..
피드 구독하기:
글 (Atom)