Re: 'r2l' continuation

[mulix]

On Tue, 3 Jul 2001, guy keren wrote:

> i think that a good method to keep going forwards is as follows:
>
> we have our arguments. we'll have several competing implementations done.
> some (group A) will keep working (i.e. actually coding) with the current
> file-based mechanisms, and try to enhance it to work on a per-window
> situation, and make it work with as many applications as possible. noet
> that this approach will be good enough for the home user, who runs all
> their apps on a single machine, and thus for them, 1 display = 1 file
> system.

i'm in.

> let the trials begin!

very well. i now refer to your original email, which started this
thread.

>>>1. combine the r2l efforts.

in what way? for what purpose? let's define *exactly* what our r2l needs
to do, so we know what to code ;)

>>>2. take out the 'file manipulating' part into a seperate library,
      that will be used by all programs (biditext, r2l and any relevant
      daemon  process, if any).

i can do this easily. check out file_ops.[hc] in my r2l package.
here's my interface, anything else we need?

/* gets one char* parameter, the name of the file to check */
/* returns 1 if it exists, 0 if not, -1 on errors */
int file_exists(const char* file_name);

/* return 1 if the file was deleted, -1 on errors */
int delete_file(const char* file_name);

/* return the file descriptor ( value >= 0 ) on success and -1 on errors */
int create_file(const char* file_name);

>>>3. modify biditext itself to contain the auto-refresh enhancements,
   instead of keeping two seperate libraries.

emil, can we see your "top secret" code? doesnt matter if it still has
bugs, we know bugs and bugs know us.

>>>>4. decide how the GUI should look and behave, and make it the same
       on all desktop environments.

i'll leave this one to the gui experts... just make sure it's small,
simple and consistent.

>>>i think the file manipulating library (or rather, biditext communications
library, since in the future we might replace the usage of files with
another mechanism)

this library is to be used for biditet and the various r2l apps to talk
to each other, right? so it should support the following (minimal)
interface:

typedef enum{
        R2L_ENABLED,
        R2L_DISABLED,
        R2L_ERROR
} R2L_STATE;

typedef r2llib_type* r2llib_t;

/* initialize */
r2llib_t r2l_init(int* argc, char* argv[]);

/* perform cleanup */
void r2l_destroy(r2llib_t r2l_data);

/* return 1 on success, -1 on failure */
int enable_r2l(r2llib_t r2l_data);

/* return 1 on success, -1 on failure */
int disable_r2l(r2llib_t r2l_data);

/* return 1 on success, -1 on failure */
int toggle_r2l(r2llib_t r2l_data);

/* return the current r2l state on success, R2L_ERROR on failure */
R2L_STATE get_current_state(r2llib_t r2l_data);

anything else? this can be a simple interface, where the actual
operations are mapped one to one to the file operations outlined
earlier.
-- 
mulix
http://www.advogato.com/person/mulix

linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead