Re: [dev] looking for a simple music player

[Josuah Demangeon]

Simple Audio Daemon may be interesting:

http://git.2f30.org/sad/files.html

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

Greg Reagle wrote:
> If it were possible to get st to do the same thing, such a feature would
> probably not be included in the main repository due to the preference for
> small fast and simple that characterizes suckless programs.

Heyho,

I agree. The main point here is imho that dwm already has a fullscreen "mode"
(like I described in my other mails), so why should we add it to our X clients
as well? It would be redundant.

--Markus

Re: [dev] [st] Full screen without menu bar?

[Greg Reagle]

I think that st does not have a menu bar.  What are you referring to? 
Perhaps you mean the title bar [1]?  If you are referring to the title
bar or any other window decoration [2], they are drawn by the window
manager, so you need to tell the window manager to display full screen. 
What window manager are you using?

On the other hand, Firefox's View > Full Screen (F11 key) does seem to
do the trick, regardless of the window manager.  If it were possible to
get st to do the same thing, such a feature would probably not be
included in the main repository due to the preference for small fast and
simple that characterizes suckless programs.  But it might be accepted
as a patch [3].

[1]
https://upload.wikimedia.org/wikipedia/commons/1/14/Window_%28windowing_system%29.svg
[2] https://en.wikipedia.org/wiki/Window_decoration
[3] http://st.suckless.org/patches/

Re: [dev] looking for a simple music player

[Amer]

I prefer ranger + mpv/cli for that.
   * filter/sort/tag/select by ranger
   * play selection/tag/yankbuf by mpv

Maybe, the single desirable extension to that -- is to auto open
narrow bar at bottom in split tmux window, to background mpv from
ranger. But desire isn't too strong to actually write that now ;)

Re: [dev] Some core tools

[Mattias Andrée]

It looks pretty good, maybe we should recommend it as an
external component.

On Tue, 7 Feb 2017 09:43:42 -0500
stephen Turner  wrote:

> I think this was blocked by the mailing list, sorry if
> its a duplicate. I wanted to mention that there is a m4
> converted from a bsd rewrite of m4 into a more Linux
> compatible version, he advised it had all the popularly
> used features but may be missing a few of the lesser
> used. I for one have used it for a while with pcc and
> haven't seen issues related to m4. Perhaps this would be
> a helpful starting point for you.
> 
>  http://haddonthethird.net/m4/
> 
> On Mon, Feb 6, 2017 at 9:31 AM, stephen Turner
>  wrote:
> > As far as m4 is concerned I happened to meet a guy who
> > converted a bsd rewrite of m4 into a more Linux
> > compatible version, he advised it had all the popularly
> > used features but may be missing a few of the lesser
> > used. I for one have used it for a while with pcc and
> > haven't seen issues related to m4. Perhaps this would
> > be a helpful starting point for you.
> >
> > http://haddonthethird.net/m4/
> >
> >
> > On Friday, February 3, 2017,
> >  wrote:  
> >>
> >> On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias
> >> Andrée wrote:  
> >> > I'm work on implementing make(1)  
> >>
> >> In theory, linux kbuild should be a good reference for
> >> the minimum set of makefile extensions to code. Well,
> >> in theory, the guys paid full-time at the
> >> linux fondation to work on kbuild, should have
> >> constraint themselves to use the
> >> bare minimum of makefile extensions, and be honest
> >> about it (they aren't, be
> >> carefull). suckless: better have a bit more roughness
> >> in the makefile than depends on super duper makefile
> >> extensions... which would make coding an alternative
> >> to make something crazy or insane. It's like C, the
> >> bare minimum of extensions would be those required to
> >> compile a kernel like linux (a good part of C89 syntax
> >> is already to much, hence
> >> even more with C99), but the gcc inline assembly is
> >> critical. The "right" answer would be to abstract away
> >> what's really needed (minimal) from a C toolchain for
> >> a reasonable linux build (even clang/llvm people
> >> failed).
> >>
> >> --
> >> Sylvain
> >>  
> >  
> 



pgpV3vHN2USRH.pgp
Description: OpenPGP digital signature

Re: [dev] looking for a simple music player

[Joseph Graham]

On Tue, Feb 07, 2017 at 08:25:02PM +0100, Cág  wrote:
> Hi,
> 
> I'm looking for something that looks like noice when I'm in my music
> folder: basically a list of file names and the current song's name and
> length at the bottom. No need for colours and album/year; ideally 
> it'd be customised by  editing config.h. Maybe mplayer, ffmpeg
> or gstreamer based.
> 
> Is there something like that?
> 
> Thanks
> 
> --
> Cág
> 

Hey, what's wrong with mpd and ncmpc?

-- 
Joseph Graham, techno-philosopher and Free Software advocate. 

I have a blog: http://www.naughtycomputer.uk/
I write software: https://www.suckmore.uk/
I run a web forum: https://www.freesoftwareuk.org.uk/
And a shop: https://www.freedcomputer.uk/

Re: [dev] looking for a simple music player

[Josuah Demangeon]

I would also be interested by such a program if one of you already know one.  
My workaround is this script:

http://github.com/josuah/config/raw/master/bin/play

[dev] looking for a simple music player

[Cág]

Hi,

I'm looking for something that looks like noice when I'm in my music
folder: basically a list of file names and the current song's name and
length at the bottom. No need for colours and album/year; ideally 
it'd be customised by  editing config.h. Maybe mplayer, ffmpeg
or gstreamer based.

Is there something like that?

Thanks

--
Cág

Re: [dev] Some core tools

[stephen Turner]

I think this was blocked by the mailing list, sorry if its a
duplicate. I wanted to mention that there is a m4 converted from a bsd
 rewrite of m4 into a more Linux compatible version, he advised it had all
 the popularly used features but may be missing a few of the lesser used. I
 for one have used it for a while with pcc and haven't seen issues related
 to m4. Perhaps this would be a helpful starting point for you.

 http://haddonthethird.net/m4/

On Mon, Feb 6, 2017 at 9:31 AM, stephen Turner
 wrote:
> As far as m4 is concerned I happened to meet a guy who converted a bsd
> rewrite of m4 into a more Linux compatible version, he advised it had all
> the popularly used features but may be missing a few of the lesser used. I
> for one have used it for a while with pcc and haven't seen issues related to
> m4. Perhaps this would be a helpful starting point for you.
>
> http://haddonthethird.net/m4/
>
>
> On Friday, February 3, 2017,  wrote:
>>
>> On Thu, Feb 02, 2017 at 06:45:49PM +0100, Mattias Andrée wrote:
>> > I'm work on implementing make(1)
>>
>> In theory, linux kbuild should be a good reference for the minimum set of
>> makefile extensions to code. Well, in theory, the guys paid full-time at
>> the
>> linux fondation to work on kbuild, should have constraint themselves to
>> use the
>> bare minimum of makefile extensions, and be honest about it (they aren't,
>> be
>> carefull). suckless: better have a bit more roughness in the makefile than
>> depends on super duper makefile extensions... which would make coding an
>> alternative to make something crazy or insane.
>> It's like C, the bare minimum of extensions would be those required to
>> compile
>> a kernel like linux (a good part of C89 syntax is already to much,
>> hence
>> even more with C99), but the gcc inline assembly is critical. The "right"
>> answer would be to abstract away what's really needed (minimal) from a C
>> toolchain for a reasonable linux build (even clang/llvm people failed).
>>
>> --
>> Sylvain
>>
>

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

doug livesey wrote:
> I shall have a play with that after work, thankyou!

Heyho,

I just noticed I did not update the patch on the website yet. I did this now, so
make sure to use the latest one[0], which is also simpler than the previous ones
and probably does not produce as many merge conflicts if you have other patches
in use.

Also note that you have to set resizehints to false, because st will try to fix
its size to an exact multiple of one character which probably leaves some gaps
around the window.

--Markus

0: http://dwm.suckless.org/patches/dwm-noborder-20170207-bb3bd6f.diff

Re: [dev] [st] Full screen without menu bar?

[doug livesey]

I shall have a play with that after work, thankyou!

On 7 February 2017 at 11:14, Markus Teich  wrote:
> Heyho doug,
>
> doug livesey wrote:
>> I'd have to figure out how to code that patch, first! :)
>
> Nope, just use that[0] patch.
>
>> However, everything I've tried so far hasn't enabled me to run st in
>> full-screen mode, so it's looking like the window manager doesn't enable full
>> screen without the app enabling it.
>
> After applying the patch just switch to monocle mode and toggle the bar. I use
> it all the time, also for videos. I don't like application level fullscreen
> modes.
>
> Use the force, read the source!
> --Markus
>
>
> 0: http://dwm.suckless.org/patches/noborder

Re: [dev] [st] Full screen without menu bar?

[Markus Teich]

Heyho doug,

doug livesey wrote:
> I'd have to figure out how to code that patch, first! :)

Nope, just use that[0] patch.

> However, everything I've tried so far hasn't enabled me to run st in
> full-screen mode, so it's looking like the window manager doesn't enable full
> screen without the app enabling it.

After applying the patch just switch to monocle mode and toggle the bar. I use
it all the time, also for videos. I don't like application level fullscreen
modes.

Use the force, read the source!
--Markus


0: http://dwm.suckless.org/patches/noborder

Re: [dev] [st] Full screen without menu bar?

[doug livesey]

I'd have to figure out how to code that patch, first! :)
I totally see the sense in keeping the concerns separated between an
app and a window manager.
However, everything I've tried so far hasn't enabled me to run st in
full-screen mode, so it's looking like the window manager doesn't
enable full screen without the app enabling it.
Thanks for your considered response,
   Doug.

On 7 February 2017 at 08:45, Raphaël Proust  wrote:
> Hi,
>
> Typically, window decorations are for the window manager to handle.
> Although applications can help (e.g., by providing shortcuts and
> special full-screen modes), I think that the separation of concerns
> (between the roles of the wm and the applications) is considered more
> suckless. As a result, I don't think such code would appear in the
> core st. You are welcome to make a patch available to the community.
>
> Cheers,
>
>
> On 7 February 2017 at 08:00, doug livesey  wrote:
>> Hi -- is it possible to get st to run full screen without the menu bar?
>> Like when I press F11 when I'm running gnome-terminal.
>> (I'm running Linux Mint, btw.)
>> Thanks,
>>Doug.
>>
>
>
>
> --
> __
> Raphaël Proust
>

Re: [dev] [st] Full screen without menu bar?

[Raphaël Proust]

Hi,

Typically, window decorations are for the window manager to handle.
Although applications can help (e.g., by providing shortcuts and
special full-screen modes), I think that the separation of concerns
(between the roles of the wm and the applications) is considered more
suckless. As a result, I don't think such code would appear in the
core st. You are welcome to make a patch available to the community.

Cheers,


On 7 February 2017 at 08:00, doug livesey  wrote:
> Hi -- is it possible to get st to run full screen without the menu bar?
> Like when I press F11 when I'm running gnome-terminal.
> (I'm running Linux Mint, btw.)
> Thanks,
>Doug.
>



-- 
__
Raphaël Proust

[dev] [st] Full screen without menu bar?

[doug livesey]

Hi -- is it possible to get st to run full screen without the menu bar?
Like when I press F11 when I'm running gnome-terminal.
(I'm running Linux Mint, btw.)
Thanks,
   Doug.