headers
clemens fischer | 1 Jun 2010 20:26
Favicon

Re: Running an application at start up

José Romildo Malaquias wrote:

> I am new to sawfish and I want to know how to run an application
> (fbpanel) at sawfish start up. I did not found this information in the
> documentation.

I'm doing something like this:

    (add-hook 'after-initialization-hook
        (unless batch-mode (system "fbpanel &"))
        t)

I don't know if fbpanel can be started this way or if using this hook is
the best way.

clemens
Permalink | Reply | 0 comments |
headers
José Romildo Malaquias | 2 Jun 2010 13:14
Picon

Default key bindings

Hello.

Where can I easily find the default key bindings for sawfish?

Romildo
Permalink | Reply | 1 comment |
headers
Christopher Bratusek | 2 Jun 2010 13:52
Picon
Favicon
Gravatar

Re: Default key bindings

        check the file "KEYBINDINGS" in the sourctree.

Chris

> -----Ursprüngliche Nachricht-----
> Von: José Romildo Malaquias 
> Gesendet: Mi. 02.06.10 (13:14)
> An: sawfish-list <at> gnome.org
> Betreff: Default key bindings
> 
> Hello.
> 
> Where can I easily find the default key bindings for sawfish?
> 
> Romildo
> 
> 
> -----Ursprüngliche Nachricht Ende-----



freenetMail mobil – Alle E-Mails auf Ihrem Handy versenden und empfangen.
Jetzt kinderleicht und kostenlos einrichten. http://tls.freenet.de/tipp/handymail/index.html
Permalink | Reply | 0 comments |
headers
Teika Kazura | 5 Jun 2010 05:47

Re: [ANNOUNCE] librep 0.90.6

Both librep 0.90.6 and rep-gtk 0.90.3 compiled without problem, and
have been running without problem.

Teika (Teika kazura)
Permalink | Reply | 0 comments |
headers
Teika Kazura | 5 Jun 2010 06:47

Re: [PATCH 0/4] Native dockapp support

Isn't it enough to introduce a new variable "detect-dockapp", and
check its value at dockapp detection in C? Like this:
------------------------------------------------------------------------
  w->wmhints = XGetWMHints (dpy, w->id);
  if (w->wmhints && w->wmhints->flags & StateHint
      && w->wmhints->initial_state == WithdrawnState
      && w->wmhints->flags & IconWindowHint
      && w->wmhints->icon_window != 0
      // ** look here**
      && ( Fsymbol_value(Qdetect_dockapp, Qt) != Qnil)) { 
      /* window in withdrawn state with IconWindow? */
      /* This looks like dockapp... */
      ...
------------------------------------------------------------------------
This is far from the final solution, but at least acceptable.

On Fri, 28 May 2010 23:05:53 +0400, "Alexey I. Froloff" wrote:
> My implementation sucks, not because it makes wrong assumptions, it
> just sucks.

Don't curse, it's the first attempt, and you're boldly beating a new,
hard path. If it doesn't harm, and so serves as to make Sawfish
acceptable for you, why not we take it?

> Implementing the whole "appicon" and "miniwindows" stuff (as a
> separate module, yes) will be better, but I guess I'll need some
> help.

Are there any documentation on how to code an dockapp? I can't find.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Teika Kazura | 5 Jun 2010 06:46

Re: Byte compilation error.

On Sat, 29 May 2010 09:06:42 -0500, Jeremy Hankins wrote:
> Would you like me to go ahead and apply this version [of compilation
> error fix] to git, then?

No, thank you. What I said is our official attitude on 1.6.3, for
the rest of the world. I was responsible, and had to announce one.
Git is mainly for developers, and since you edit is ok, too, we don't
need a further action.

> I wonder if it's the raw order of the directory.

What was necessary was a compilation error fix, and let me forget the
file ordering issue. Many factors are there.  <at> _ <at> 

>> 'requiring itself' [...]
> I was trying to decide if requiring the file might, e.g., hide
> legitimate errors that are introduced in the future.

I didn't notice that, but it must be almost ok. Remember, the trigger
of this error is the edit:
------------------------------------------------------------------------
--- a/lisp/sawfish/wm/state/maximize.jl
+++ b/lisp/sawfish/wm/state/maximize.jl
           sawfish.wm.viewport
-          sawfish.wm.state.shading
-         sawfish.wm.util.prompt)
+          sawfish.wm.state.shading)
------------------------------------------------------------------------
Thus, util.prompt had been loaded "to itself" at byte compilation
after the long chain of module dependency.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jeremy Hankins | 5 Jun 2010 16:24

Re: Byte compilation error.

Teika Kazura <teika <at> lavabit.com> writes:
> On Sat, 29 May 2010 09:06:42 -0500, Jeremy Hankins wrote:

>> The unfinished part has nothing to do with prompt.jl; I can apply
>> that anytime we decide it's time.  In fact, the sawfish that I run
>> myself has this patch applied and has for months.  The problem is
>> that it breaks backward-compatibility since it changes the way the
>> prompt code is called.
>
> We're not in hurry at all, but if you could do it, I'd appreciate it
> deeply. Is it easy for you to write a rough documentation on the
> usage? If it's supplied, then it's easy to update existent codes, so
> there'll be no problem.

Hmm..  Currently there is no documentation for prompt, only the source.
I've been meaning to write up some more thorough docs on using the
prompt module, maybe in the form of a tutorial.  But here's very rough
documentation of the changes:

In the past prompt has worked by allowing a variety of helper functions
and variables to be over-ridden by let statements at the time that
prompt is called.  With my changes in place these things are not passed
implicitly via let statements, but passed explicitly in the call to
prompt.  Here's an example from prompt-extras.jl that I think captures
all the changes: the prompt-for-file function presented as a diff
against the old way of doing things.

 
+(define filename-history (prompt-make-history))
 (define (prompt-for-file #!optional title existing start default)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Alexey I. Froloff | 6 Jun 2010 00:57
Favicon

Re: [ANNOUNCE] rep-gtk 0.90.3

On Fri, May 28, 2010 at 08:37:19PM +0200, Christopher Roy Bratusek wrote:
> a new maintainance-release of the GTK+-binding to librep is available. NOW.
Can't find tag 0.90.3 in git://git.gnome.org/rep-gtk .

--

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/
Permalink | Reply | 3 comments |
headers
Alexey I. Froloff | 6 Jun 2010 00:59
Favicon

Re: [ANNOUNCE] librep 0.90.6

On Fri, May 28, 2010 at 06:33:51PM +0200, Christopher Roy Bratusek wrote:
>    * renamed `file-uid-p' to `file-uid' and `file-gid-p' to `file-gid'
This change affects symbols exported by librep.so.  Either SONAME
should be bumped or old symbols still have to be present.

--

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/
Permalink | Reply | 8 comments |
headers
Alexey I. Froloff | 6 Jun 2010 01:28
Favicon

[PATCH] Provide aliases for backward compatibility

---
 src/files.c    |    2 ++
 src/librep.sym |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/src/files.c b/src/files.c
index ff95a2b..5a6bc78 100644
--- a/src/files.c
+++ b/src/files.c
 <at>  <at>  -1339,6 +1339,7  <at>  <at>  Returns the gid of the file called FILE-NAME
 	 return rep_call_file_handler(handler, op_file_gid,
 			              Qfile_gid, 1, file);
 }
+extern __typeof__ (Ffile_gid) Ffile_gid_p __attribute__ ((alias ("Ffile_gid")));

 DEFUN("file-uid", Ffile_uid, Sfile_uid,
 	(repv file), rep_Subr1) /*
 <at>  <at>  -1357,6 +1358,7  <at>  <at>  Returns the uid of the file called FILE-NAME
 	 return rep_call_file_handler(handler, op_file_uid,
 			 		Qfile_uid, 1, file);
 }
+extern __typeof__ (Ffile_uid) Ffile_uid_p __attribute__ ((alias ("Ffile_uid")));

 DEFUN("file-nlinks", Ffile_nlinks, Sfile_nlinks,
       (repv file), rep_Subr1) /*
diff --git a/src/librep.sym b/src/librep.sym
index 595fba9..56f9651 100644
--- a/src/librep.sym
+++ b/src/librep.sym
 <at>  <at>  -107,7 +107,9  <at>  <at>  Ffile_name_nondirectory
(Continue reading)

Permalink | Reply | 7 comments |

Gmane