Re: [dev] [edit] Introducing edit, a simple text editor

[David Demelier]

On Wed, 2023-09-27 at 22:33 +0200, Страхиња Радић wrote:
> On closer inspection, termbox2.h does include signal.h itself[1], and
> additionally defines _XOPEN_SOURCE[2] and _DEFAULT_SOURCE, so the
> inclusion of 
> signal.h can't be escaped.
> 
> My testing has shown that when -std=c99 is specified, it is as if
> that switch 
> explicitly undefines _DEFAULT_SOURCE/_XOPEN_SOURCE **defined inside
> the header 
> file** (this is the weird part). If -D_DEFAULT_SOURCE is given as an
> argument, 

This,

I've been played several times with -std and
_POSIX_C_SOURCE/_XOPEN_SOURCE and experienced many different behavior
depending on the system and libc. Example, I remember that setting
_XOPEN_SOURCE could hide non-standard functions which can still be
useful as long as you take care of the proper #define.

Not sure if that helps but I eventually stopped adding flags at all and
use just the defaults everywhere. Otherwise I'd be glad to understand
if there is a complete and strict conformance explanation on those
combinations.

-- 
David

Re: [dev] getting rid of cmake builds

[David Demelier]

On Thu, 2023-09-21 at 09:42 -0400, LM wrote:
> I build a lot of common libraries and programs from source.  Many of
> them are switching to cmake.  I'm not a fan of cmake.  For one thing,
> it's so complicated to build from source code that I can't bootstrap
> the build of cmake itself.  I really would prefer to build as many of
> my tools from source as possible and that includes the build system.
> I've been attempting to create makefiles by hand for some of these
> programs and libraries that now use cmake.  Does anyone have an easy
> or automated way to convert a cmake build to makefiles or another
> less
> complicated build system?  Is anyone else trying to simplify their
> build scripts for commonly used libraries or programs?  Is there a
> way
> to automate the processes or share effort on this?  Thank you.
> 

Hi,

It's near to impossible to convert a CMake project to make
automatically, CMake is almost like a scripting language given the
numerous of things you can do with it.

Keep in mind that plain make (POSIX) is enough for really simple
projects but can come limited when going portable. Although the use of
pkg-config helps there are various places where you will need to pass
additional compiler/linker flags. For those I like GNU make even though
its syntax is somewhat strange at some points.

Which projects are you referring to?

-- 
David

Re: [dev] C variants, compilers and completeness

[David Demelier]

On Mon, 2023-07-24 at 17:38 +0200, Sagar Acharya wrote:
> I see C compilers recommended by suckless are:
> 
> tinycc
> simplecc
> cproc
> qbe
> lacc

qbe isn't a compiler. however cproc is promising but I had various
issues compiling some apps, can't use it as my daily for now.

-- 
David

Re: [dev] Suckless filesystems

[David Demelier]

On Fri, 2023-06-23 at 10:30 +0200, m...@datameer.com wrote:
> Sagar Acharya  wrote:
> > Which are the filesystems which suckless recommends?
> > 
> > In my view, simple ones are FAT32, ext2.
> > 
> > I think journaling is required which I see as within disk backup. A
> > robust and easy fsck like program which corrects errors easily. And
> > a program which periodically checks memory and replaces all
> > corrupted file data with journaled data to be spick and span.
> 
> What do you think about xfs. is it too bloated for you guys?

XFS has nice features and very good and consistent documentation. Note
that it can only be expanded larger and not smaller (some consider this
as showstopper).

Beside that I've never experienced any major problem on XFS/EXT4,
however on OpenBSD I already had several files in /lost+found after a
power failure but you can't really choose something else yet.

-- 
David

Re: [dev] suckless indentation with vim

[David Demelier]

On Sat, 2022-07-02 at 23:07 +0600, NRK wrote:
> Hi,
> 
> The suckless coding style follows "tabs for indent, spaces for
> alignment" philosophy. But afaik, vim doesn't support it natively.
> 
> I remember trying out a couple plugins from here:
> https://vim.fandom.com/wiki/Indent_with_tabs,_align_with_spaces
> but they all failed miserably on many cases.
> 
> 'clang-format' can do this with 'UseTab: AlignWithSpaces' but it also
> does a bunch of *other* stuff (which I don't like) and I also don't
> like
> external formatters and would much rather have my editor do the
> formatting as I'm typing.
> 
> If someone's using vim and follows this style, what plugin and/or
> setting do you use?

I'm not sure if it's really easy to implement a smart alignment. I use
some mapping to switch between et/noet option to insert spaces instead
of tabs and align manually.

nmap , :set et!

Of course, always better to view whitespaces when dealing with that
mix.

-- 
David

Re: [dev] I made a bluetooth-control-thing

[David Demelier]

On Wed, 2022-06-15 at 17:30 +0200, Stefan Mark wrote:
> I was always a bit annoyed by the lack of a simple, gui-based
> bluetooth
> control thing. Like blueman, but not in a scripting language. And
> maybe
> with somewhat simpler interface.
> 
> Thus i did this:
> https://git.weitnahbei.de/nullmark/little_blue_man
> 
> Its written in C, uses drw and dbus and it works. At least for me. It
> lacks many features and proper testing. And i got somewhat
> carried
> away and dabbled with ideas of starting my own toolkit. Turned out,
> such a thing is quite big a thing, thus there is no toolkit, but the
> code is somewhat more complicated than it has to. 
> 
> Anyway, i would like to hear some opinions :)
> 
> Sidenote and a warning: i am not a good c programmer. I just like to
> use it :)

Hi,

There is something wrong with the makefile because each time I type
make it keeps rebuilding everything.

Otherwise, I wanted to test but it exits with:

$ lbm
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  15 (X_QueryTree)
  Resource id in failed request:  0x0
  Serial number of failed request:  12
  Current serial number in output stream:  12

Regards,

-- 
David

Re: [dev] Automatic C header dependency tracking for the redo build-system

[David Demelier]

On Mon, 2022-06-06 at 15:13 +0200, Georg Lehner wrote:
> Hi,
> 
> The topic of header dependency tracking is already addressed since
> the 
> inception of redo by DJB.

About C header dependencies, you can actually do it using POSIX Make
(in the next version, the -include statement is not available yet but
widely supported).

SRCS= foo.c bar.c baz.c
OBJS= ${SRCS:.c=.o}
DEPS= ${SRCS:.c=.d}

.c.o:
${CC} -o $@ -MMD -c $< ${CFLAGS}

all: hello

-include ${DEPS}

hello: ${OBJS}
${CC} -o $@ ${OBJS}

And you're done. On a fresh directory the -include ${DEPS} will
silently fail and rebuild everything. Then .d files will be generated
and touching any file will rebuild exactly what should be.

The only non portable thing is the -MMD option (gcc and clang support
though).

HTH

-- 
David

Re: [dev][dwm][autostart] Patch to make autostart conform to XDG Base Directory specification

[David Demelier]

Le 09/06/2020 à 22:48, Gan Ainm a écrit :
Just pushed a patch that makes autostart conform to the XDG Base 
Directory specification 
(https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). 
That helps to avoid dotfile clutter in the home directory.


dwm will look for the scripts autostart_blocking.sh and autostart.sh 
first in $XDG_DATA_HOME/dwm, then $HOME/.local/share/dwm, and finally in 
$HOME/.dwm. If the first existing directory in that list does not 
contain any autostart file or if neither of the directories exists, dwm 
starts without the autostart feature.


Thank you!

I was planning to write something similar because some applications 
require a working D-Bus session to start (so unable to launch them 
before dwm in .xinitrc). Example: pulseaudio then mpd.


--
David

Re: [dev] Mailing list searching

[David Demelier]

Le 07/05/2019 à 04:05, opal hart a écrit :

On Mon, 6 May 2019 08:13:32 +0200
Hiltjo Posthuma  wrote:


On Mon, May 06, 2019 at 02:34:28AM +, opal hart wrote:

Shouldn't this be a FAQ entry at this point for any suckless projects
depending on Xft?


If only we could teach people to read...



At least by then we'd have an excuse to get mad at people. Either that
or give people an easy way to search the MLs, because [1] doesn't
really encourage searching before posting. To be fair, that should be
expected before posting on any ML, but the fact there's no easy way to
search lists.suckless.org makes it an even bigger issue. And while for
this case, a search for 'xft site:lists.suckless.org' (replace 'xft'
with 'emoji' or 'font' and get similar results), search engines aren't
always quick to index newer posts, so this wouldn't work in all cases.



I can't blame much the user about that issue, because it's a crash 
rather than a warning. Also, when I first encountered the crash myself 
several weeks ago, I firstly also thought it was a problem in st rather 
than in a library. Note that the error does not mention that much xft.


What could help though is definitely add a note in the manual page under 
a section BUGS or in the README/FAQ of st until libxft/freetype is fixed 
upstream.


What do you think?

Regards,

--
David

Re: [dev] Learn C

[David Demelier]

Le 24/03/2019 à 14:33, sylvain.bertr...@gmail.com a écrit :

* do not use enum (hard rule)


I'd be glad to get any reason why not. C is already minimalistic, won't 
you write in assembly next time?


Moreover, enums are often well supported in debuggers and show the 
actual enum constant rather than its value. Also, compilers are smart 
enough to be sure you compare good things:


$ gcc test.c -Wall -Wextra
test.c: In function ‘main’:
test.c:8:8: warning: comparison between ‘enum gender’ and ‘enum color’ 
[-Wenum-compare]

  if (g == red)
^
$ cat test.c
enum gender { male, female };
enum color { red, green, blue };

int main()
{
enum gender g = male;

if (g == red)
return 1;
}


* declare your variables at the beginning of a block (c99 allows declarations a
   bit everywhere, bad). personnally I try to keep my variables declared first, 
then
   the variables with assignment, because it's actually code (presume C
   initializers are code).


Welcome to prehistory. Declaring when you use (with a assignment) makes 
uninitialized variables less often happening.



* I personnaly add a macro #define loop for(;;) and use only 1 loop
   statement (hard rule)


Strange, hiding explicit code for a benefit of 4 keystrokes.


* use sized types: u8 u16 i64 float32 etc... you can use the C
   preprocessor to fix that, but in some case, as a good tradeof (for instance 
in
   "object oriented C code"), add a suffix to your type (u8_t, struct 
my_class_t), then
   for instance you can nest structs, struct base_type_t base_type.


This is completely nonsense. Do you know that using the appropriate 
types is just the best thing to do? For example, it's sometimes even 
better to pass an int rather than a bool as argument/return value 
because the processor has to perform more steps since it will promotes 
the bool to int. In most of the case int is just the way to go. However, 
having those fixed size types in PODs for serialization, hardware access 
and memory management is clean (but with care of alignment/padding).


Regards,

--
David

Re: [dev] surf

[David Demelier]

Le 26/01/2019 à 22:33, Igor Rubel a écrit :

Unfortunately, it seems that XQuartz doesn't support Retina displays properly.


X does not perform any kind of scaling on its own. It's the purpose of 
toolkiks to do that. For example with Gtk applications one should set 
the environment variable GDK_SCALE=2 (at least) to scale 2 times.


Try: GDK_SCALE=2 surf

HTH

--
david

Re: [dev] Coding style: why /* */ and not //?

[David Demelier]

Le 27/12/2018 à 11:10, Silvan Jegen a écrit :

The only downside of //-style comments that I can
see is that they are only allowed since C99[0].


Yes, but C99 was released 20 years ago. Perhaps it's okay to use it 
nowadays :)


Regards,

--
David

Re: [dev] GPL free Linux

[David Demelier]

Le 12/11/2018 à 07:27, Alexander Huemer a écrit :

If you don't like the GPL, why use the Linux kernel in the first place?
Go with {Free,Open,Net}BSD and live happily ever after.


Unfortunately in matter of hardware support, Linux is definitely the 
best selection for now.


Lot of people try to get rid of GPL code just because of the license. 
See OpenBSD and FreeBSD which have switched to clang. They even had a 
special gnu directory for easier removal for those who wants to do 
proprietary stuff with that their systems.


I completely understand the idea of driving away from GNU/GPL when you 
really want to provide flexibility and opensource to the mass. To me GPL 
is only useful for users, not for developers.


My $0.02.

--
David

Re: [dev] freetype2/fc pain

[David Demelier]

Le 23/09/2018 à 06:10, AR Garbe a écrit :

Back in the days I also concluded that the introduction of Xinerama
and multihead support was a bad idea after all.

I'm really at a point to consider forking dwm and dmenu to simply rely
on X11 as it used to be, perhaps with going the extra mile to remove
Xinerama support as well and to rely on single headed setups.


Are you saying that you would like to remove the support for multiple 
screens?


If yes, please don't minimize the number of multiheads setups, both at 
work and at home I have two monitors. Or as Quentin said at least in a 
separate patch.


However, I don't care if dwm runs on two screens without being able to 
have a window in the “middle” split in both views.


Regards,

--
David

Re: [dev] freetype2/fc pain

[David Demelier]

Le 24/09/2018 à 08:19, AR Garbe a écrit :

On 23 September 2018 at 11:56, Eric Pruitt  wrote:

On Sun, Sep 23, 2018 at 09:14:11AM -0700, AR Garbe wrote:

I totally agree. I'd be in favour in a st just using plain X fonts.
This emoji unicode porn and anti-aliasing TTF support doesn't make
sense to me.


It's not just about Emoji or anti-aliasing. If you work with languages
that use non-Latin characters, support for fallback fonts is a must.


Well, are you using st with glyphs that require fallback fonts?
I wonder if at suckless we should aim for the general purpose.



Hello,

Unfortunately, I remember having terminus not rendering some kind of 
unicode characters not even emojis. I think it was some drawing characters.


Many tools like to use those characters (just even tree).

Is freetype/fontconfig the only way to implement fallback characters? I 
remember when dwm switched to Xft a while back ago, I was surprised at 
first but if that choice was made I think there were a lot of good 
reasons isn't it?


Also, I'm not sure if many bitmap fonts render correctly on 4k screens. 
I just love how Fira Mono renders on mine. But I should test some.


--
David

Re: [dev] [st] solarized light patch colors incorrect

[David Demelier]

On Wed, 2018-09-12 at 22:44 +0200, Quentin Rameau wrote:
> And no, it's not my mistake, stop pointing fingers, especially at the
> wrong persons.
> If you had read the thread correctly, it's about a third party patch.
> I didn't write it, the name of the author is accessible.

I have never told it's you, I'm just commenting the quote

I say that bug reports should be accompagned with a patch (yes
please).

-- 
David

Re: [dev] [st] solarized light patch colors incorrect

[David Demelier]

On Fri, 2018-09-07 at 19:39 +0200, Quentin Rameau wrote:
> I say that bug reports should be accompagned with a patch (yes
> please).

Quentin, I agree that patches are welcome, for the colors I understand
that is a easy issue that could be fixed by any newcomer.

However, not everybody can fix everything. For example, I use dwm but
if I find a bug within I'm pretty sure I'll unable to fix it (example I
remember the old SDL issue regarding fullscreen), mostly because I
don't know X11 libraries not because I would not do it. So I think we
can't just ask everyone to provide a patch every single time they
encounter a bug.

Everybody make mistakes and errors and asking others to fix them for
you is a bit rude IMHO. It's like:

- I have found a very small bug in your application
- Just fix it yourself, it's my mistake but it's only you that want it
to be fixed.

Regards,

-- 
David

Re: [dev] [dwm] [PATCH] Do not draw bar if it is hidden

[David Demelier]

On Mon, 2018-08-06 at 19:01 +0200, Petr Šabata wrote:
> On Mon, Aug 06, 2018 at 06:10:02PM +0200, Hiltjo Posthuma wrote:
> > This is not a dwm issue. Please bother the Xft developers.
> 
> While true, there's also no point in executing the code if the
> bar is hidden.

Completely second that.

-- 
David

[dev] [surf] crashing in libcairo

[David Demelier]

Hello,

I've compiled the latest surf from git. Trying to go on reddit.com
immediately crashes the webkit process, surf still runs though but shows
a blank page.

I get this error logged:

[ 7793.051138] WebKitWebProces[2099]: segfault at 0 ip 73434b44 sp
7fffc4e8 error 4 in libcairo.so.2.11400.8[7337e000+125000]

I've tried with midori and it worked fine. So I wonder what happens
under the hood. Do I need to compile webkit in debug mode to give you
more useful information?

Regards,

-- 
David Demelier

Re: [dev] [dwm] firefox fullscreen youtube issue

[David Demelier]

> On Nov 20, 2017, at 7:17 PM, Laslo Hunhold  wrote:
> 
>> I remember some years ago that it worked fine, I wonder if something
>> has changed? Do I need to configure something in firefox/dwm?
> 
> does it work with the latest git-version of dwm?

Yes, it works in git, I'll switch to that.

Thanks!

Re: [dev] [dwm] firefox fullscreen youtube issue

[David Demelier]

> On Nov 20, 2017, at 2:36 PM, Donald Allen  wrote:
> 
> I am not seeing this, with the same version of Firefox on an Arch
> Linux system. You did not say what patches, if any, you have applied
> to dwm. In my case, I have applied only the 'pertag' patch. It's also
> possible that there is something about your changes to config.h that
> is causing the symptom you are seeing. So more information (patches,
> your config.h) would be more likely to get you an answer.
> 

I've just tested with a plain dwm compiled as-is without any modification and 
have the same problem. On my own dwm version I have useless-gap and pertag 
patches. The config.h is almost default and just contains modifications about 
colors, fonts and keybinds.

Regards,

[dev] [dwm] firefox fullscreen youtube issue

[David Demelier]

Hello all,

With firefox 57 and dwm 6.1, watching a video on youtube and clicking on the 
fullscreen button makes the video fill the firefox frame, not the whole screen. 

I remember some years ago that it worked fine, I wonder if something has 
changed? Do I need to configure something in firefox/dwm?

Regards,

-- 
David

[dev] [dwm] switch tag with mouse wheel on root

[David Demelier]

Hello dear dwm users,

I was just wondering how could I switch to the next or previous tag by 
using the mouse wheel on root window.


I think I must add the following :

{ ClkRootWin,MODKEY, Button4, ?? }
{ ClkRootWin,MODKEY, Button5, ?? }

But I don't know what I must add in the argument colon.

Kind regards,

--
David Demelier

Re: [dev] [dwm] switch tag with mouse wheel on root

[David Demelier]

On 21/12/2010 14:14, Rob wrote:

dwm doesn't have this by default, because dwm doesn't have a current
tag, since you can have many activated.
Here's what I do [attached]. It's taken and modified from a ML post I
saw a good while back.

Rob.



Absolutely great! Thanks, this little piece of code should be added to 
the patches/ :-).


Kind regards,

David.

Re: [dev] [dwm] Windows size changes

[David DEMELIER]

2010/11/12 pmarin pacog...@gmail.com:
 AWT_TOOLKIT = MToolkit.
 Sorry.

 On Fri, Nov 12, 2010 at 11:16 PM, pmarin pacog...@gmail.com wrote:
 On Fri, Nov 12, 2010 at 7:58 PM, David DEMELIER
 demelier.da...@gmail.com wrote:
 Hello,

 I was surprised to see that a java window does not update its content,
 in fact nothing changes. If you resize the window nothing happens and
 the usual behavior is that the window updates its content to the new
 size.

 On pekwm or gnome, it works. The window `stretch' its content to the
 maximal size, on dwm nothing happens it stays at white.

 You can try my little example program on a free wm and dwm :

 import javax.swing.*;
 import java.awt.*;

 public class Compteur extends JPanel {
        JButton jp_plus;        /* Bouton plus */
        JButton jp_minus;       /* Bouton moins */

        JTextField jtf_field;   /* Affichage du compteur */

        public Compteur() {
                super ();
                this.setLayout(new BorderLayout());

                jp_plus = new JButton(+);
                jp_minus = new JButton(-);

                jtf_field = new JTextField(0, 20);

                this.add(jp_plus, BorderLayout.WEST);
                this.add(jtf_field, BorderLayout.CENTER);
                this.add(jp_minus, BorderLayout.EAST);
        }

        public static void main(String[] args) {
                JFrame jf = new JFrame(Exercice 2 : Compteur);
                jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                jf.setSize(400,100);

                JPanel jp_cp = new Compteur();

                jf.add(jp_cp);
                jf.setVisible(true);
        }
 }

 Kind regards,

 --
 Demelier David



 When I had problems with Java some years ago I remember to setup the
 environment variable= Mtoolkit  and worked (with a very old version of
 dwm)




Thanks, but it seems this workaround only works for i386 while i'm on
amd64... What a pity

-- 
Demelier David

[dev] [dwm] Windows size changes

[David DEMELIER]

Hello,

I was surprised to see that a java window does not update its content,
in fact nothing changes. If you resize the window nothing happens and
the usual behavior is that the window updates its content to the new
size.

On pekwm or gnome, it works. The window `stretch' its content to the
maximal size, on dwm nothing happens it stays at white.

You can try my little example program on a free wm and dwm :

import javax.swing.*;
import java.awt.*;

public class Compteur extends JPanel {
JButton jp_plus;/* Bouton plus */
JButton jp_minus;   /* Bouton moins */

JTextField jtf_field;   /* Affichage du compteur */

public Compteur() {
super ();
this.setLayout(new BorderLayout());

jp_plus = new JButton(+);
jp_minus = new JButton(-);

jtf_field = new JTextField(0, 20);

this.add(jp_plus, BorderLayout.WEST);
this.add(jtf_field, BorderLayout.CENTER);
this.add(jp_minus, BorderLayout.EAST);
}

public static void main(String[] args) {
JFrame jf = new JFrame(Exercice 2 : Compteur);
jf.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
jf.setSize(400,100);

JPanel jp_cp = new Compteur();

jf.add(jp_cp);
jf.setVisible(true);
}
}

Kind regards,

-- 
Demelier David

Re: [dev] [dwm] adding WM_WINDOW_ROLE rule

[David DEMELIER]

2010/8/8 Kris Maglione maglion...@gmail.com:
 On Sun, Aug 08, 2010 at 09:36:24AM +0200, David DEMELIER wrote:

 It's so sad to see that suckless developers don't want to add 10 lines
 to the code to improve it just because *the developers* think it's
 useless.

 Maybe for people it's useless, but for others it can be useful. Sad.

 Don't get pissy. 10 lines here and there adds up. So does a feature here and
 there, especially when it would likely be used by so few. If you want it and
 you can't convince the developers that it's worthwhile, maintain a patch.
 That's how it works here. If you don't like it, you're welcome to go
 somewhere else.

 --
 Kris Maglione

 The tragedy of modern war is not so much that young men die but that
 they die fighting each other, instead of their real enemies back home
 in the capitals.
        --Edward Abbey




I agree for an optional patch if it's possible.

-- 
Demelier David

Re: [dev] [dwm] adding WM_WINDOW_ROLE rule

[David DEMELIER]

2010/7/27 Anselm R Garbe garb...@gmail.com:
 Hi David,

 On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote:
 There is something that make me sad with dwm, there is a lack of role
 rules for clients. I explain : clients have instance and name using
 WM_CLASS, but there is also WM_WINDOW_ROLE which is really important
 and useful.

 Example : you want your firefox window tiled but not the download
 manager or not the preference client you could make a rule that catch
 the WM_WINDOW_ROLE

 - xprop WM_WINDOW_ROLE on the firefox windows and sub-windows
 -- xprop WM_WINDOW_ROLE
 -- WM_WINDOW_ROLE(STRING) = Preferences # this is preferences
 -- xprop WM_WINDOW_ROLE
 -- WM_WINDOW_ROLE(STRING) = browser # the main window
 -- xprop WM_WINDOW_ROLE
 -- WM_WINDOW_ROLE(STRING) = Manager # the download window

 Why is this so important? Because you can make more rules to specifig
 windows, I personally like to have the main browser window tiled but
 not the download window. This is also the same thing with pidgin,
 pidgin has a conversation window and a buddy list that have differents
 WM_WINDOW_ROLE.

 Of coure we could use the `title' rules but it's different on each
 locale you are using so it sucks as well.

 I would like to write a patch but for the moment I don't find the good
 function that handle WM_WINDOW_ROLE.

 I think the right thing to do would be to extend Rule and applyrules()
 with support for WM_WINDOW_ROLE. However I doubt that many client make
 actually use of WM_WINDOW_ROLE in a consistent way, which is why I
 believe there is no great benefit in doing so -- or in other words,
 yet another proof how hideous X has become ;)

 Cheers,
 Anselm


It's so sad to see that suckless developers don't want to add 10 lines
to the code to improve it just because *the developers* think it's
useless.

Maybe for people it's useless, but for others it can be useful. Sad.

Kind regards.

-- 
Demelier David

Re: [dev] [dwm] adding WM_WINDOW_ROLE rule

[David DEMELIER]

2010/7/27 Rob robpill...@gmail.com:
 On 26 July 2010 22:32, David DEMELIER demelier.da...@gmail.com wrote:
 Hello dear dwm users,

 hi

 There is something that make me sad with dwm, there is a lack of role
 rules for clients. I explain : clients have instance and name using
 WM_CLASS, but there is also WM_WINDOW_ROLE which is really important
 and useful.

 dwm uses XGetClassHint() to retrieve the class and instance, and you
 can't get WM_WINDOW_ROLE like this, so it's not as trivial to add on.

 I've attached a patch (with some dodgy casting) that works for me, but
 it's pretty useless. To have rules work with lots of arbitary WM_*
 rules would mean extending the code a lot for little gain - Iron
 (chromium clone) doesn't set WM_WINDOW_ROLE, for example, and nor does
 surf, nor vimprobable.


Thanks for your work, but there is many applications that also set it.
pidgin, gajim, firefox, gimp ...

 tl;dr:
 However I doubt that many client make
 actually use of WM_WINDOW_ROLE in a consistent way, which is why I
 believe there is no great benefit in doing so -- or in other words,
 yet another proof how hideous X has become ;)

 Rob




-- 
Demelier David

[dev] [dwm] adding WM_WINDOW_ROLE rule

[David DEMELIER]

Hello dear dwm users,

There is something that make me sad with dwm, there is a lack of role
rules for clients. I explain : clients have instance and name using
WM_CLASS, but there is also WM_WINDOW_ROLE which is really important
and useful.

Example : you want your firefox window tiled but not the download
manager or not the preference client you could make a rule that catch
the WM_WINDOW_ROLE

- xprop WM_WINDOW_ROLE on the firefox windows and sub-windows
-- xprop WM_WINDOW_ROLE
-- WM_WINDOW_ROLE(STRING) = Preferences # this is preferences
-- xprop WM_WINDOW_ROLE
-- WM_WINDOW_ROLE(STRING) = browser # the main window
-- xprop WM_WINDOW_ROLE
-- WM_WINDOW_ROLE(STRING) = Manager # the download window

Why is this so important? Because you can make more rules to specifig
windows, I personally like to have the main browser window tiled but
not the download window. This is also the same thing with pidgin,
pidgin has a conversation window and a buddy list that have differents
WM_WINDOW_ROLE.

Of coure we could use the `title' rules but it's different on each
locale you are using so it sucks as well.

I would like to write a patch but for the moment I don't find the good
function that handle WM_WINDOW_ROLE.

With kind regards.

-- 
Demelier David

Re: [dev] dwm-5.8.2 / 9base-6

[David DEMELIER]

2010/6/4 Anselm R Garbe garb...@gmail.com:
 Hi there,

 after the positive feedback to the recent fullscreen fixes it is time
 for a new dwm bugfix release:

  http://dl.suckless.org/dwm/dwm-5.8.2.tar.gz


I'm sorry to disturb you again, but the fullscreen problem is still
here with mplayer. Even fstype=non in mplayer.conf still does'nt scale
the mplayer fullscreen window.

 Also 9base has been updated during the past weeks and contains several
 new commands like ed, sam, unutf and many others.

  http://dl.suckless.org/tools/9base-6.tar.gz

 Have fun,
 Anselm



-- 
Demelier David

Re: [dev] dwm-5.8.1 / dmenu-4.1.1

[David DEMELIER]

2010/5/30 Anselm R Garbe garb...@gmail.com:
 On 29 May 2010 22:18, Sylvain Laurent syll...@gmail.com wrote:
 2010/5/29 Kris Maglione maglion...@gmail.com:
 On Sat, May 29, 2010 at 07:59:39PM +0100, Anselm R Garbe wrote:

 On 29 May 2010 19:17, Anselm R Garbe garb...@gmail.com wrote:

 On 29 May 2010 18:18, Kris Maglione maglion...@gmail.com wrote:

 On Sat, May 29, 2010 at 01:12:15PM +0100, Anselm R Garbe wrote:
 The getfullscreen bit is probably not necessary in most cases. The rest
 of the clientmessage function is a hack, because I don't know the dwm
 sourcecode well enough to do it properly. It's just to show what's 
 required.

 I got a similar impression when reverting the changeset that the EWMH
 fullscreen handling was incomplete.

 Overall my aim is trying to prevent using too much EWMH magic, though as
 things look more clients seem to fully depend on EWMH nowadays for
 fullscreen handling, like chromium.

 I think the intention of the patch wasn't to support EWMH fullscreen so much
 as to tell apps that they were in fullscreen mode. Without it, chromium went
 fullscreen fine, but it still showed its tab bar, etc. A lot of apps (when
 the WM supports EWMH) only show their fullscreen UI when they have the EWMH
 fullscreen hint set on their window. It's actually a good thing in a lot of
 cases, because if you manually force the apps to fullscreen from the WM side
 they tend to hide their decorations properly.

 Yes, that's what I was thinking about EWMH, there is already monocle
 mode to set full screen on the user's end, by not maximizing windows
 when sending hint to the window it allows users to play with
 monocle/floating/tiles mode.

 I spend some time on the fullscreen issues and came up with a version
 that works for all cases I tested so far. It is committed into hg tip.
 It is a simplification of Kris' patch (basically I got rid of
 superflous checks that don't seem to be necessary), but with a more
 complicated clientmessage(). I also extended Client a bit to keep
 state and changed resize(). The changes I did are backwards compliant
 for any layout algorithms however.

 Please test hg tip and let me know any issues.


Do you remember the mplayer scaling issue that we talked about on IRC?
The issue is still here even in hg tip.

Cheers.

-- 
Demelier David

Re: [dev] Fullscreen troubles.

[David DEMELIER]

No it's not a SDL problem because some are not SDL based apps, and it
does this problem only with dwm.

Best regards.

2010/3/9 Jakub Lach jakub_l...@mailplus.pl:
 Hi,

 I use dwm for longtime now, it's the only one tiling wm which does
 everything by almost default. Like manage fixed sixe windows (zsnes,
 games,..) perfectly and has a full xinerama support whereas ratpoison
 does not have free layout or the possibility to manage free windows,
 same for i3, it does not support everything well.

 I was used to mplayer for watching some videos, and fullscreen mode
 works pretty well. But the last time I wanted to start zsnes,
 foobillard as fullscreen it just does not anything. Your screen is
 resized and you can see the bar with the window getting mangled.

 Try that with zsnes, foobillard and maybe wesnoth ? (not tested the
 last).



 It's apparently SDL problem which I reported earlier.

 http://forums.libsdl.org/viewtopic.php?t=6013

 Still no reply form SDL devs.

 best regards,
 -Jakub Lach