Page MenuHomePhabricator

GTK-QT-Edje Theme Engine
Updated 2,358 Days AgoPublic

Notice

There is no work in progress to make this happen as it is, sorry for getting your hopes up.
But don't lose faith!, there is work already on a QT-Edje bridge. See QEdje.

Abstract

This article describes the implementation of two theme engines, one for GTK and one for QT. Both draw their widgets based on the contents of a given Edje file, easing integration with an EFL based desktop.

Rationale

The need for a project like this is founded over three assumptions:

Users prefer an application over another similar application based on the features the first provides. Ignoring the underlying library the application is built on.
Users prefer a consistent desktop experience.
There are some applications that cannot be simply replaced or rewritten.
In order to address the second assumption, a definition for "desktop consistency" needs to be specified.

Desktop Consistency: refers to the relationship between the two attributes of any graphical interface, appearance and the behavior. Given two graphical components, the similarity in behavior between them is reflected by a similarity in appearance.

Today the Linux desktop is dominated by two toolkits, GTK and QT. Most users mix applications based on either one. It is possible to maintain consistency between both toolkits by either using the gtk-qt-engine or the qtcurve gtk/qt theme.

Enlightenment is an advanced desktop shell and provides multiple configuration dialogs and small applications. Besides the desktop shell there are two widget libraries (or toolkits) based on the EFL, Ewl and Etk.

Under both assumptions detailed at the beginning of this section it would be preferable for users if E, Ewl and Etk maintained as level of consistency with QT/GTK as possible.

Keep in mind that is not necessary, not recommendable, to create a carbon copy of all the interface components across the toolkits but to provide visual hints corresponding with the level of similarity. Interface components that do not behave exactly the same should not look exactly the same.

Other possible solutions

  • Mimic a given QT/GTK theme in E, Ewl and Etk.
    • Pros: No programming required.
    • Cons: No automation possible. Lots of manual work.
  • Mimic a given E/Ewl/Etk theme in QT/GTK.
    • Pros: No programming required.
    • Cons: No automation possible. Lots of manual work.

The proposed solution

To create two theme engines for each main toolkit, GTK and QT. These engines will draw key interface elements based on the contents of a given Edje file. The format of this Edje file must be agreed beforehand, so its design elements can be reused by the EFL based toolkits.

As I said before, I don't consider a complete carbon copy of the interfaces across the toolkits necessary for, or even beneficial to, desktop consistency. Unity can be achieved by maintaining a color scheme across the themes. This does not mean that EFL themers should limit themselves to use plain colors, this mean that the EFL themers should define a color scheme they feel fits with the looks of their theme. This would be extremely simple to implement in both, the GTK/QT theme engine and EFL based toolkit themes.

After colors the next step is to repeat the textures that decorate widgets in EFL toolkits, in their GT/QT cousins. This would require either:

  • Standardization on the basic structure of EFL based toolkits. The engine will then know which groups to import. The downside of this method is that it limits the freedom of the EFL themers trying to cover the various EFL toolkits.
  • Ask EFL themers to add additional groups to their themes files. Not necessarily to reuse them in the rest of the theme. But to provide a set of textures that, applied to GTK/QT themes, would fit with their own theme.

I believe the second option will work better on the near term, the first option can be left aside for the time a single EFL based widget arises over the competition.

For an example of how unity could be maintained with a simple color scheme and texture change see this screenshot, I have singled this particular screenshot out of the rest in the group becuase it shows how unity can be achieved with a color scheme and textures on the key elements.

Possible Implementation?

<dresb> I'm thinking of implementing a (very basic) QT-Edje theme engine.
<dresb> would using Edje/Evas to create assemble a bitmap in memory and pass that to the QT drawing function the best way to go?
<raster> that may be possible
<raster> u'll have problems with swallow stuff
<raster> and layering
<raster> and animation
<Stalwart> it may be easier to rewrite needed app from scratch
<dresb> oh yes, I intend to implement a small subset of Edje
<dresb> to keep some consistency in font family, font color, icon theme, window background, button background, menu background.

For those hoping to make a fully functional GTK-Edje engine

<dresb_> the correct way to display Edje objects over GTK applications would be creating a gdkpixbuf Evas engine right?
<raster> that'd be one way
<dresb_> seems like the kind of way I don't want to go. =) there anything easier?
<Inc> slacker
<raster> not really
<iamsthitha> rewrite all the gtk apps!
<raster> well maybe the buffer engine
<dresb_> *hopes up*
<raster> as that just renders to an in-memory ARGB buffer
<raster> but u still have to merge ecore and glib main loops
<raster> :)
<iamsthitha> but.. how will his edje get events then?
* uberpinguin (n=uberping@unaffiliated/uberpinguin) ha entrado en #e
<raster> u will need to feed them to the buffer canvas
<iamsthitha> merging the loops is easy right?
<raster> nup
* bobby_C (n=bobby@85.127.76.212) ha entrado en #E
* Bhl` (i=Bhl@m241.net81-64-255.noos.fr) ha abandonado #e
<iamsthitha> ecore_main_loop_iterate in the glib loop wont work?
<raster> nup
<dresb_> sweet.
<iamsthitha> aww.. damm you glib!
<raster> u need ecore to know when to wake up for a timer
<raster> ecore has idler enterers and exiters
<raster> which glib doesnt have
<raster> both glib and ecore have idlers
<raster> both have timers
<raster> ecore has animators (though built on top of timers)
<raster> and pollers (again built on top of timers)
<iamsthitha> but they're all handled in the iterate fuction..
<iamsthitha> could you.. have a loop that runs ecore's iterate and glib's iterate (assuming it has one) ?
<raster> buty u dont know when to WAKE UP
* Ryback_ (n=ulisses@enlightenment/developer/ryback) ha entrado en #e
<raster> ecore knows it needs to wake up at tim X
<raster> glib has no clue about this
* VaLouille se ha marchado (Read error: 110 (Connection timed out))
<iamsthitha> ah
<raster> ecore can be interrupted by data on an fd
* Raven301 se ha marchado ("bbl")
<raster> and glib knows nothing of this fd
<raster> if ecore has an ilder it is in a busy-sleep
<iamsthitha> ok.. that is quite tricky then :|
<raster> ie it doesnt sleep - it just loops the ilder while "sleeping"
<dresb_> If I implemented a gdkpixbuf evas engine I would still have to merge loops right?
* phoenix__| (n=valentin@fwle.univ-lemans.fr) ha entrado en #e
<raster> yup
<raster> a pixbuf engine is simply a matter of work
<raster> merging loops is in fact hard
<raster> the ONLY way is to put ecore in 1 thread
<raster> and glib in another
<raster> and use fd pipes betwene glib and ecore loops to communicate
* VaLouille (n=valouill@mmenal.org) ha entrado en #e
<raster> and NEVER call anything that may call an ecore/efl call from the glib loop
<raster> glib is threadsafe
<raster> ecore/edje/evas is not

Code

Here are some experiments with Gtk+ and Evas http://tux-style.de/projects/gtk_edje/. Don't be excited! It's not working and I'm not sure if the concept could work in any way! It's only some code I played with. Look at it, laugh, throw it away or do something useful with it. :-)

One big problem I found out is that Gtk clear the window after each redraw. There's no way in the theme engine to prevent this. It comes somewhere from within the library. But this kicks the way Evas work. It had worked, but as Evas has only single buffering it looks very bad! So my idea was to render into a buffer and draw that into the window each redraw. That could work, but I stopped it as it didn't work with my first experiments. Maybe someone else will continue that idea or one day I'll continue it.

Imported from https://trac.enlightenment.org/e/wiki/DevelopmentIdeas/GtkQtEdjeThemeEngine
History:
1 mcalamelli 2009-01-30 01:36:07
2 andreasvolz 2009-04-19 11:41:31

Last Author
beber
Last Edited
Sep 5 2013, 1:36 PM
Projects
None
Subscribers
None