headers
Diogo F. S. Ramos | 24 Apr 2012 08:22
Picon

[STUMP] A stumpwm's module

I've been using a *very* primitive code to interact with pulseaudio and
I decided to pack it as a "module" [0].

Now, there were discussions in the past for what a new module to stumpwm
should look like, here, at the irc channel and also in the wiki [1].

I've tried to summarize it all in my module, but I'm not sure if I did
it right.

First, using a library called `quickproject', I've created a normal CL
package called `pavol' where I export three symbols. This package uses
`:stumpwm'.

I've also created an asdf file where I declare a dependency in stumpwm.

This way, I can create symbols outside stumpwm package.

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.

Also, because the procedure `define-key' only accepts commands, to make
the life of the user easier, I decided to define three of them. To do
it, I had to use `(in-package #:stumpwm)' inside my package. I don't
know if this is OK or not.

The objective of all of this is to make it easy to be loaded using
quicklisp and to not clutter the namespace of stumpwm.

What do you think?
(Continue reading)

Permalink | Reply |
headers
Max Mikhanosha | 24 Apr 2012 16:34

Re: [STUMP] A stumpwm's module

At Tue, 24 Apr 2012 03:22:01 -0300,
Diogo F. S. Ramos wrote:
> 
> I've been using a *very* primitive code to interact with pulseaudio and
> I decided to pack it as a "module" [0].
> 
> This way, I can create symbols outside stumpwm package.
> 
> 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.
> 
> Also, because the procedure `define-key' only accepts commands, to make
> the life of the user easier, I decided to define three of them. To do
> it, I had to use `(in-package #:stumpwm)' inside my package. I don't
> know if this is OK or not.

Same as above, OK in my book, but I'm just a user like you not a
maintainer :-)

For whatever its worth, I had the same hack for over a year, rather
then go all lispy I thrown together a zsh script.. IMHO it is
extremely useful to have an "input" parameter that chooses input based
on name. This way I have bound super-W and super-R to control amarok
volume, s-S and s-F to control master volume, and s-X and s-V to
control Alsa volume, which is what firefox/chrome uses.
(Continue reading)

Permalink | Reply |
headers
Diogo F. S. Ramos | 25 Apr 2012 02:37
Picon

Re: [STUMP] A stumpwm's module

Max Mikhanosha <max <at> openchat.com> 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.

>> Also, because the procedure `define-key' only accepts commands, to make
>> the life of the user easier, I decided to define three of them. To do
>> it, I had to use `(in-package #:stumpwm)' inside my package. I don't
>> know if this is OK or not.
>
> Same as above, OK in my book, but I'm just a user like you not a
> maintainer :-)

My rationale for this decision was that, even if defining a command
clutters stumpwm namespace, this is not a big issue as the "module"
intention is to extend stumpwm.

Maybe it's more like a post rationalization than nothing else.

> For whatever its worth, I had the same hack for over a year, rather
> then go all lispy I thrown together a zsh script.. IMHO it is
(Continue reading)

Permalink | Reply |
headers
Daimrod | 25 Apr 2012 08:22
Picon

Re: [STUMP] A stumpwm's module

diogofsr <at> gmail.com (Diogo F. S. Ramos) writes:

> Max Mikhanosha <max <at> openchat.com> 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.
Permalink | Reply |
headers
Diogo F. S. Ramos | 25 Apr 2012 17:59
Picon

Re: [STUMP] A stumpwm's module

Daimrod <daimrod <at> gmail.com> writes:

> diogofsr <at> gmail.com (Diogo F. S. Ramos) writes:
>
>> Max Mikhanosha <max <at> openchat.com> 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
(Continue reading)

Permalink | Reply |
headers
Scott Jaderholm | 21 May 2012 08:10
Picon
Gravatar

Re: [STUMP] A stumpwm's module

On Wed, Apr 25, 2012 at 8:59 AM, Diogo F. S. Ramos <diogofsr <at> gmail.com> wrote:

Daimrod <daimrod <at> gmail.com> writes:

> diogofsr <at> gmail.com (Diogo F. S. Ramos) writes:
>
>> Max Mikhanosha <max <at> openchat.com> 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
_______________________________________________
Stumpwm-devel mailing list
Stumpwm-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Permalink | Reply |
headers
Scott Jaderholm | 21 May 2012 08:58
Picon
Gravatar

Re: [STUMP] A stumpwm's module

On Sun, May 20, 2012 at 11:10 PM, Scott Jaderholm <jaderholm <at> gmail.com> wrote:
>
> On Wed, Apr 25, 2012 at 8:59 AM, Diogo F. S. Ramos <diogofsr <at> gmail.com> wrote:
>>
>> Daimrod <daimrod <at> gmail.com> writes:
>>
>> > diogofsr <at> gmail.com (Diogo F. S. Ramos) writes:
>> >
>> >> Max Mikhanosha <max <at> openchat.com> 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
 <at>  <at>  -48,7 +48,9  <at>  <at> 

 (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 #\# #\:)))))

 <at>  <at>  -92,5 +94,5  <at>  <at> 

 (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))
Permalink | Reply |
headers
Diogo F. S. Ramos | 21 May 2012 23:49
Picon

Re: [STUMP] A stumpwm's module

Scott Jaderholm <jaderholm <at> gmail.com> writes:

>> 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.

Good idea.

Thank you for the patch.

The new code is already up at gitorious.

--

-- 
Diogo F. S. Ramos
Permalink | Reply |
headers
Scott Jaderholm | 3 Aug 2012 02:58
Picon
Gravatar

Re: [STUMP] A stumpwm's module

Hey Diogo,

Do you still use pavol? I thought of another feature: per app volume setting.

I am thinking of this kind of UI: a command that first presents a menu
of apps (the result of pacmd's show sink-inputs), possibly including
the full command name (application.name is included in output, but
it's only "mplayer", so might be better to get pid and full name such
as "mplayer foo.mov" to make choosing between multiple mplayers
easier). It also might be nice to present the current volume for each
app in that menu. When an app is selected, it goes to a UI like the
current ui with the same keystrokes, progressbar, muting, etc.

The volume can be set with pacmd's set-sink-input-volume.

Scott

On Mon, May 21, 2012 at 2:49 PM, Diogo F. S. Ramos <diogofsr <at> gmail.com> wrote:
> Scott Jaderholm <jaderholm <at> gmail.com> writes:
>
>>> 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.
>
> Good idea.
>
> Thank you for the patch.
>
> The new code is already up at gitorious.
>
> --
> Diogo F. S. Ramos
Permalink | Reply |
headers
Diogo F. S. Ramos | 4 Aug 2012 00:59
Picon

Re: [STUMP] A stumpwm's module

Scott Jaderholm <jaderholm <at> gmail.com> writes:

> Hey Diogo,

Hey Scott.

> Do you still use pavol?

Sure I use. Everyday. :^)

> I thought of another feature: per app volume setting.
>
> I am thinking of this kind of UI: a command that first presents a menu
> of apps (the result of pacmd's show sink-inputs), possibly including
> the full command name (application.name is included in output, but
> it's only "mplayer", so might be better to get pid and full name such
> as "mplayer foo.mov" to make choosing between multiple mplayers
> easier). It also might be nice to present the current volume for each
> app in that menu. When an app is selected, it goes to a UI like the
> current ui with the same keystrokes, progressbar, muting, etc.
>
> The volume can be set with pacmd's set-sink-input-volume.

Uh, I thought about this when I started writing pavol but decided it was
too much for my personal usage. I personally never had the need to
change the volume of a specific application, only the global one. Also,
I couldn't figure out a good UI for it. It seems you solved the latter
problem.

I'll take a look at it!
Permalink | Reply |
headers
Diogo F. S. Ramos | 8 Aug 2012 05:03
Picon

Re: [STUMP] A stumpwm's module

Scott Jaderholm <jaderholm <at> gmail.com> writes:

> Do you still use pavol? I thought of another feature: per app volume setting.

Hey Scott!

I created a new branch called `application-sink' to implement this. The
code is a mess, I confess, but I think I got something working.

Try it and tell me if it is what you envisioned.

I didn't implement the application name thing because some programs are
started using really long lines and I'm aware of the not correctly
justified text when picking the application.

Anyway, the new command is called `pavol-application-list'.
Permalink | Reply |
headers
Scott Jaderholm | 10 Aug 2012 07:18
Picon
Gravatar

Re: [STUMP] A stumpwm's module

Diogo,

Cool, this does the job for me. Thank you!

I needed this change on my system.

-(defcommand pavol-interactive (&optional (index 0)) (:rest)
+(defcommand pavol-interactive (&optional (index "0")) (:rest)

I also did this as a temporary measure because I was getting a no-name
result when I use "pactl load-module module-equalizer-sink".

(defun sink-input-index-name (sink-input-index)
   "The application name of the sinput index."
-  (ppcre:register-groups-bind (name)
-      ("\\ *application.name = (.*)" sink-input-index)
-    (subseq name 1 (1- (length name)))))
+  (or (ppcre:register-groups-bind (name)
+          ("\\ *application.name = (.*)" sink-input-index)
+        (subseq name 1 (1- (length name))))
+      "equalizer"))

I guess it will take some time to see how often I use this. If I find
that I use it quite a bit I'll probably add in full command name, even
if they're long, because I run several mplayer's at the same time.

Thanks again,
Scott

On Tue, Aug 7, 2012 at 8:03 PM, Diogo F. S. Ramos <diogofsr <at> gmail.com> wrote:
> Scott Jaderholm <jaderholm <at> gmail.com> writes:
>
>> Do you still use pavol? I thought of another feature: per app volume setting.
>
> Hey Scott!
>
> I created a new branch called `application-sink' to implement this. The
> code is a mess, I confess, but I think I got something working.
>
> Try it and tell me if it is what you envisioned.
>
> I didn't implement the application name thing because some programs are
> started using really long lines and I'm aware of the not correctly
> justified text when picking the application.
>
> Anyway, the new command is called `pavol-application-list'.
Permalink | Reply |
headers
Diogo F. S. Ramos | 10 Aug 2012 08:14
Picon

Re: [STUMP] A stumpwm's module

Scott Jaderholm <jaderholm <at> gmail.com> writes:

> Cool, this does the job for me. Thank you!

:^)

> I needed this change on my system.
>
> -(defcommand pavol-interactive (&optional (index 0)) (:rest)
> +(defcommand pavol-interactive (&optional (index "0")) (:rest)

Strange, although I confess I wrestled with this specific part of the
code.

> I also did this as a temporary measure because I was getting a no-name
> result when I use "pactl load-module module-equalizer-sink".
>
> (defun sink-input-index-name (sink-input-index)
>    "The application name of the sinput index."
> -  (ppcre:register-groups-bind (name)
> -      ("\\ *application.name = (.*)" sink-input-index)
> -    (subseq name 1 (1- (length name)))))
> +  (or (ppcre:register-groups-bind (name)
> +          ("\\ *application.name = (.*)" sink-input-index)
> +        (subseq name 1 (1- (length name))))
> +      "equalizer"))

Yeah, I assumed that everything had an 'application.name' because I
always saw one in my tests. Apparently I was wrong :^(. Oh well.

> I guess it will take some time to see how often I use this. If I find
> that I use it quite a bit I'll probably add in full command name, even
> if they're long, because I run several mplayer's at the same time.

Looking at the problem now, there is a field called 'media.name' that
could be used for some sort of identification, but unfortunately not
every application seems to fill it with useful information. Amarok set
it with the name of the music and author, but mplayer just writes "audio
stream" and Flash's plugging with "ALSA Playback".
Permalink | Reply |

Gmane