2007-08-28 19:54:52 +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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "Autostart.h"
|
|
|
|
#include "icons/warning.xpm"
|
2007-08-29 20:38:00 +04:00
|
|
|
#include "EvokeService.h"
|
2007-08-28 19:54:52 +04:00
|
|
|
|
|
|
|
#include <edelib/Nls.h>
|
2008-09-15 15:00:23 +04:00
|
|
|
#include <FL/Fl_Pixmap.H>
|
|
|
|
#include <FL/Fl.H>
|
2007-08-28 19:54:52 +04:00
|
|
|
|
|
|
|
Fl_Pixmap warnpix(warning_xpm);
|
|
|
|
|
|
|
|
void closeit_cb(Fl_Widget*, void* w) {
|
|
|
|
AstartDialog* win = (AstartDialog*)w;
|
|
|
|
win->hide();
|
|
|
|
}
|
|
|
|
|
2007-08-29 20:38:00 +04:00
|
|
|
void run_sel_cb(Fl_Widget*, void* w) {
|
|
|
|
AstartDialog* win = (AstartDialog*)w;
|
|
|
|
win->run_selected();
|
|
|
|
}
|
|
|
|
|
|
|
|
void run_all_cb(Fl_Widget*, void* w) {
|
|
|
|
AstartDialog* win = (AstartDialog*)w;
|
|
|
|
win->run_all();
|
|
|
|
}
|
|
|
|
|
2007-09-11 18:06:44 +04:00
|
|
|
AstartDialog::AstartDialog(unsigned int sz, bool do_show) : Fl_Window(370, 305, _("Autostart warning")),
|
|
|
|
curr(0), lst_sz(sz), show_dialog(do_show), lst(0) {
|
2007-08-28 19:54:52 +04:00
|
|
|
|
|
|
|
if(lst_sz)
|
|
|
|
lst = new AstartItem[lst_sz];
|
|
|
|
|
2007-09-11 18:06:44 +04:00
|
|
|
if(!show_dialog)
|
|
|
|
return;
|
|
|
|
|
2007-08-28 19:54:52 +04:00
|
|
|
begin();
|
|
|
|
img = new Fl_Box(10, 10, 65, 60);
|
|
|
|
img->image(warnpix);
|
|
|
|
txt = new Fl_Box(80, 10, 280, 60, _("The following applications are registered for starting. Please choose what to do next"));
|
|
|
|
txt->align(FL_ALIGN_INSIDE | FL_ALIGN_LEFT | FL_ALIGN_WRAP);
|
|
|
|
cbrowser = new Fl_Check_Browser(10, 75, 350, 185);
|
2007-08-29 20:38:00 +04:00
|
|
|
rsel = new Fl_Button(45, 270, 125, 25, _("Run &selected"));
|
|
|
|
rsel->callback(run_sel_cb, this);
|
|
|
|
rall = new Fl_Button(175, 270, 90, 25, _("&Run all"));
|
|
|
|
rall->callback(run_all_cb, this);
|
2007-08-28 19:54:52 +04:00
|
|
|
cancel = new Fl_Button(270, 270, 90, 25, _("&Cancel"));
|
|
|
|
cancel->callback(closeit_cb, this);
|
|
|
|
cancel->take_focus();
|
|
|
|
end();
|
|
|
|
}
|
|
|
|
|
|
|
|
AstartDialog::~AstartDialog() {
|
|
|
|
if(lst_sz)
|
|
|
|
delete [] lst;
|
|
|
|
}
|
|
|
|
|
|
|
|
void AstartDialog::add_item(const edelib::String& n, const edelib::String& e) {
|
|
|
|
if(!lst_sz)
|
|
|
|
return;
|
2007-08-29 20:38:00 +04:00
|
|
|
|
|
|
|
if(e.empty())
|
|
|
|
return;
|
|
|
|
|
2007-08-28 19:54:52 +04:00
|
|
|
AstartItem it;
|
|
|
|
it.name = n;
|
|
|
|
it.exec = e;
|
|
|
|
|
|
|
|
lst[curr++] = it;
|
|
|
|
}
|
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
|
|
|
#include <stdio.h>
|
|
|
|
#include <unistd.h>
|
2007-08-28 19:54:52 +04:00
|
|
|
|
|
|
|
void AstartDialog::run(void) {
|
2007-09-11 18:06:44 +04:00
|
|
|
if(!show_dialog) {
|
|
|
|
run_all();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2007-08-28 19:54:52 +04:00
|
|
|
for(unsigned int i = 0; i < curr; i++)
|
|
|
|
cbrowser->add(lst[i].name.c_str());
|
|
|
|
|
|
|
|
if(!shown())
|
|
|
|
show();
|
|
|
|
|
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
|
|
|
while(shown()) {
|
|
|
|
//puts("WAIT WAIT");
|
2007-08-28 19:54:52 +04:00
|
|
|
Fl::wait();
|
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
|
|
|
}
|
2007-08-28 19:54:52 +04:00
|
|
|
}
|
2007-08-29 20:38:00 +04:00
|
|
|
|
|
|
|
void AstartDialog::run_selected(void) {
|
2007-09-11 18:06:44 +04:00
|
|
|
if(!show_dialog)
|
|
|
|
return;
|
|
|
|
|
2007-08-29 20:38:00 +04:00
|
|
|
int it = cbrowser->nchecked();
|
|
|
|
if(!it)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for(unsigned int i = 0; i < curr; i++) {
|
|
|
|
if(cbrowser->checked(i+1))
|
|
|
|
EvokeService::instance()->run_program(lst[i].exec.c_str());
|
|
|
|
}
|
|
|
|
|
|
|
|
hide();
|
|
|
|
}
|
|
|
|
|
|
|
|
void AstartDialog::run_all(void) {
|
|
|
|
if(!curr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for(unsigned int i = 0; i < curr; i++)
|
|
|
|
EvokeService::instance()->run_program(lst[i].exec.c_str());
|
|
|
|
|
|
|
|
hide();
|
|
|
|
}
|