Beryls Emerald for compiz

[rememo]

Hi all,

thanks to the hard work of FunkyM sending patches for emerald upstream to beryl and the work from beryl-devs on compiz-git (mainly maniac), we can now use emerald for beryl and compiz (latest git recommended). Since the beryl-devs decided to base their work on compiz-core they've now created a compiz git-repository for emerald :)

WHAT'S EMERALD:
Emerald is a themeable window decorator written by quinn and other devs (I think cornelius?) from beryl-project.org. They based their work on the gnome-window-decorator from David Reveman (lead compiz developer) and continuosly added patches to enhance functionality. Kudos to them!!
Emerald supports different engines to do the drawing of the window borders and you can also write your own engines.
The aim of emerald also is to be desktop independent. That's why it ships its own settings system (flat file backend) and the emerald-theme-manager, where you can create and export your own themes using the different engines.
The main benefit over gtk-window-decorator/metacity-themes is the use of region-transparency for drawing and many existing themes using this. Also you can have some nice button-glow. It also supports blurring of the decorations now.
The code is released under the GPL.

WHAT DOES IT LOOK LIKE:
Here is a nice slick example from gnome-look.org(kudos to original author astoyanov, very nice):
http://img152.imageshack.us/img152/9687/pure10zq8.th.png (http://img152.imageshack.us/my.php?image=pure10zq8.png)
And here is an example of blur support added by FunkyM:
http://sukimashita.com/temp/10-emerald-add-decoration-blur-support-2.jpg

WHAT'S NEEDED TO LET IT RUN IN COMPIZ (aka dependencies):
- tested with latest stable compiz release (0.36) and compiz-git
- a libdecoration-dev package to compile (in Ubuntu 7.04 (feisty) it is libdecoration0-dev)
- all other stuff should be as for gtk-window-decorator (without the gnome deps of course)
I don't know where to get the dev packages for other distros. If you compile from source (i.e. compiz-git) you will get all you need.

WHAT DO I HAVE TO DO TO USE IT:
0. fulfill all dependencies
1.a COMPIZ <= 0.36:
- Checkout the emerald sources from beryl svn-repository
- extract into emerald repository
- apply initial compiz support patch (http://sukimashita.com/temp/00-emerald-for-compiz-1.patch)
- Apply blur-support-patch (http://sukimashita.com/temp/10-emerald-add-decoration-blur-support-2.patch). (thanks to FunkyM)

1.b latest COMPIZ-GIT:
- Checkout the emerald sources from beryl's "compiz/emerald" git-repository or download the latest snapshot here (http://gitweb.beryl-project.org/?p=compiz/emerald;a=snapshot;h=HEAD) and extract into emerald repository

2. run "./autogen.sh" in emerald directory
3. run "make install" as root
4. run "emerald-theme-manager" and fetch some themes from beryl-repository (via Repositories tab)
5. run "emerald --replace" (you will need a startscript to get it up on session start, or set the decorator command in decoration plugin)
6. play around in emerald-theme-manager it's fairly easy to set up a theme
7. create your own themes and share them via gnome-look ;)

You can also download themes from gnome-look.org (http://www.gnome-look.org/index.php?xcontentmode=103) and the beryl-theme site (http://themes.beryl-project.org/themes.php?cat=0) .

If you want to use the blur support for your window borders, set "Compiz Decoration Blur Type" in "Emerald-Settings"-Tab to "All decoration" or "Titlebar only". Also make sure you have blur plugin loaded and your system supports it (hint: fragment programs via proper ati-card+XGL+fglrx, proper nvidia-card+nvidia-driver or proper intel-card+latest xorg).

WHAT GETS INSTALLED WHERE:
- all user downloaded and installed themes are stored in ~/.emerald/themes
- the actual theme is stored in ~/.emerald/theme
- general settings are stored in ~/.emerald
- system-themes (after root make install) are stored in /usr/local/share
- all engines, programs and other stuff is stored in /usr/local/lib|bin|include

WHAT ARE KNOWN BUGS:
- settings won't change until restart of emerald (latest git version)
- please refer to the beryl bug-tracker for any other bugs in emerald

/*FOR DEVS*/

WHAT COULD I DO TO IMPROVE EMERALD:
0. try to fix bugs
1. rewrite emerald to use libdecoration
- fully utilize the libdecoration structs (decor_context_t, decor_layout_t) to use the nice set_lXrXtXbX_window_quads functions
- use the shadow creation/update/... functions in libdecoration
2. send any patches upstream to beryls bug-tracker by filing a new bug (with attached patch) there

[RYX]

Great work, rememo ... :D

I am sure many people will be very happy about this.

btw: a simple way to get libdecoration.h is to install compiz from source ;)

(And how about "backporting" the name, too? CWD could use a revival ... :D:D ... )

:)

[RAOF]

...
(And how about "backporting" the name, too? CWD could use a revival ... :D:D ... )

:)

Please, no. It's bad enough that Beryl took gtk-window-decorator and renamed it Heliodor. We don't have to needlessly antagonise them by doing the same thing.

[maniac]

Funny enough, I've done the same today without seeing this ;)
I used a slightly different approach. I left the stretching intact and added the appropriate interface to libdecoration. As David was ok with it, it's now in Compiz GIT.
With that, you can use latest Emerald from Beryl GIT with Compiz. I've uploaded the adapted version here: http://rapidshare.com/files/22043306/emerald.tgz.html. The only changes are replacing libberyldecoration references with libdecoration references.
However, I fully agree that emerald should be rewritten using libdecoration.

[rememo]

@RYX:
Thanks. Forgot about the source installation :D
I fully agree with RAOF. The beryl-devs have put quite a lot of efforts into emerald and I wanted to respect this and give proper credits. A port doesn't justify a name-change ;)

@maniac:
Yes, I've seen your changes. Great work! Nice to see the cross-commit access becoming reality. So it seems that someone first has to patch libdecoration now to use your interface in the set_horz_quad_line/set_vert_quad_row functions. Currently you are using no stretch (q->stretch=0) if I understand this correctly and only your git-emerald version uses the interface (in quinns quad-setting method). Hmm why didn't you fully set it up in libdecoration ;) . I think moving emerald (either your git-version or my ported version) further to libdecoration only makes sense after this is done. So I'll just wait to see where libdecoration is heading before I try to use the decor structs.

[mikedee]

Thanks rememo :)

I have mirrored it here in case of any problems.

http://www.anykeysoftware.co.uk/compiz/emerald.tar.gz

Also, it seemed to be having problems installing the engines into a directory other than /usr/local/lib.

[imnotpc]

Nice job rememo and maniac! Thanks for doing this.

[maniac]

@maniac:
Yes, I've seen your changes. Great work! Nice to see the cross-commit access becoming reality. So it seems that someone first has to patch libdecoration now to use your interface in the set_horz_quad_line/set_vert_quad_row functions. Currently you are using no stretch (q->stretch=0) if I understand this correctly and only your git-emerald version uses the interface (in quinns quad-setting method). Hmm why didn't you fully set it up in libdecoration ;) . I think moving emerald (either your git-version or my ported version) further to libdecoration only makes sense after this is done. So I'll just wait to see where libdecoration is heading before I try to use the decor structs.
To be honest, I don't understand the decoration interface enough to do this change by myself :(
You are right that libdecoration currently doesn't use it, but only emerald uses it. If you have any proposals on how to meaningfully change the interface, I'm all ears ;)

[RYX]

The beryl-devs have put quite a lot of efforts into emerald and I wanted to respect this and give proper credits. A port doesn't justify a name-change ;)
How ironic :D ... I guess you're right - don't take me too serious with the name-thing (though I bet David still did 70-80% of emerald ... ;)). It's true - emerald is emerald ...

(I heard birds singing that we will get something maybe even more interesting soon(er or later) ... :D ... )

:)

[FunkyM]

Great work!
It would be interesting to implement gwd's blur support in this.
The stuff should go into some repository asap (already two people had worked ont his and exchanging patches in posts or mass archives is really odd!).

[imnotpc]

/*FOR IMNOTPC Smile */
I'm fine with adding the port to compiz-extra (either rock3d or go-compiz git, I think david decides on the later). Unfortunately I've never used git and currently I've no time to learn it or to maintain the port (allthough emerald seems quite freezed in beryl). I hope this is no blocker for integration.
We're still having access issues with the go-compiz site so I'll set this up in the rock3d git repo. We can always move it later.

@maniac: It would be great if we could merge your version and rememo's. Once I get his git running can you run a diff and work with rememo to create a common trunk? Even if you need to keep branches I think the more common code the better.

As our cores converge there will be more projects like this that can be shared between communities. I'd be happy to host any of those projects on the rock3d site. If anyone is interested you can PM me or mail me at imnotpc_at_ubaight.com

[rememo]

@mikedee:
Thanks for the file-mirror.
Setting libdir=/usr/lib in configure.ac doesn't work? After having looked at the makefile.am's it should define ENGINE_DIR right, which is then used in engine_loader.c and libengine\themer.c . If this doesn't work, I'm afraid I can't help you more because this is the first time I actually tried to understand the automake tools.

@maniac:
Huh... Ok then, I thought you could explain it to me :D . Hmm, then I will have to try to understand where and how emerald uses the stretch interface and how the quad-matrices work. Anyways I simply thought of adding the stretch parameter to set_horz_quad_line/vert_quad_row where one could set STRETCH_X or STRETCH_Y for the middle quad (this will mostly be used I guess), but maybe this is to basic :) Btw: Have you looked at the splitX/splitGravity/left|right|bottom|top_corner_space interface which is used in set_lXrXbXtX functions. David used it to define a stretch_offset for metacity-themed titlebars I think. Effectively you let the left_quad end at splitX(=stretch_offset), then you have a zero-width middle stretching_quad and after that you begin with the right_quad at splitX. If you set the stretch_offset properly the user won't notice any resizing glitches (I used this interface in my port, without computing proper stretch_offset). I think that is what you also wanted to achieve with the stretch interface in beryl. But as I'm only beginning to understand the quads I maybe wrong, so please correct any misunderstanding.

I think we should also agree to use only one libdecoration, if we want to get interoperable window-decorators (i.e. emerald). I propose to use compiz's libdecoration because libberyldecoration hasn't added much new code (besides the stretch interface of course).

@RYX:
Interesting! Keep it coming! Any more infos from the birds?

@FunkyM:
Definitely, forgot to add it to the TODO list. There is already some support in libdecoration for this (after having a quick look). Anyways, this will be hard work I guess.

@imnotpc:
Thanks for the hosting. I would also like to see a merge and hosting at your repositories, but in this case it depends on the beryl-devs.

@all:
I think a merge is a good idea but first there needs to be a common libdecoration and I'm not skilled enough nor do I have enough time to proper integrate the new stretch-interface (from beryl) into compiz's libdecoration :( We will need someone who has main-git access and fully understands the quad-settings. After we have agreed on a common library we can use it to rewrite emerald in a central repository. Anyways I don't think the beryl-devs will agree to host emerald in a repository outside beryl. I think we all would agree if they host it on their servers as long as they assure compatibility with the common libdecoration. I think all this depends on what beryl decides to do: merge or diverge.
I think we should give them some time to decide on this... and if they disagree on a merge we can simply fork (and rename ;) ) emerald to use our libdecoration, at least this is GPL'd code *:D, sorry SCNR*

[delfick]

YAY!!!!!

finally :D


THANKYOU!!!! :D

</over-excitement>

[delfick]

o ye, how can i get the blur plugin to blur my borders ??

http://delfick.storage.googlepages.com/compiz-beryl-noblur.png

[FunkyM]

Since this is all done on a SVN maintained emerald checkout, I thought the best to do is to work on a patch level to keep in sync with any changes.

1. Thus I have split up the changes and rememo's intitial compiz support patch:
00-emerald-for-compiz-1.patch (http://sukimashita.com/temp/00-emerald-for-compiz-1.patch)

2. Attempt at adding the blur support (yet, not working):
10-emerald-add-decoration-blur-support-1.patch (http://sukimashita.com/temp/10-emerald-add-decoration-blur-support-1.patch)

I tried to add the blur functionality by setting the blur region hints like gtk-window-decorator does, however got stuck at translating the actual decoration region stuff to the format g-w-d works with.

Maybe someone else is more fluent in that and is able to fix the last issue. I will try to fix it once I understand the emerald quad vs. decor stuff.

[maniac]

@maniac:
Huh... Ok then, I thought you could explain it to me :D . Hmm, then I will have to try to understand where and how emerald uses the stretch interface and how the quad-matrices work. Anyways I simply thought of adding the stretch parameter to set_horz_quad_line/vert_quad_row where one could set STRETCH_X or STRETCH_Y for the middle quad (this will mostly be used I guess), but maybe this is to basic :)

Well, as I said: I'm not that competent at the decorator interface. My knowledge just was sufficient to add the changes I added, and I wouldn't have commited it if David wouldn't have had a look over it.


Btw: Have you looked at the splitX/splitGravity/left|right|bottom|top_corner_space interface which is used in set_lXrXbXtX functions. David used it to define a stretch_offset for metacity-themed titlebars I think. Effectively you let the left_quad end at splitX(=stretch_offset), then you have a zero-width middle stretching_quad and after that you begin with the right_quad at splitX. If you set the stretch_offset properly the user won't notice any resizing glitches (I used this interface in my port, without computing proper stretch_offset). I think that is what you also wanted to achieve with the stretch interface in beryl. But as I'm only beginning to understand the quads I maybe wrong, so please correct any misunderstanding.

gwd and kwd don't stretch at all. They update the pixmap whenever the window size is change. An example for that is the function update_window_decoration_size in gwd. On the other hand, emerald stretches them so the pixmap isn't reprocessed on resize.


I think we should also agree to use only one libdecoration, if we want to get interoperable window-decorators (i.e. emerald). I propose to use compiz's libdecoration because libberyldecoration hasn't added much new code (besides the stretch interface of course).

libdecoration == superset of libberyldecoration (which is libdecoration minus blur stuff). In case you didn't notice: I commited the stretching stuff to Compiz' libdecoration ;)
So at the moment we already have one libdecoration...


@all:
I think a merge is a good idea but first there needs to be a common libdecoration and I'm not skilled enough nor do I have enough time to proper integrate the new stretch-interface (from beryl) into compiz's libdecoration :(

See above ;)


We will need someone who has main-git access and fully understands the quad-settings. After we have agreed on a common library we can use it to rewrite emerald in a central repository. Anyways I don't think the beryl-devs will agree to host emerald in a repository outside beryl. I think we all would agree if they host it on their servers as long as they assure compatibility with the common libdecoration. I think all this depends on what beryl decides to do: merge or diverge.
I think we should give them some time to decide on this... and if they disagree on a merge we can simply fork (and rename ;) ) emerald to use our libdecoration, at least this is GPL'd code *:D, sorry SCNR*
Well, for the moment, I would prefer if you could prepare patches to Beryl GIT's emerald so I can commit them there. The ultimate goal of course should be a central repository :D

[maniac]

Since this is all done on a SVN maintained emerald checkout, I thought the best to do is to work on a patch level to keep in sync with any changes.

Yes, exactly. I'll merge any changes for libdecoration usage into the GIT repo.


1. Thus I have split up the changes and rememo's intitial compiz support patch:
00-emerald-for-compiz-1.patch (http://sukimashita.com/temp/00-emerald-for-compiz-1.patch)

I'm not completely sure if we need that at the moment after adding the stretch interface - GIT emerald works out-of-the-box with Compiz. ;)


2. Attempt at adding the blur support (yet, not working):
10-emerald-add-decoration-blur-support-1.patch (http://sukimashita.com/temp/10-emerald-add-decoration-blur-support-1.patch)

I tried to add the blur functionality by setting the blur region hints like gtk-window-decorator does, however got stuck at translating the actual decoration region stuff to the format g-w-d works with.

Maybe someone else is more fluent in that and is able to fix the last issue. I will try to fix it once I understand the emerald quad vs. decor stuff.
Once that is done, a patch would be highly appeciated. :D

[rememo]

@FunkyM:
Great Work! I wished I would better understand the decor/quads relation to help you.

@maniac:
Thanks for the stretch explanation. So the main benefit of the interface that emerald uses is that it's faster during resize due to stretching of quads (middle-quad) instead of pixmap update. Hmm, but the user will surely notice the stretch of the texture during resize. Why didn't you choose the gwd method? Gwd with metacity-theme enabled seems pretty fast on my (2 years old) system during resize.

Yes, I noticed the add of the interface to libdecoration, BUT as I said earlier currently it doesn't utilize the interface in the high-level functions and that's what I wanted to achieve. But since we both agreed on not being experts with the quads, I think we should ask David about the proper integration into libdecoration. I think what we want to have in the end, is that emerald uses the set_lSrStXbX_window_quads function and there is a parameter to this function to disable or enable the texture stretching. If we have this we don't need all the low-level quad setting currently used in beryls emerald, but simply pass over a decor and layout and get proper quads.

My patch brought some initial support for libdecoration high-level-function use but I'm fine with not adding it until we have a properly updated libdecoration that brings support for using your texture stretching in the high-level functions. Also to me it makes no sense to move emerald further to libdecoration until this is done, that's what I wanted to say ;)

Great to see that we agreed on one libdecoration and in the end I would, just like you, want to see a central repository with decorators for both communities :)

[delfick]

@maniac:
Thanks for the stretch explanation. So the main benefit of the interface that emerald uses is that it's faster during resize due to stretching of quads (middle-quad) instead of pixmap update. Hmm, but the user will surely notice the stretch of the texture during resize. Why didn't you choose the gwd method? Gwd with metacity-theme enabled seems pretty fast on my (2 years old) system during resize.

or atleast have it as an option, the resizing can get annoying :D

[RYX]

@maniac:
Thanks for the stretch explanation. So the main benefit of the interface that emerald uses is that it's faster during resize due to stretching of quads (middle-quad) instead of pixmap update. Hmm, but the user will surely notice the stretch of the texture during resize. Why didn't you choose the gwd method? Gwd with metacity-theme enabled seems pretty fast on my (2 years old) system during resize.

or atleast have it as an option, the resizing can get annoying :D
I remember that from emerald back when I used it with beryl and I always thought this stretching-issue is a bug ... Does the title-text still stretch, too?

I really agree that this should be a (non-default) option. The slow resizing is a problem of nvidia cards (driver?) as far as I know and working around that with stretching the texture doesn't seem like a good solution.

[FunkyM]

I actually did not think it is as easy as in the change in my patch but the blur support seems to work now.

The patches are:
1. rememo's intitial compiz support patch (might become obsolete once GIT is updated):
00-emerald-for-compiz-1.patch (http://sukimashita.com/temp/00-emerald-for-compiz-1.patch)

2. Adding compiz blur support for decoration to emerald and themer:
10-emerald-add-decoration-blur-support-2.patch (http://sukimashita.com/temp/10-emerald-add-decoration-blur-support-2.patch)

Looks like this:
http://sukimashita.com/temp/10-emerald-add-decoration-blur-support-2.jpg

Of course this needs a bit more work to fix all remaining bugs. Anyone?

emerald seems to have some issues with water and switcher interactions alongside being slower than g-w-d (using metacity themes). I think this is caused by the codebase not being "synced" enough with the gurrent g-w-d.

[maniac]

@maniac:
Thanks for the stretch explanation. So the main benefit of the interface that emerald uses is that it's faster during resize due to stretching of quads (middle-quad) instead of pixmap update.

Right.


Hmm, but the user will surely notice the stretch of the texture during resize. Why didn't you choose the gwd method? Gwd with metacity-theme enabled seems pretty fast on my (2 years old) system during resize.

Sorry, I can't tell you - I didn't write that stuff :(


Yes, I noticed the add of the interface to libdecoration, BUT as I said earlier currently it doesn't utilize the interface in the high-level functions and that's what I wanted to achieve. But since we both agreed on not being experts with the quads, I think we should ask David about the proper integration into libdecoration.

That's right - I already asked David about that ;)


I think what we want to have in the end, is that emerald uses the set_lSrStXbX_window_quads function and there is a parameter to this function to disable or enable the texture stretching. If we have this we don't need all the low-level quad setting currently used in beryls emerald, but simply pass over a decor and layout and get proper quads.

Right again - racarr told me that he plans to rewrite emerald (together with Quinn), but I have no clue when this will happen.


My patch brought some initial support for libdecoration high-level-function use but I'm fine with not adding it until we have a properly updated libdecoration that brings support for using your texture stretching in the high-level functions. Also to me it makes no sense to move emerald further to libdecoration until this is done, that's what I wanted to say ;)

Nice, that's fine. As I said, emerald should be rewritten either way, so most likely it would be a bit of a waste effort to work on that right now.

[rememo]

Sorry, I can't tell you - I didn't write that stuff

Well, after finally moving to git-compiz I had the chance to test beryls-emerald and I fully agree with delfick that it's annoying after some time to see the titlebar(with text and buttons) stretch on a resize. If I remember correctly the stretch was introduced by Quinn because of slow resizing when using pixmap-engine. But to stretch the whole titlebar with text and button is definitely not a solution, a better solution would be to spot a region between buttons and text (depending on the titlebar-layout) and map this region on the stretching quad. But I would only try to do this if using gwds repaint-method fails, because the titlebar-layout won't get updated during resize anyway and everything will look displaced. Anyways, until there is a better solution I will stay without texture-stretching ;) .

Right again - racarr told me that he plans to rewrite emerald (together with Quinn), but I have no clue when this will happen.

Yes, that's why I started porting to libdecoration, because nothing happened. Maybe now :)

@FunkyM:
Looks Great, many thanks for your efforts. If only I could use blur plugin now, but open-source radeon driver's don't support fragment programs.

[karmapolice]

It's working great still has some problems with shadows just like in beryl and another bug that I still don't know how to fix is that emerald theme manager doesnt change my theme unless I restart emerald.

And yes stretching is anoying :P

[rememo]

Hi,

just to get you updated.
Thanks to imnotpc we now have a git repository for the port over at http://git.rock3d.org/git/ . Since I'am currently the only one having access (maybe this will change, I asked imnotpc to give also access to FunkyM) I would like to get any patches via this forum thread. I would also like to get real names and email-adresses to give proper credits in commit's (you could pm me, but it will get public in gitweb anyway ;) ). Anyways, if someone wants to stay private I will respect this and use the forum-name and the forum-adress (i.e. Author: rememo E-Mail: @http://forum.go-compiz.org/ ).

I don't want to split or branch from beryls-emerald that's why I wouldn't want the codebase to drift apart. Git is currently based on my initial support patch and I want to push out FunkyM's blur-support changes asap. I would like to see the two git-repos (our's and beryl's) being only a temporary solution until we agree on a central repository with beryl-devs or at least know where beryl is heading. Is there any opinion from beryl-devs about this? Judging from the mailing-list it seems that quinn at least also wants a merge. Btw.: Is there a gitweb adress to see your new git-repositories?

I will update the first post with proper instructions asap.

Edit: And of course I would also like to see a beryl-dev with commit access to this repo, if aynone is interested :)

[FunkyM]

I think patches should always go upstream. In this case it is in beryl-project's GIT repository at http://gitweb.beryl-project.org/. After talking back with marex on IRC I filed a ticket http://bugs.beryl-project.org/ticket/1808 for this.

[rememo]

Yeah, you're right they definitely should go upstream!
Hmm, than I don't really see a reason for a git repository to exist for the port. I would be fine with removing it from rock3d.

@imnotpc:
What do you think? Since we now probably will have a merge I would guess emerald stays hosted at the beryl-server and will be developed there.

[imnotpc]

I think it's best at this point to hold off on any major changes until we work this out. There's a lot going on. The Rock3d server could become the main server, a mirror, host some stuff, stay the way it is, or not be involved at all. Nothing has been decided yet, but I'm going to post something in a few minutes to explain what we know.

[FunkyM]

You can now directly checkout or download the latest snapshot (http://gitweb.beryl-project.org/?p=beryl/emerald;a=snapshot;h=HEAD) of emerald.
Due to this commit (http://gitweb.beryl-project.org/?p=beryl/emerald;a=commit;h=f506da5b8df55999c53c4f9057d0191 eaa3f1575) you can now pass "--with-cm=compiz" to the configure script.
There are still some general issues with emerald but this should make it easy to streamline emerald packages for Compiz or enable "non-developers" to play around with emerald on Compiz.

[mikedee]

By the way, that download is a tar not a gzipped tar (as the filename suggests)

to extract it type

tar xvf emerald-HEAD.tar.gz

[rememo]

Thanks for your hard work with the patches FunkyM. And also thanks to beryl-devs for including them into emerald. :)

EDIT: Updated first post.

[fldc]

I can't see --enable-cm=compiz enabling blur settings in emerald-theme-manager, or didn't that patch go in?

[maniac]

I can't see --enable-cm=compiz enabling blur settings in emerald-theme-manager, or didn't that patch go in?
That patch definitely went in, and from what I can see from latest git (click (http://gitweb.beryl-project.org/?p=compiz/emerald;a=summary) - click on snapshot), file themer/main.c, the source code says the same (search for 'blur') :)

[rememo]

@fldc:
Hmm, that's strange, for me it works. Make sure you restart emerald after setting blur in emerald-theme-manager. That should do it... because currently changed settings will only work after a restart of emerald.

@maniac:
Changed settings will only work after a restart of emerald.
Is this a bug or a feature? Or maybe something with my system (i.e. dbus, does emerald use dbus?) ?

[fldc]

Change ...hehe, i have nothing to change it with, that's the problem :)
I used the patch before, and all worked fine, and no restarts were needed either.

[rememo]

Hmm, that's really strange...
I just downloaded the latest snapshot of emerald (from the new created compiz section) and it works for me (i'm getting blur-settings in "Emerald Settings"). You can get the latest snapshot with this:
http://gitweb.beryl-project.org/?p=compiz/emerald;a=snapshot;h=HEAD
Since this is the compiz version of emerald you will not need to do "--enable-cm=compiz" anymore during autogen.

I'm assuming you are using compiz git?

[fldc]

Well, after deleting ~/.emerald/settings.ini, things decided to start working again :)

EDIT: until i tried emerald built from git, now that don't start, haha.

btw, is emerald-theme-manager supposed to write all those newlines between sections to the config each time you close it? :)

[rememo]

Great :) That seems to be a common way to get things working again :D

EDIT:

EDIT: until i tried emerald built from git, now that don't start, haha.


:? ... damn
Are you using compiz-git?


btw, is emerald-theme-manages supposed to write all those newlines between sections to the config each time you close it?

Hmm, sorry I don't know (but I don't think so :wink: ). I didn't wrote it. Maybe you could ask over @beryl-forums if this is a bug.

[fldc]

Great :) That seems to be a common way to get things working again :D

EDIT:

EDIT: until i tried emerald built from git, now that don't start, haha.


:? ... damn
Are you using compiz-git?


btw, is emerald-theme-manages supposed to write all those newlines between sections to the config each time you close it?

Hmm, sorry I don't know (but I don't think so :wink: ). I didn't wrote it. Maybe you could ask over @beryl-forums if this is a bug.

Yes it's compiz git, but a restart of compiz was enough to get it working again, so, all is well for now :)

[karmapolice]

@maniac:
Changed settings will only work after a restart of emerald.
Is this a bug or a feature? Or maybe something with my system (i.e. dbus, does emerald use dbus?) ?

It is a bug because it is supposed to change the settings immediatly.

[jackkerouac]

Where do I get libdecoration-dev? I tried to ./autogen.sh and it told me I didn't have libdecoration-dev. Sigh.

[rememo]

WHAT'S NEEDED TO LET IT RUN IN COMPIZ (aka dependencies):
- tested with latest stable compiz release (0.36) and compiz-git
- a libdecoration-dev package to compile (in Ubuntu 7.04 (feisty) it is libdecoration0-dev)
- all other stuff should be as for gtk-window-decorator (without the gnome deps of course)
I don't know where to get the dev packages for other distros. If you compile from source (i.e. compiz-git) you will get all you need.

I've highlighted the important parts from the first post, I hope it helps. If you downloaded emerald from the beryl git-repos you will have to use compiz-git. I can assure you that all this will be easier once compiz 0.4 is out and packaged in the distro repos (if they do it right :wink: ). Unfortunately compiz has no packager for bleeding-edge-versions currently (as opposed to beryl) and that's why it's a bit complicated now. I know patience is a no-go for some users, but right now that's all I can tell you in the case you don't want to compile from source.

[jackkerouac]

I've highlighted the important parts from the first post, I hope it helps. If you downloaded emerald from the beryl git-repos you will have to use compiz-git. I can assure you that all this will be easier once compiz 0.4 is out and packaged in the distro repos (if they do it right :wink: ). Unfortunately compiz has no packager for bleeding-edge-versions currently (as opposed to beryl) and that's why it's a bit complicated now. I know patience is a no-go for some users, but right now that's all I can tell you in the case you don't want to compile from source.

I guess it helps to read the article. :oops:

I think, at this point, I'll just wait. I have no desire to compile so hopefully when 0.4 comes out, it'll have something like Emerald ready to go.

Thanks!

[bijoux]

Weird problem with emerald. The first time I initiate the app switcher, the switcher window is broken

http://i109.photobucket.com/albums/n50/SAbijoux/appswitcher.png

Sometimes, the switcher window also gets decorations (title bar, buttons etc.)

These do not happen with gtk-window-decorator.
Like I said, it only happens the first time I initiate app switcher, after the first, it becomes normal.

[karmapolice]

I can confirm the bug about window decorations in the switcher with emerald.

[jackkerouac]

Hello,

I am trying to compile this, but getting errors and thought someone could help.

When I ./configure, I get:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for library containing strerror... none required
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking how to run the C preprocessor... gcc -E
./configure: line 4417: AC_PROG_LIBTOOL: command not found
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
./configure: line 4755: syntax error near unexpected token `0.35.0'
./configure: line 4755: `IT_PROG_INTLTOOL(0.35.0)'


When I ./autogen.sh, I get:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
configure.ac:17: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
engines/Makefile.am:37: Libtool library used but `LIBTOOL' is undefined
engines/Makefile.am:37: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
engines/Makefile.am:37: to `configure.ac' and run `aclocal' and `autoconf' again.
engines/Makefile.am:37: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
engines/Makefile.am:37: its definition is in aclocal's search path.
libengine/Makefile.am:8: Libtool library used but `LIBTOOL' is undefined
libengine/Makefile.am:8: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
libengine/Makefile.am:8: to `configure.ac' and run `aclocal' and `autoconf' again.
libengine/Makefile.am:8: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
libengine/Makefile.am:8: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1

Any ideas? :?

[karmapolice]

You need libtool installed

[jackkerouac]

You need libtool installed

sudo apt-get install libtool
Reading package lists... Done
Building dependency tree
Reading state information... Done
libtool is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
configure.ac:17: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
engines/Makefile.am:37: Libtool library used but `LIBTOOL' is undefined
engines/Makefile.am:37: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
engines/Makefile.am:37: to `configure.ac' and run `aclocal' and `autoconf' again.
engines/Makefile.am:37: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
engines/Makefile.am:37: its definition is in aclocal's search path.
libengine/Makefile.am:8: Libtool library used but `LIBTOOL' is undefined
libengine/Makefile.am:8: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
libengine/Makefile.am:8: to `configure.ac' and run `aclocal' and `autoconf' again.
libengine/Makefile.am:8: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure
libengine/Makefile.am:8: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1

Weird.

[HydroDiOxide]

Hi there. I'm quite new to this. Running Ubuntu Feisty Fawn 64bit. How do I install Emerald so I can use it wit compiz and how do I apply the patches mentioned. Also, how will I be able to use/apply a theme downloaden from gnome-look? Loads of questions... hope you can give some answers.

Cheers!

[jmccarthy14]

Si,

Compiling isn't too bad, but the version availible for download now requires the latest compiz source, and at least for me on feisty, that gets rid of my window borders and all the other features. even using the 'patch' command or 'cg-commit/cg-patch' doesn't correct these emerald files, so i dont think there is a version out right now that will run stock with 3.6, am i wrong?
Does anyone have an old emerald pack that will work with this/the patches that doesn't require the newest compiz source? preferrably patched but anything is fine. if any of that is availible i'll write a guide for all the people with trouble compiling/installing.

ps to people on feisty - make sure you have your default depth to 24 in /etc/X11/xorg.conf - for some reason with this distro it can set it to 16 default. this may solve your window border problems

[Kevin]

I've got a version of emerald that runs fine on compiz 0.3.6 in feisty. I don't want to keep advertising my packages, but hey, it might be helpful to some :)

The source and patch is there too, so feel free to look at it and/or build it yourself. http://ubuntuforums.org/showthread.php?t=423743[/url]

[imsochobo]

The name emerald is just great, the name compiz-fusion, hmm doesnt pling though..
But the control panel, the features, and the god damn good web page theyve thrown together is just lovely :)

Although, emerald should be integrated into the ccsm I think, I love the emerald, and isnt it better to run it as a single service ? makes it alot more easy to manage ur applications in a taskmanager, or system monitor, whatever you prefer to call it.