|
|
|
|
noinst_PROGRAMS = $(clients_programs) \
|
|
|
|
|
$(poppler_programs) \
|
|
|
|
|
$(simple_clients_programs)
|
|
|
|
|
|
|
|
|
|
libexec_PROGRAMS = $(desktop_shell) $(tablet_shell)
|
|
|
|
|
|
|
|
|
|
if BUILD_SIMPLE_CLIENTS
|
|
|
|
|
simple_clients_programs = simple-egl simple-shm simple-touch
|
|
|
|
|
simple_egl_SOURCES = simple-egl.c
|
|
|
|
|
simple_egl_LDADD = $(SIMPLE_CLIENT_LIBS) -lm
|
|
|
|
|
|
|
|
|
|
simple_shm_SOURCES = simple-shm.c
|
|
|
|
|
simple_shm_LDADD = $(SIMPLE_CLIENT_LIBS)
|
|
|
|
|
|
|
|
|
|
simple_touch_SOURCES = simple-touch.c
|
|
|
|
|
simple_touch_LDADD = $(SIMPLE_CLIENT_LIBS)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
if BUILD_CLIENTS
|
|
|
|
|
clients_programs = \
|
|
|
|
|
gears \
|
|
|
|
|
flower \
|
|
|
|
|
screenshot \
|
|
|
|
|
terminal \
|
|
|
|
|
image \
|
|
|
|
|
dnd \
|
|
|
|
|
smoke \
|
|
|
|
|
resizor \
|
|
|
|
|
wscreensaver \
|
|
|
|
|
eventdemo
|
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
desktop_shell = weston-desktop-shell
|
|
|
|
|
tablet_shell = weston-tablet-shell
|
|
|
|
|
|
|
|
|
|
noinst_LIBRARIES = libtoytoolkit.a
|
|
|
|
|
|
|
|
|
|
AM_CFLAGS = $(GCC_CFLAGS)
|
|
|
|
|
AM_CPPFLAGS = \
|
|
|
|
|
-DDATADIR='"$(datadir)"' \
|
|
|
|
|
$(CLIENT_CFLAGS)
|
|
|
|
|
|
|
|
|
|
libtoytoolkit_a_SOURCES = \
|
|
|
|
|
window.c \
|
|
|
|
|
window.h \
|
|
|
|
|
cairo-util.c \
|
|
|
|
|
cairo-util.h
|
|
|
|
|
|
|
|
|
|
toolkit_libs = \
|
|
|
|
|
libtoytoolkit.a \
|
|
|
|
|
$(CLIENT_LIBS) -lrt -lm
|
|
|
|
|
|
|
|
|
|
gears_SOURCES = gears.c
|
|
|
|
|
gears_LDADD = $(toolkit_libs)
|
|
|
|
|
|
|
|
|
|
flower_SOURCES = flower.c
|
|
|
|
|
flower_LDADD = $(toolkit_libs)
|
|
|
|
|
|
|
|
|
|
screenshot_SOURCES = screenshot.c screenshooter-protocol.c
|
|
|
|
|
screenshot_LDADD = $(toolkit_libs)
|
|
|
|
|
|
|
|
|
|
terminal_SOURCES = terminal.c
|
|
|
|
|
terminal_LDADD = $(toolkit_libs) -lutil
|
|
|
|
|
|
|
|
|
|
image_SOURCES = image.c
|
|
|
|
|
image_LDADD = $(toolkit_libs)
|
|
|
|
|
|
|
|
|
|
dnd_SOURCES = dnd.c
|
|
|
|
|
dnd_LDADD = $(toolkit_libs)
|
|
|
|
|
|
|
|
|
|
smoke_SOURCES = smoke.c
|
|
|
|
|
smoke_LDADD = $(toolkit_libs)
|
|
|
|
|
|
|
|
|
|
resizor_SOURCES = resizor.c
|
|
|
|
|
resizor_LDADD = $(toolkit_libs)
|
|
|
|
|
|
protocol: add screensaver interface
Add the screensaver interface to the desktop-shell protocol file. Also
add stubs for it in the compositor, and make wscreensaver to bind to the
screensaver interface. Wscreensaver gets a new option --demo to retain
the current behaviour as a regular wayland client.
When a screensaver application starts, it should bind to the screensaver
interface, enumerate all outputs, create a surface per output, and
register those surfaces via screensaver::set_surface request. Then it
continues with the usual animation loop, waiting for frame events. The
compositor will decide, when the given screensaver surfaces are
displayed. A screensaver application should respond to outputs coming
and going away by creating and destroying surfaces.
The compositor is supposed to activate a screensaver by exec'ing it, and
stop the screensaver by killing the client process. Only one client may
be bound to the screensaver interface at a time. If there already is a
client, the compositor could either kill it first, or not exec a new
one.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
|
|
|
wscreensaver_SOURCES = \
|
|
|
|
|
wscreensaver.c \
|
|
|
|
|
wscreensaver.h \
|
protocol: add screensaver interface
Add the screensaver interface to the desktop-shell protocol file. Also
add stubs for it in the compositor, and make wscreensaver to bind to the
screensaver interface. Wscreensaver gets a new option --demo to retain
the current behaviour as a regular wayland client.
When a screensaver application starts, it should bind to the screensaver
interface, enumerate all outputs, create a surface per output, and
register those surfaces via screensaver::set_surface request. Then it
continues with the usual animation loop, waiting for frame events. The
compositor will decide, when the given screensaver surfaces are
displayed. A screensaver application should respond to outputs coming
and going away by creating and destroying surfaces.
The compositor is supposed to activate a screensaver by exec'ing it, and
stop the screensaver by killing the client process. Only one client may
be bound to the screensaver interface at a time. If there already is a
client, the compositor could either kill it first, or not exec a new
one.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
13 years ago
|
|
|
desktop-shell-client-protocol.h \
|
|
|
|
|
desktop-shell-protocol.c \
|
|
|
|
|
wscreensaver-glue.c \
|
|
|
|
|
wscreensaver-glue.h \
|
|
|
|
|
glmatrix.c \
|
|
|
|
|
matrix3.xpm
|
|
|
|
|
wscreensaver_LDADD = $(toolkit_libs) -lGLU
|
|
|
|
|
|
|
|
|
|
eventdemo_SOURCES = eventdemo.c
|
|
|
|
|
eventdemo_LDADD = $(toolkit_libs)
|
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
weston_desktop_shell_SOURCES = \
|
|
|
|
|
desktop-shell.c \
|
|
|
|
|
desktop-shell-client-protocol.h \
|
|
|
|
|
desktop-shell-protocol.c
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
weston_desktop_shell_LDADD = $(toolkit_libs) \
|
|
|
|
|
../shared/libconfig-parser.la
|
|
|
|
|
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
weston_tablet_shell_SOURCES = \
|
|
|
|
|
tablet-shell.c \
|
|
|
|
|
tablet-shell-client-protocol.h \
|
|
|
|
|
tablet-shell-protocol.c
|
Rename wayland-compositor to weston
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
13 years ago
|
|
|
weston_tablet_shell_LDADD = $(toolkit_libs) \
|
|
|
|
|
../shared/libconfig-parser.la
|
|
|
|
|
|
|
|
|
|
BUILT_SOURCES = \
|
|
|
|
|
screenshooter-client-protocol.h \
|
|
|
|
|
screenshooter-protocol.c \
|
|
|
|
|
desktop-shell-client-protocol.h \
|
|
|
|
|
desktop-shell-protocol.c \
|
|
|
|
|
tablet-shell-client-protocol.h \
|
|
|
|
|
tablet-shell-protocol.c
|
|
|
|
|
|
|
|
|
|
CLEANFILES = $(BUILT_SOURCES)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
@wayland_scanner_rules@
|
|
|
|
|
|
|
|
|
|
if HAVE_POPPLER
|
|
|
|
|
poppler_programs = view
|
|
|
|
|
view_SOURCES = view.c
|
|
|
|
|
view_LDADD = $(toolkit_libs) $(POPPLER_LIBS)
|
|
|
|
|
view_CPPFLAGS = $(AM_CPPFLAGS) $(POPPLER_CFLAGS)
|
|
|
|
|
endif
|
