IT/Mobile Platforms | Posted by 철규님(최규철) 2011. 3. 2. 00:59

EFL(Enlightenment Foundation Library)이란 무엇인가?



EFL이란 무엇인가?
by GyuCheol Choi(gc8134.choi@gmail.com) on 01 Mar 2011

삼성 SLP 또는 LiMo4 플랫폼의 아키텍처를 보면(2011/02/23 - [Dev/LiMo/SLP/EFL] - LiMo4? SLP?), UI 프레임워크로 GTK+와 EFL을 지원한다고 나와있다. GTK+는 Gimp ToolKit의 약자로 이미 오래전부터 사용되어 온 프레임워크로 관련 정보를 많이 찾을 수 있지만, EFL에 대한 정보는 아직 많이 제공되고 있지 않다. 간단하게 EFL이 무엇인지 정리를 해보려고 한다.

Enlightenment? EFL?
Enlightenment는 Linux/X11 등을 위한 Windows manager를 의미하기도 하고, 기존의 toolkit 보다 더 적은 작업으로 더 보기 좋은 UI 제작을 가능하게 하는 것을 목표로 하는 프로젝트의 이름을 의미하기도 한다. 이 개발 환경은 휴대폰과 같은 소형기기부터 노트북, 데스크탑과 같은 기기까지 지원한다.

EFL은 Enlightenment Foundation Library의 약자로 Enlightenment windows manager의 GUI 구현을 위한 라이브러리인데, 정확하게는 각각의 목적과 기능을 가진 라이브러리의 셋으로 볼 수 있다.

Enlightenment 홈페이지(http://www.enlightenment.org)에서 EFL의 구조를 찾으면 세 가지의 그림을 찾을 수 있다.

Figure 1. EFL stack with essentials

 
Figure 2. EFL stack by Marketing department


Figure 3. EFL stack in  programmer's view


전체적인 구조를 간단하게 나타내기 위한 것이 Figure 1이며, 상세한 정보를 나타내는 것이 Figure 2와 Figure 3인데 동일한 contents로 이렇게 다른 view가 나온 것에 대해서는 관련된 설명을 보자.

다양한 라이브러리의 구조 설명을 위해서 도입된 박스 형태의 도식(Figure 2)은 상위 레벨은 하위 레벨에 의존성을 가지고, 프로그래머는 상위 레벨의 요소들만 이용해야 하며 하위 레벨의 요소들을 직접 컨트롤해서는 안된다는 의미를 가진다. 하지만 EFL 라이브러리들은 이러한 상하 의존적 관계를 구성하고 있는 것이 아니기 때문에 Figure 2와 같이 상화 관계를 강조한 도식보다는 FIgure 3과 같이 상호 작용을 강조한 도식이 실제적인 EFL의 구조를 설명하는데 더 적합하다.

Figure 3을 정확히 이해하기 위해서는 각각의 요소들이 무엇인지에 대한 이해가 필요하므로, 간단하게 이것에 대해서 알아보고 다시 FIgure 3에 대해서 이야기해 보자.

  • Ecore glue library
    Ecore는 GTK+의 Glib와 비교할 수 있는데, EFL의 주요 요소들을 하나로 모아서 사용자 어플리케이션이 사용할 수 있도록 해주는 역할을 한다. data structure, IPC mechanism, easy networking, helper function 등을 제공하고 UNIX/X 시스템의 일부 common 기능에 대한 abstraction도 제공한다. Graphic적인 요소가 없는 어플리케이션에서도 Ecore를 사용할 수 있다.
  • Evas canvas
    Evas는 강력한 canvas로, X11 toolkit의 canvas widget보다 훨씬 더 진일보한 환경을 제공한다. Evas는 스크린에 어떤 것이 렌더링되었는지에 대한 정보를 모두 보유하고 있으며, 각각의 Evas object들은 "draw and forget" object의 성격을 띈다 . 즉, 사용자가 rectangle을 그리면 이것을 인지하고, 외부 data structure의 도움 없이도 move나 resize 등을 가능하게 하며, 프로그래머는 각 object의 state를 저장하고 있을 필요도 없고, redrawing이나 repainting에 대해서도 신경 쓸 필요가 없다. Evas는 매우 최적화되어 있어서 제한된 memory나 저수준의 processor를 가진 임베디드 시스템에서도 사용이 가능하다. X11의 back-end로 OpenGL이나 Xrender, frame-buffer device에서도 동작한다.
  • Edje layout engine
    Edje를 이용하면 C 코드를 단 한 줄도 코딩하지 않고 GUI를 구현할 수 있다. 인터페이스가 어떻게 구성되고 스크린에 어떻게 나타나며 어떻게 동작하는지만 작성하면, Edje가 low level code와 하나의 테마 파일에 모든 것이 포함된 번들을 만들어준다. 이를 이용하면 어플리케이션을 C 코드에 대해서는 전혀 모르는 graphical part와 GUI에 대해서는 전혀 모르는 functionality part로 나누어서 작성할 수 있다. 덕분에 GUI를 건드리지 않고 기능을 변경하거나, 기능을 변경하지 않고 GUI를 수정하는 등의 작업을 매우 쉽게 할 수 있다. 어플리케이션의 사용자 또한 자신의 테마를 만들어서 곧바로 적용할 수 있다.
  • Eet storage library
    대부분의 테마들은 하나의 파일로 전달되지만 설치 과정에서 압축이 풀리고 어플리케이션은 이 압축이 풀린 테마 파일'들'을 사용한다. Eet는 전혀 다른 방법을 사용하는데, 테마 파일은 압축이 풀리지 않은 상태에 있다가 어플리케이션의 UI를 구성하기 위해 필요한 때 Eet에 의해서 읽혀진다. 또한 Eet는 일반적인 storage의 역할도 한다.
  • Embryo scripting language
    Embryo는 마치 HTML에 Javascript, Flash, AJAX 등이 더해져서 동적인 UI가 가능해진 것 처럼, 테마 구성에 있어서 더 동적인 UI 구조를 만들 수 있게 한다.
  • Epeg thumbnailing library
    가장 많이 사용되고 있는 이미지 포멧이 JPEG이기 때문에, 이에 대한 thumbnail 기능 지원을 위해 JPEG에 최적화된 Epeg이 제공된다.
  • Epsilon thumbnailing library
    Epsilon은 PNT, JPEG 및 imlib2, Evas에서 지원하는 이미지 포멧에 대한 thumbnail을 제공한다. 경우에 따라서는 Epeg를 사용하지 않고 Epsilon을 사용해서 JPEG 파일을 지원할 수도 있다.
  • Esmart utility library
    Esmart는 Edje에 추가적인 능력을 더해주는 helper 라이브러리이다. Esmart를 이용하면 GUI를 위한 컨테이너를 사용할 수도 있고, X root window에 기반한 어플리케이션에서 transparent 효과를 줄 수도 있다. thumbnail 지원을 위한 Epsilon 라이브러리에 대한 인터페이스를 제공하고, 툴킷으로서의 기능(text entries, file dialog box, object drag 등)도 추가해준다.
  • EWL widget set
    EWL을 이용하면 어플리케이션이 위젯의 형태를 띄도록 할 수 있다.
  • Imlib2
    Imlib2는 EFL 이전에 등장한 초고속 이미지 처리 라이브러리로 EFL의 라이브러리는 아니다. 많은 시스템에서 이미지 처리를 위해서 사용되고 있으며 EFL에서는 Epsilon 라이브러리가 대표적이다.

Figure 3. EFL stack in  programmer's view again


이제 다시 Figure 3을 보고 EFL 라이브러리들의 구조에 대해서 알아보자. 

Figure 3을 보면 각각의 라이브러리들은 상하 의존 관계를 가지고 있지 않으며, 상호 연결 관계에 있어서도 어떠한 방향성도 가지지 않는다. 또한 각 모듈의 크기는 전체 EFL에서의 중요도를 나타낸다.

위의 도식을 설명하면, Evas는 명백하게 EFL에서 가장 중요한 요소이며, Edje는 Evas에 그래픽적 요소를 더해주는 infrastructure 역할을 한다. App1은 도식으로 보아 GUI를 지원하지 않는 콘솔 프로그램일 것이며, App2는 일반적인 형태의 어플리케이션, App3는 위젯 형태의 어플리케이션일 것이다.


아래의 공지를 보면 알 수 있지만, EFL은 아직 완성된 형태의 구조를 갖춘 라이브러리로 보기에는 무리가 있다. 
 

Enlightenment News

1.0 Release of core EFL

Carsten Haitzler - Jan 29, 2011 at 03:40 AM

Finally after a long time coming, we are pleased to announce the 1.0 release of the core EFL libraries (With the exception of Eet at 1.4). The following libraries have been released:

You can download the respective libraries from our Download Page.




아직 1.0까지 밖에 릴리즈가 안된 상태이어서 앞으로도 많은 변화가 있을 것으로 예상된다.

홈페이지의 자료를 찾다보면 Doc의 문서와 Release 관련 문서에서 많은 차이점들을 찾을 수 있는데, 정확한(사실은 더 최신의) 정보를 얻기 위해서는 News의 공지를 바탕으로 Release 관련 정보를 확인하는 것이 좋은 방법일 듯 하다.

댓글을 달아 주세요

IT/Mobile Platforms | Posted by 철규님(최규철) 2011. 2. 23. 23:50

LiMo4? SLP?



아무도 모르지만, MWC 첫날인 지난 2월 14일에 리모 재단(LiMo Foundation, http://www.limofoundation.org/)이 LiMo4 버전을 공개했다.


지난 기사에 따르면 2010년 5월 LiMo4 표준 선정에서 리모 재단은 삼성전자의 '콜로라도'를 선택했고, 삼성전자가 이를 11월 경 리모 재단에 기증하고, 리모 재단은 이를 LiMo4로 공개한다고 했었다. LiMo4의 발표가 각종 MWC2011 이슈에 묻혀서 완전히 관심 밖으로 벗어나는 바람에 관련 정보는 해당 홈페이지를 제외하고는 전무하다.

우선 알려진 자료를 바탕으로 SLP와 LiMo4 의 구조를 비교해 보자.

SLP와 LiMo4의 아키텍쳐를 비교해보면 프레임워크 구분이나 네이밍에 있어서 약간의 차이가 있지만 거의 동일한 구조를 가지고 있음을 알 수 있다.

코어로는 Linux를 사용하고, X-Window 기반으로 GTK+, EFL 등이 UI FW로 사용되고 있다. WebKit-gtk, WebKit-efl 까지 포함하면 LiMo는 GTK+ 어플리케이션, EFL 어플리케이션, 웹 어플리케이션을 구동할 수 있다.

LiMo4의 주요 특징은 아래와 같다.(http://www.limofoundation.org/en/what-is-the-platform.html)

  • flexible and powerful user interface
  • extended widget libraries
  • 3D window effects
  • advanced multimedia
  • social networking
  • location based service framework
  • sensor framework
  • multi-tasking
  • multi-touch
  • scalable screen resolution

다른 모바일 플랫폼이 지원하는 대부분의 기능을 그대로 지원하고 있고, 그나마 특징이 있다면 GUI FW(GTK+, EFL)을 내장하고 있다는 점과 다양한 화면 해상도를 지원한다고 자신있게 내세운다는 점이다.

아직 정확히 판단을 할 수 없지만, LiMo4는 다른 플랫폼이 지원하는 수준까지 이제 레벨을 올려놓은 수준으로 보는 것이 가장 나을 듯 하다. 즉, 특별한 경쟁력을 지녔다고는 볼 수 없기 때문에 앞으로 리모 재단 멤버 회원들의 지원 여부에 따라 성패가 나뉠 것으로 보인다.

게다가 FAQ에 의하면 LiMo4는 Flash, AIR, WAC 런타임을 지원하고, native 개발은 회원사들만 가능하며, 심지어는 자체 eco-system을 구축할 계획도 없다고 한다.

앞날은.........각자의 판단에......

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 소혼 2011.02.24 00:02 신고

    정보를 잘 찾네. 다양한 화면 해상도를 지원하는것은 EFL의 큰 장점중 하나지.

  2.  댓글주소  수정/삭제  댓글쓰기 zelon 2011.03.13 15:49 신고

    native 개발은 회원사들만 가능하며...... 오픈인 리눅스를 기반으로 만들면서 좀 의아하네 -_-; 후발주자이면서 무슨 배짱인지 -0-

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 23. 21:28

HTML5에서 <hgroup> 요소의 의미

HTML5에는 <h1>~<h6> 요소들을 묶는 <hgroup> 요소가 도입되었다. <hgroup> 요소의 사용 유무는 실질적으로 사용자에게는 드러나지 않는다. 다음 예제를 실행해보면 그 결과를 알 수 있다.


<!DOCTYPE html>
<html>
<head>
  <title>HTML5 - <hgroup> element 테스트</title>
</head>
<body>

<h1>장원준 "개막전 선발 욕심 있다"</h1>
<h2>日롯데 2군에 5이닝 무실점</h2>
<p>롯데 자이언츠가 일본 지바롯데 마린스 2군과의 연습경기에서 대승을 거뒀다.</p>

<hgroup>
  <h1>장원준 "개막전 선발 욕심 있다"</h1>
  <h2>日롯데 2군에 5이닝 무실점</h2>
</hgroup>
<p>롯데 자이언츠가 일본 지바롯데 마린스 2군과의 연습경기에서 대승을 거뒀다. </p>

</body>
</html>

결과 화면은 아래와 같다. (결과링크)



사용자에게 보여주는 화면은 <hgroup> 요소를 사용하나 사용하지 않으나 동일함을 알 수 있다. 하지만 HTML5에는 시멘틱 개념이 도입되었고, 이러한 관점에서는 두 소스 코드는 다른 의미를 가진다.

각각의 컨텐츠를 도식화 해 보면 다음과 같다.



첫번째 소스 코드에서는 <h2> 요소는 <h1> 요소의 '하위' 항목이 되고 <p> 요소는 <h2>요소에 대한 설명으로 인식된다.
두번째 소스 코드에서는 <h2> 요소는 <h1> 요소의 '부가' 항목이 되고 <p> 요소는 <h1>, <h2>요소에 대한 설명으로 인식된다.

만약 검색 엔진 등 기계적으로 본문에 대한 주제나 요약을 찾을 경우,
첫번째 소스코드에서는 <h2> 요소가 <p> 요소를 대표하게 되고,
두번 소스코드에서는 <h1>, <h2>요소가 모두 <p> 요소를 대표하게 되는데,
<h1>, <h2> 중 다시 하나를 선별한다면 <h1> 요소가 <p>요소를 대표하게 된다. 

댓글을 달아 주세요