this was, I guess, an attempt to provide users with an easily accessible ibar icon when starting a new config. problem: xterm isn't installed by default on ANY distributions! so now we end up providing a launcher which is guaranteed to fail, and that makes us look pretty stupid. same thing goes for mplayer.
regardless of whether they're installed, however, these aren't our apps, so we shouldn't be trying to provide .desktops for them: doing that tell users that we support and recommend the use of these apps, and I'm not prepared to make that claim for any app other than powerpoint.
* Move compositor to core, but letting the configuration there
* Rename all files and functions from e_mod_comp_* to e_comp_*
* Move the config dialogs to a new module named conf_comp. It still
uses a domain config, otherwise it would not pick the current
user's configuration. Maybe it would be wise to later on move these
options to e_config
* Fixup the wizard mess linking the header in the build tree in order
to be able to create the config. Since now it's in core, we don't
need to play linking games in the build system
I'm not sure if the wayland part works. It was not even building
previously so I'll let for who cares about this to actually test and
report bugs.
SVN revision: 82454
module build chnages because its fundamentally broken. it DOES NOT
PRODUCE .SO FILES. just .la and .a files. the only reason u dont
notice is.. you ALREADY had .so's installed. i just got in from the
airport... synced and updated.. rebuilt and was met with all modules
not loading... literally - no .so's are installed int he module dirs.
try rm -rf the instaleld module tree.
regardless... this has to be reverted be3cause it's a major break. the
idea is right/nice. the implementation is causing... problems.
SVN revision: 79015
automake thinks it's good to mix absolute and relative path, based on
where the build dir is. So, $(top_srcdir) is not always relative
regardless the fact that if we wanted it to be absolute we could have
used $(abs_top_srcdir). So... use the absolute dir. Always.
SVN revision: 78999
Automake 1.11 seems not to include a dependency between
wizard_page_150_la_OBJECTS and the generated .c/.h files. I'm not
entirely sure this is the right fix, but letting the build broken for
some people is not nice neither. Try to fix it with this, and check
later if this is indeed necessary.
SVN revision: 78998