stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] A stumpwm's module


From: Scott Jaderholm
Subject: Re: [STUMP] A stumpwm's module
Date: Sun, 20 May 2012 23:58:08 -0700

On Sun, May 20, 2012 at 11:10 PM, Scott Jaderholm <address@hidden> wrote:
>
> On Wed, Apr 25, 2012 at 8:59 AM, Diogo F. S. Ramos <address@hidden> wrote:
>>
>> Daimrod <address@hidden> writes:
>>
>> > address@hidden (Diogo F. S. Ramos) writes:
>> >
>> >> Max Mikhanosha <address@hidden> writes:
>> >>
>> >>>> Unfortunately, by doing all this, I couldn't directly access a function
>> >>>> called `bar', which is not exported by stumpwm, so I had to use `::'. It
>> >>>> looks like a good symbol to export to me.
>> >>>
>> >>> stumpwm export list is IMHO stale, and its impossible to extend it
>> >>> well without using internal symbols, so I see absolutely no problem with 
>> >>> that.
>> >>
>> >> Hum, that's unfortunate.
>> >>
>> >> I think that a nice set of exported symbols would be nice. Of course,
>> >> it's much easier said than done.
>> >
>> > Maybe we could use the two packages #:stumpwm and #:stuwmpm-user by
>> > exporting a small set of symbols in #:stumpwm-user required to use and
>> > configure it and a larger set in #:stumpwm to develop modules with it.
>> >
>> > Currently, the #:stuwmpwm-user package doesn't contain any symbols and
>> > is only used by two modules.
>> >
>> > Ofc to minimize the amount of change required we could simply add
>> > another package like #:stumpwm-dev.
>>
>> Well, as said earlier, I'm not a maintainer, but I don't see a reason to
>> divide the symbols in different packages. It might create confusion by
>> having to decide in which package a symbol should be exported and it's
>> very likely that a "module" will have to use symbols exported by more
>> than one package.
>>
>> I've been making more changes to pavol thanks to the great ideas of
>> Scott and some bug reports and I didn't had to call stumpwm's internals
>> more than the `bar' function. Granted, pavol doesn't have even a page of
>> code, but still.
>>
>
> I've been using this contrib a lot and really like it. On the subject of 
> things not exported from stumpwm: I recommend you change stumpwm:message in 
> pavol.lisp to stumpwm::message-no-timeout. It probably made sense before the 
> switch to its own keymap but now it's easy for the message to disappear while 
> the user is still in the keymap without any indication that something's not 
> normal. I think this change will help there.
>
> Scott

I forgot about the non-interactive pavol commands.

diff --git a/pavol.lisp b/pavol.lisp
index a10dffb..74a08c6 100644
--- a/pavol.lisp
+++ b/pavol.lisp
@@ -48,7 +48,9 @@

 (defun show-volume-bar ()
   (let ((percent (volume)))
-    (stumpwm:message
+    (funcall (if (equal stumpwm:*top-map* pavol:*pavol-keymap*)
+         #'stumpwm::message-no-timeout
+         #'stumpwm:message)
      (format nil "~:[OPEN~;MUTED~]~%^B~3d%^b [^[^7*~a^]]"
              (mutep) percent (stumpwm::bar percent 50 #\# #\:)))))

@@ -92,5 +94,5 @@

 (defcommand pavol-interactive () ()
   "Change the volume interactively using `j', `k' and `m' keys"
-  (pavol:show-volume-bar)
-  (push-top-map pavol:*pavol-keymap*))
+  (push-top-map pavol:*pavol-keymap*)
+  (pavol:show-volume-bar))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]