ede/evoke/EvokeService.h

134 lines
3.0 KiB
C
Raw Normal View History

2007-07-11 20:03:18 +04:00
/*
* $Id$
*
* Evoke, head honcho of everything
* Part of Equinox Desktop Environment (EDE).
* Copyright (c) 2000-2007 EDE Authors.
*
* This program is licensed under terms of the
* GNU General Public License version 2 or newer.
* See COPYING for details.
*/
#ifndef __EVOKESERVICE_H__
#define __EVOKESERVICE_H__
#include "Log.h"
#include "Xsm.h"
#ifdef HAVE_COMPOSITE
#include "Composite.h"
#endif
2007-07-30 17:25:13 +04:00
#include <edelib/List.h>
2007-07-11 20:03:18 +04:00
#include <edelib/String.h>
#include <FL/x.h>
#include <pthread.h>
2007-07-11 20:03:18 +04:00
struct EvokeClient {
2007-07-30 17:25:13 +04:00
edelib::String desc; // short program description (used in Starting... message)
2007-07-11 20:03:18 +04:00
edelib::String icon; // icon for this client
edelib::String exec; // program name/path to run
};
struct EvokeProcess {
edelib::String cmd;
pid_t pid;
};
struct QueuedSignal {
pid_t pid;
int signum;
};
typedef edelib::list<EvokeClient> ClientList;
typedef edelib::list<EvokeClient>::iterator ClientListIter;
typedef edelib::list<edelib::String> StringList;
2007-07-30 17:25:13 +04:00
typedef edelib::list<edelib::String>::iterator StringListIter;
typedef edelib::list<EvokeProcess> ProcessList;
typedef edelib::list<EvokeProcess>::iterator ProcessListIter;
typedef edelib::list<QueuedSignal> SignalQueue;
typedef edelib::list<QueuedSignal>::iterator SignalQueueIter;
2007-07-11 20:03:18 +04:00
class EvokeService {
private:
2007-07-30 17:25:13 +04:00
bool is_running;
2007-07-11 20:03:18 +04:00
Log* logfile;
Xsm* xsm;
#ifdef HAVE_COMPOSITE
Composite* composite;
#endif
2007-07-11 20:03:18 +04:00
char* pidfile;
2007-07-30 17:25:13 +04:00
char* lockfile;
2007-07-11 20:03:18 +04:00
Atom _ede_shutdown_all;
Atom _ede_spawn;
2007-07-30 17:25:13 +04:00
Atom _ede_evoke_quit;
2007-07-11 20:03:18 +04:00
ClientList clients;
ProcessList processes;
int wake_up_pipe[2];
2007-07-11 20:03:18 +04:00
public:
EvokeService();
~EvokeService();
static EvokeService* instance(void);
2007-07-30 17:25:13 +04:00
void start(void) { is_running = true; }
void stop(void) { is_running = false; }
bool running(void) { return is_running; }
bool setup_channels(void);
2007-07-11 20:03:18 +04:00
bool setup_logging(const char* file);
2007-07-30 17:25:13 +04:00
bool setup_pid(const char* file, const char* lock);
2007-07-11 20:03:18 +04:00
void setup_atoms(Display* d);
2007-07-30 17:25:13 +04:00
bool init_splash(const char* config, bool no_splash, bool dry_run);
void init_autostart(bool safe);
2007-07-30 17:25:13 +04:00
void init_xsettings_manager(void);
void stop_xsettings_manager(bool serialize);
void init_composite(void);
2007-07-30 17:25:13 +04:00
int handle(const XEvent* ev);
A lot of changes, especially the ways how screen is repainted (in composite). Composite will now draw only damaged regions, and their damage is (now) correctly reported, mostly due changes in main FLTK loop. Also there are two ways how evoke will be running: if USE_FLTK_LOOP_EMULATION is defined (default yes), it will fully emulate FLTK loop (as done before). Oposite way (without emulation) it will relay on FLTK message passing, but it is very unpredictable since FLTK will sometime miss SelectionClear events (XSETTINGS relay on it), probably due large XDamageNotify throttling. When emulation is used, there are no such problems since all events are processed before they are routed to FLTK. In composite is added another way of repainting (when USE_CHECK is defined), and it will relay on Fl::add_check() function; there are some differences between this function and timer used for screen refresh. Timer will try to refresh it every XX ms and when there are large number of XDamageNotify reports, this will not be suitable for movements smoothing on the screen; on other hand add_check() will call callback every time when event is processed, which brings smooth movements. For now only timer is used untill I finish compositing stuff. Also composite will handle messages from it's own add_handler() since (somehow), all pending XDamageNotify events will not be correctly reported inside EvokeService handler. And about splash... splash will now keep it's window at the top, no matter what window is raised. This is a small hack until I implement _NET_WM_WINDOW_TYPE_SPLASH in edewm (I don't have to say that this hack works for all wm's I tested :P). Sound from splash is removed; reason for this is when evoke starts childs (only when X session was started), device descriptors will be used by childs too making sound device unusable and marked as busy. This can be solved by using better sound library, which is story for itself...
2008-01-14 15:50:30 +03:00
int composite_handle(const XEvent* ev);
2007-07-11 20:03:18 +04:00
Log* log(void) { return logfile; }
2007-07-30 17:25:13 +04:00
void service_watcher(int pid, int signum);
void wake_up(int fd);
void run_program(const char* cmd, bool enable_vars = 1);
void register_process(const char* cmd, pid_t pid);
void unregister_process(pid_t pid);
bool find_and_unregister_process(pid_t pid, EvokeProcess& pc);
void quit_x11(void);
A lot of changes, especially the ways how screen is repainted (in composite). Composite will now draw only damaged regions, and their damage is (now) correctly reported, mostly due changes in main FLTK loop. Also there are two ways how evoke will be running: if USE_FLTK_LOOP_EMULATION is defined (default yes), it will fully emulate FLTK loop (as done before). Oposite way (without emulation) it will relay on FLTK message passing, but it is very unpredictable since FLTK will sometime miss SelectionClear events (XSETTINGS relay on it), probably due large XDamageNotify throttling. When emulation is used, there are no such problems since all events are processed before they are routed to FLTK. In composite is added another way of repainting (when USE_CHECK is defined), and it will relay on Fl::add_check() function; there are some differences between this function and timer used for screen refresh. Timer will try to refresh it every XX ms and when there are large number of XDamageNotify reports, this will not be suitable for movements smoothing on the screen; on other hand add_check() will call callback every time when event is processed, which brings smooth movements. For now only timer is used untill I finish compositing stuff. Also composite will handle messages from it's own add_handler() since (somehow), all pending XDamageNotify events will not be correctly reported inside EvokeService handler. And about splash... splash will now keep it's window at the top, no matter what window is raised. This is a small hack until I implement _NET_WM_WINDOW_TYPE_SPLASH in edewm (I don't have to say that this hack works for all wm's I tested :P). Sound from splash is removed; reason for this is when evoke starts childs (only when X session was started), device descriptors will be used by childs too making sound device unusable and marked as busy. This can be solved by using better sound library, which is story for itself...
2008-01-14 15:50:30 +03:00
//void update_screen(void);
2007-07-11 20:03:18 +04:00
};
#define EVOKE_LOG EvokeService::instance()->log()->printf
/*
* FIXME: This should be probably declared somewhere outside
* or in edelib as separate class
*/
class Mutex {
private:
pthread_mutex_t mutex;
Mutex(const Mutex&);
Mutex& operator=(const Mutex&);
public:
Mutex() { pthread_mutex_init(&mutex, 0); }
~Mutex() { pthread_mutex_destroy(&mutex); }
void lock(void) { pthread_mutex_lock(&mutex); }
void unlock(void) { pthread_mutex_unlock(&mutex); }
};
2007-07-11 20:03:18 +04:00
#endif