Re: [dev] [edit] Introducing edit, a simple text editor
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
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
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
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
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
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
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
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
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
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
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 //?
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
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
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
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
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
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
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
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
> 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
> 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
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
Re: [dev] [dwm] switch tag with mouse wheel on root
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.
[dev] [dwm] switch tag with mouse wheel on root
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] Windows size changes
2010/11/13 Antoni Grzymala : > David DEMELIER dixit (2010-11-13, 09:34): > >> Thanks, but it seems this workaround only works for i386 while i'm on >> amd64... What a pity > > The canonical workaround these days is: > > wmname LG3D > > where wmname is available from: http://code.suckless.org/hg/wmname, > and it does indeed seems to fix the problem. > > Regards, > > -- > [a] > > Mmm I don't like this workaround much but it works, thanks. Cheers, -- Demelier David
Re: [dev] [dwm] Windows size changes
2010/11/12 pmarin : > AWT_TOOLKIT = MToolkit. > Sorry. > > On Fri, Nov 12, 2010 at 11:16 PM, pmarin wrote: >> On Fri, Nov 12, 2010 at 7:58 PM, David DEMELIER >> 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
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
2010/8/8 Kris Maglione : > 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
2010/7/27 Anselm R Garbe : > Hi David, > > On 26 July 2010 22:32, David DEMELIER 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
2010/7/27 Rob : > On 26 July 2010 22:32, David DEMELIER 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
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
2010/6/4 Anselm R Garbe : > 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
2010/5/30 Anselm R Garbe : > On 29 May 2010 22:18, Sylvain Laurent wrote: >> 2010/5/29 Kris Maglione : >>> On Sat, May 29, 2010 at 07:59:39PM +0100, Anselm R Garbe wrote: On 29 May 2010 19:17, Anselm R Garbe wrote: > > On 29 May 2010 18:18, Kris Maglione 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.
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 : >> 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 > > >
[dev] Fullscreen troubles.
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).