Re: tinycore - Used to be [dev] I'm back
On Tue, Oct 22, 2013 at 3:23 AM, Jens Staal wrote: > On Monday 21 October 2013 14:43:16 Carlos Torres wrote: >> so then...on a separate topic is stali meant to be a distro that sucks >> at being extensible? >> or is it meant to be a distro thats simple, lean and yet extensible. > > If I understood it correctly it would have an "/emul" directory or similar for > legacy dynamically linked apps (most likely a (s)chroot of a regular distro > like Arch or Gentoo). > ok, in that case, suppose suckless rolls its own stali version of tinycore, and replaces the part of the init scripts that deal with loading tcz's and mounting them through loopback. and not using tce.installed scripts et.al. then maybe tinycore would be good. but there are other distros that already do not use that are are small too.
Re: tinycore - Used to be [dev] I'm back
On Monday 21 October 2013 14:43:16 Carlos Torres wrote: > On Mon, Oct 21, 2013 at 1:15 PM, hiro <23h...@gmail.com> wrote: > > Yeah, tinycore's biggest failure is that it's too difficult to find > > the right man pages of certain packages. > > I knew tinycore wouldn't have docs included, they say so in the website, > heck when i create a tcz for my self, i strip the docs out too (did i > mention that?) > > so then...on a separate topic is stali meant to be a distro that sucks > at being extensible? > or is it meant to be a distro thats simple, lean and yet extensible. > > maybe i'm still not "hardcore" enough... > If I understood it correctly it would have an "/emul" directory or similar for legacy dynamically linked apps (most likely a (s)chroot of a regular distro like Arch or Gentoo).
tinycore - Used to be [dev] I'm back
On Mon, Oct 21, 2013 at 1:15 PM, hiro <23h...@gmail.com> wrote: > Yeah, tinycore's biggest failure is that it's too difficult to find > the right man pages of certain packages. I knew tinycore wouldn't have docs included, they say so in the website, heck when i create a tcz for my self, i strip the docs out too (did i mention that?) so then...on a separate topic is stali meant to be a distro that sucks at being extensible? or is it meant to be a distro thats simple, lean and yet extensible. maybe i'm still not "hardcore" enough... > >> yes, i really enjoy the boot speed of tinycorelinux with the least deps for >> wifi, dwm (et. al.) , surf, acpi; but when i boot into this system its >> because i >> want to develop something, and so i always end up loading the rest of the >> world to build stuff. and i forget api's all them time, of which i end up >> using >> manuals for (which surely you've noticed everyone purposefully strips them >> out of packages (i do it too)... >> >> >
Re: [dev] I'm back
Yeah, tinycore's biggest failure is that it's too difficult to find the right man pages of certain packages. On 10/21/13, Carlos Torres wrote: > On Mon, Oct 21, 2013 at 8:41 AM, hiro <23h...@gmail.com> wrote: >> then simply don't use pure 64bit, why did you think that was a good idea? > > when i hopped on the pure 64 band wagon i "assumed" that the x86 packages > would have been rebuilt for pure 64 eventually... that was a big mistake on > my > part. > >> it's a feature (tm). works like intended. > > Yeah, its a feature i like. Maybe i'm just complaining about the lack of > packages for pure 64 :p, again i figured there was a community of pure64 > users that were contributing packages (slower but eventually - not true) > >> Just proves you have no taste. > > I tried other browsers before i went the with webkit/surf on this system, > i did most of my work with lynx, i tried opera, links2, w3m etc... none of > which anyone else was using on pure 64 :p (goes back to my initial bad > choice) > >>> I now cringe at the thought of rebuilding any suckless tool on >>> tinycorelinux for any >>> simple tweak. >> >> Granted, the everything-is-in-ram approach requires you to use special >> procedures to properly install anything. For many things that's too >> much of a trade-off. > > its a pretty big one. > >> I exploit this to make sure I don't have too many libraries installed >> so that autohell tools will build against the least amount of >> dependencies possible (without first having to find the right >> configure switches to manually turn features off). > > yes, i really enjoy the boot speed of tinycorelinux with the least deps for > wifi, dwm (et. al.) , surf, acpi; but when i boot into this system its > because i > want to develop something, and so i always end up loading the rest of the > world to build stuff. and i forget api's all them time, of which i end up > using > manuals for (which surely you've noticed everyone purposefully strips them > out of packages (i do it too)... > >
Re: [dev] I'm back
On Mon, Oct 21, 2013 at 8:41 AM, hiro <23h...@gmail.com> wrote: > then simply don't use pure 64bit, why did you think that was a good idea? when i hopped on the pure 64 band wagon i "assumed" that the x86 packages would have been rebuilt for pure 64 eventually... that was a big mistake on my part. > it's a feature (tm). works like intended. Yeah, its a feature i like. Maybe i'm just complaining about the lack of packages for pure 64 :p, again i figured there was a community of pure64 users that were contributing packages (slower but eventually - not true) > Just proves you have no taste. I tried other browsers before i went the with webkit/surf on this system, i did most of my work with lynx, i tried opera, links2, w3m etc... none of which anyone else was using on pure 64 :p (goes back to my initial bad choice) >> I now cringe at the thought of rebuilding any suckless tool on >> tinycorelinux for any >> simple tweak. > > Granted, the everything-is-in-ram approach requires you to use special > procedures to properly install anything. For many things that's too > much of a trade-off. its a pretty big one. > I exploit this to make sure I don't have too many libraries installed > so that autohell tools will build against the least amount of > dependencies possible (without first having to find the right > configure switches to manually turn features off). yes, i really enjoy the boot speed of tinycorelinux with the least deps for wifi, dwm (et. al.) , surf, acpi; but when i boot into this system its because i want to develop something, and so i always end up loading the rest of the world to build stuff. and i forget api's all them time, of which i end up using manuals for (which surely you've noticed everyone purposefully strips them out of packages (i do it too)...
Re: [dev] I'm back
On 2013-10-21 16:28, koneu wrote: > On Oct 21, 2013, at 10:41 AM, hiro <23h...@gmail.com> wrote: > > I hope it scared you away from webkit also. > > Compared to Gecko (XUL, lol!), the only other web engine as popular as > WebKit, WebKit is a blessing, especially WebCore. I think only Hubbub beats > it in speed. Speed is nowhere near as important as correctness (I have never used Hubbub, so I cannot comment on whether I think it is "correct" or not). pgpOpeQrjqTuA.pgp Description: PGP signature
Re: [dev] I'm back
On Oct 21, 2013, at 10:41 AM, hiro <23h...@gmail.com> wrote: > I hope it scared you away from webkit also. Compared to Gecko (XUL, lol!), the only other web engine as popular as WebKit, WebKit is a blessing, especially WebCore. I think only Hubbub beats it in speed. Maybe it's time surf switched to swk + Hubbub? :P -- koneu
Re: [dev] I'm back
On 10/20/13, Carlos Torres wrote: > On Tue, Aug 13, 2013 at 6:24 PM, Carlos Torres > wrote: >> Glad you changed your mind on Android core. >> Consider looking at tinycorelinux; it too is very simple. simpler than >> crux. > > hmm, after tooling around with tinycorelinux, i think its use > doesn't make sense > as a day-to-day distro. it would suit well a specific purpose or an > embeded system. > So i'm actually removing my "+" on tinycorelinux. I went for a pure > 64bit system > and that was hellish. then simply don't use pure 64bit, why did you think that was a good idea? > since there are barely any packages for it! soo it's a feature (tm). works like intended. > i had to build > webkit and its horrid dependencies from scratch... that basically > scared my away... I hope it scared you away from webkit also. > granted i completed the daunting task to the end. Just proves you have no taste. > I now cringe at the thought of rebuilding any suckless tool on > tinycorelinux for any > simple tweak. Granted, the everything-is-in-ram approach requires you to use special procedures to properly install anything. For many things that's too much of a trade-off. I exploit this to make sure I don't have too many libraries installed so that autohell tools will build against the least amount of dependencies possible (without first having to find the right configure switches to manually turn features off). You might be able to use chroot for the task, but to me that's also additional complexity. I now just use a basic tinycore install - either in a VM or just by rebooting into it - which makes these tasks seamless. It's also simple to just boot up and load a different library version without having to memorize how to specify some special library path flags for each build system out there.
Re: [dev] I'm back
On Tue, Aug 13, 2013 at 6:24 PM, Carlos Torres wrote: > Glad you changed your mind on Android core. > Consider looking at tinycorelinux; it too is very simple. simpler than crux. hmm, after tooling around with tinycorelinux, i think its use doesn't make sense as a day-to-day distro. it would suit well a specific purpose or an embeded system. So i'm actually removing my "+" on tinycorelinux. I went for a pure 64bit system and that was hellish. since there are barely any packages for it! soo i had to build webkit and its horrid dependencies from scratch... that basically scared my away... granted i completed the daunting task to the end. I now cringe at the thought of rebuilding any suckless tool on tinycorelinux for any simple tweak. --Carlos
Re: [dev] I'm back
On Tue, Aug 13, 2013 at 1:21 PM, Anselm R Garbe wrote: > Actually I gave up on the android core now and am looking at crux 3.0 > now. Glad you changed your mind on Android core. Consider looking at tinycorelinux; it too is very simple. simpler than crux. Thanks, --Carlos
Re: [dev] I'm back
On 17 November 2012 20:50, Kurt H Maier wrote: > crux linux might have some useful approaches. I don't understand the > decision to use android crap like bionic when musl has come so far so > quickly. Actually I gave up on the android core now and am looking at crux 3.0 now. I like the fact that crux stayed KISS all years along and this makes it a good candidate. musl is pretty much set btw. Best regards, Anselm
Re: [dev] I'm back
On 25 November 2012 19:30, clamiax wrote: > Why don't provide an external lib, like libdraw, which provide an > interactive bar which read/write data from/to somewhere and share it between > dwm, tabbed, dmenu, etc. etc.? An external bar would require an interface with all of the apps you listed. The purpose of draw.c is to provide some drawing routines to those apps you listed -- as they will usually draw different things, but with the same routines. This is the simplest and sanest code re-use we can achieve, but there is not much room for more re-use left. Best regards, Anselm
Re: [dev] I'm back
Why don't provide an external lib, like libdraw, which provide an interactive bar which read/write data from/to somewhere and share it between dwm, tabbed, dmenu, etc. etc.? 2012/11/25 Anselm R Garbe > On 25 November 2012 15:26, KarlOskar Rikås wrote: > > I would like the bar to stay, but I'll be fine to have the mouse support > > removed. > > As I said, the bar will stay (default), but there will be a compile > time option to not compile it in. > > Best regards, > Anselm > >
Re: [dev] I'm back
On 11/25/2012 06:22 PM, Anselm R Garbe wrote: As I said, the bar will stay (default), but there will be a compile time option to not compile it in. Best regards, Anselm Perfect! -- Barbu Paul - Gheorghe Common sense is not so common - Voltaire Visit My GitHub profile to see my open-source projects - https://github.com/paullik
Re: [dev] I'm back
On 25 November 2012 15:26, KarlOskar Rikås wrote: > I would like the bar to stay, but I'll be fine to have the mouse support > removed. As I said, the bar will stay (default), but there will be a compile time option to not compile it in. Best regards, Anselm
Re: [dev] I'm back
On 2012-11-25, at 16:39, Noah Birnel wrote: > I use dwm to manage 10-15 simultaneous RDP sessions. Since RDP eats all > keystrokes, the mouse is the only way to switch between them. No mouse = I > need a different WM. Assuming you are using rdesktop as RDP client, try option -K to allow window manager keys to work. -Truls
Re: [dev] I'm back
On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote: > -> is there anyone who uses the mouse functionality of the dwm bar > right now? Could you live without it? Yes. No. I use dwm to manage 10-15 simultaneous RDP sessions. Since RDP eats all keystrokes, the mouse is the only way to switch between them. No mouse = I need a different WM. Welcome back, and thanks for the fantastic software. noah
Re: [dev] I'm back
I would like the bar to stay, but I'll be fine to have the mouse support removed. Thanks klr
Re: [dev] I'm back
On 17 November 2012 20:50, Kurt H Maier wrote: > crux linux might have some useful approaches. I don't understand the > decision to use android crap like bionic when musl has come so far so > quickly. I think crux is one of the cleanest distros and some aspects of it are indeed a good starting point. In the meantime I decided sta.li will be a from-scratch development with musl as its base C lib. Best regards, Anselm
Re: [dev] I'm back
On Thu, Nov 22, 2012 at 10:46:15AM +0100, sta...@cs.tu-berlin.de wrote: > Either me or you misunderstood the other one. The point is, you can configure borders or not in the dwm program already - no need to make major changes to it. Sam
Re: [dev] I'm back
* Sam Watkins [2012-11-22 04:58]: > On Wed, Nov 21, 2012 at 12:45:35PM +0100, sta...@cs.tu-berlin.de wrote: > > - borders are useful means yes to borders > configuration > > border-width: 0 means no borders. > > problem solved how??? Either me or you misunderstood the other one. cheers --s_
Re: [dev] I'm back
On Wed, Nov 21, 2012 at 12:45:35PM +0100, sta...@cs.tu-berlin.de wrote: > - borders are useful configuration border-width: 0 problem solved
Re: [dev] I'm back
Borders are not drawn by dwm, the border width is a part of the window configuration dwm tells the X server to use on each window. The *only* drawing performed by dwm is the bar. Getting rid of the bar would also mean that the status string does not have to pass through dwm as it would rather be piped directly to the bar. dwm would only really need to output tag info to stdout. -Truls
Re: [dev] I'm back
- borders are useful - the information in the bar is quite useful, too. Don't mind if it is provided separately. But isn't it too much ofa hassle to interface it with dwm then? - never used mouse in the bar, and don't plan to. cheers --s_
Re: [dev] I'm back
On 121117 2053, Ruben Mikkonen wrote:
> Hi,
>
> However, why would dwm need draw{.h,c} if there were no bar? Window
> borders? They're imo somewhat useless: a) If a window is a terminal
> window, then you easily see from the cursor if it's active. b) Otherwise
> you most likely need the mouse anyway, and focus follows mouse, so you
> don't have to know wheter it's already active or not.
>
>
> Ruben
>
I disagree with window borders being useless. For example a lot of
curses based programs don't have a cursor at all. If you have two of
these open, no way of telling which one is active.
I also get easily confused with graphical programs if I don't have a
bright hilight for the currently active window. I dare guess that a lot
of people who use dwm also use keyboard with a web browser, even with a
graphical one, and they usually don't have this kind of indicator
either.
- Tuomo Hartikainen
signature.asc
Description: Digital signature
Re: [dev] I'm back
Anselm R Garbe writes: > > -> is there anyone who uses the mouse functionality of the dwm bar > right now? Could you live without it? FWIW: I've used it on occasion. But I can certainly live without it, using the keys combination it is fine. > I barely use the mouse for the dwm bar and would be in favour for > removing the bar altogether from dwm. Instead I would output the > current dwm state to stdout which could be used by a different program > like sbar for input. But I wouldn't add an interface to dwm to change I like the bar because it provides a visual reference on which part of the environment you're working on. I can see the case if the removal is required to advance the application, but I will still see it as a loss. Using sbar or dzen2 would be ok with me if that's the decision. Worst case, can it be determined at compilation time with a -D compiler switch? Just a thought. > dmenu > - I am still using version 3 because I like it better than 4. That's just my preference though. I am an avid user of dmenu in different types of environment. (wmii, metacity, openbox, etc..), I would certainly welcome improvements to it. :). Welcome back... and as always, your efforts are appreciated. -- Luis Anaya papo anaya aroba hot mail punto com "Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
Re: [dev] I'm back
Errata: I meant logind. It's really difficult to remember anything but the d in the end, as the distribution now uses everythingd... On 11/19/2012 03:53 AM, 7...@mail.com wrote: I do *TOTALLY* agree. (one could cote netcfg in addition to systemd and profiled and...) If you want the complete list, go to http://archlinux.org/news it's faster. 7heo. On 11/18/2012 09:56 AM, clamiax wrote: I do not want to get involved in one of the usual useless discussions about how much something sucks. As for me, I have never been able to install Archlinux without having to use a custom kernel, which is unacceptable for a serious linux distro. The system is often unstable, the community is rather idiotic, full of fanatic morons with dubious technical skills and anyway Arch is probably the "minimalist" linux distribution with more bugs ever. systemd, which of course sucks, is a blessing in comparison to everything else. I think we could write a book about, but I'll stop here.
Re: [dev] I'm back
I do *TOTALLY* agree. (one could cote netcfg in addition to systemd and profiled and...) If you want the complete list, go to http://archlinux.org/news it's faster. 7heo. On 11/18/2012 09:56 AM, clamiax wrote: I do not want to get involved in one of the usual useless discussions about how much something sucks. As for me, I have never been able to install Archlinux without having to use a custom kernel, which is unacceptable for a serious linux distro. The system is often unstable, the community is rather idiotic, full of fanatic morons with dubious technical skills and anyway Arch is probably the "minimalist" linux distribution with more bugs ever. systemd, which of course sucks, is a blessing in comparison to everything else. I think we could write a book about, but I'll stop here.
Re: [dev] I'm back
söndagen den 18 november 2012 07.42.52 skrev Strake: > One may use stacking bind mounts rather than symlinks. I know no > decent such fs in Linux kernel space, as aufsn and unionfs seem > cumbersome, but it ought to not be too difficult in user space, as 9p > server. This is indeed a really cool aspect of Plan9. I definitely think that a system that could get rid of stuff like a PATH variable and replace it with union mounts and private namespaces would be very nice. I have done some union mounting using FUSE but one probably would have to have a better performing system to really base the whole logic of the system on its union mount capabilities.
Re: [dev] I'm back
I rewrote stow in guile about 10 years ago when I did my gnu/hurd distro it was much more maintainable and short.. Not because of perl, but gnu. But well.. I dont think this is going to give anything good to the discussion. I use arch nowadays but im sure it will not be my next prefered distro when i have to install on a new system. Probably will move/try to voidlinux. About libdraw.. I see more sense of libdraw for swk (which is sadly abandoded) than in dwm. I dont see any need to abstract the x11 drawing access for just the few things dwm draws there. And probably in a matter of 2 years everybody will move to wayland. And then, a fork will be probably the best thing to do than trying to just separate the drawing thingy. About the bar.. I never click on it. Only my fathers do and thats because i hooked a 'visual menu' to launch apps or kill windows with right click. I would prefer to have the bar optional rather than killing it, if we support external bars we will need to design a way to communicate dwm with it and we will make it much more complex.. And we will see screenshots on the internets with people using gtk menubars and pink ponies in translucend terminal background. And that's something we don't want. About pkgsystem i wrote slpm, and im still using it on several systems (linux, bsd, osx, ios..) and it works fine for my needs. It's now in github if anyone wants to try. About musl/android... Im gonna add another stuff to the suckless todo list: defora.org. Its a 1 guy project that runs on several kernels (netbsd, linux mainly) and aims to implement the whole userland, from libc, to compiler and ui apps. Actually the libc is c-only (no fancy asm optimizations), but compiles nicely and works on several kernels.. And it can run even gtk, so i guess its quite complete. --pancake On Nov 18, 2012, at 13:45, Strake wrote: > On 18/11/2012, Bjartur Thorlacius wrote: >> GNU Stow also. > > Oh, yeah, that's what we need: more perl. >
Re: [dev] I'm back
On 2012-11-18 at 11:04:31 Kurt H Maier wrote: > On Sun, Nov 18, 2012 at 07:00:23AM +0100, Jens Staal wrote: > > For me, this is a nicer solution than for example pacman to keep > > track on which files that belong to which package (no fragile > > databases needed). I am also happy to report that dmenu/dwm works > > nicely on Sabotage (however, it seems like some of the xlibs can > > not be linked statically). > > Slackware does this without crapping up the disk: the manifest is in > the file /var/log/packages/packagename. If you need to know where a > file came from, just grep the path in that directory. I regret years spent with Gentoo. It's funny how Slackware's simple implementation outperforms portage and friends. Not even mentioning compilation times. It's funny, but not surprising. Slackware compatible packages would be really nice.
Re: [dev] I'm back
Dnia 18 listopada 2012 17:04 Kurt H Maier napisał(a): > When I discovered wayland required mesa, I cited it as the biggest > problem wayland had. Now it has other problems, but mesa still really > sucks. Not only does it depend on libudev, it has a build-time dep on > libxml2 (unsure if that is also runtime). How does it run on FreeBSD? > I know it still pulls in XML crap, but surely they're not building a > dummy udev in the linux emulation layer? http://trillian.chruetertee.ch/ports/browser/trunk/ > > I am starting to think of this as the Fragile X syndrome, which usually > > refers > > to a genetic disease causing mental retardation ( > > http://en.wikipedia.org/wiki/Fragile_X_syndrome ). I am starting to feel > > that > > Linux is having a serious case of its digital variant. > > I love this. Fragile X11 Syndrome. The only difference is it's caused > *by* mental retardation. Haha, good one.
Re: [dev] I'm back
On Sun, Nov 18, 2012 at 07:00:23AM +0100, Jens Staal wrote: > For me, this is a nicer solution than for example pacman to keep track on > which files that belong to which package (no fragile databases needed). I am > also happy to report that dmenu/dwm works nicely on Sabotage (however, it > seems like some of the xlibs can not be linked statically). Slackware does this without crapping up the disk: the manifest is in the file /var/log/packages/packagename. If you need to know where a file came from, just grep the path in that directory. > What I have noticed lately is however how much of the broken stuff that are > expected to build also relatively fundamental technologies. For example, mesa > (which is needed if one ever wants to run wayland instead of X) expects > libudev to build, and if the version requirements will increase further that > will basically force systemd on peopole. When I discovered wayland required mesa, I cited it as the biggest problem wayland had. Now it has other problems, but mesa still really sucks. Not only does it depend on libudev, it has a build-time dep on libxml2 (unsure if that is also runtime). How does it run on FreeBSD? I know it still pulls in XML crap, but surely they're not building a dummy udev in the linux emulation layer? > I am starting to think of this as the Fragile X syndrome, which usually > refers > to a genetic disease causing mental retardation ( > http://en.wikipedia.org/wiki/Fragile_X_syndrome ). I am starting to feel that > Linux is having a serious case of its digital variant. I love this. Fragile X11 Syndrome. The only difference is it's caused *by* mental retardation.
Re: [dev] I'm back
On 18/11/2012, Bjartur Thorlacius wrote: > GNU Stow also. Oh, yeah, that's what we need: more perl.
Re: [dev] I'm back
Jens Staal wrote: > I agree with this. As an example distribution, Sabotage does things pretty > well. One detail that I like a lot (but it sort of depends on your stance on > symlinks) is the way applications usually are placed in it: > Each application gets its own directory under /opt and then installed files > get symlinks in / (the file system hierarchy is stali-inspired with > everything in root and usr just pointing back to root). > > For me, this is a nicer solution than for example pacman to keep track on > which files that belong to which package (no fragile databases needed). One may use stacking bind mounts rather than symlinks. I know no decent such fs in Linux kernel space, as aufsn and unionfs seem cumbersome, but it ought to not be too difficult in user space, as 9p server. > What I have noticed lately is however how much of the broken stuff that are > expected to build also relatively fundamental technologies. For example, mesa > (which is needed if one ever wants to run wayland instead of X) expects > libudev to build, and if the version requirements will increase further that > will basically force systemd on peopole. Free software, captive society. > I am starting to think of this as the Fragile X syndrome, which usually refers > to a genetic disease causing mental retardation > (http://en.wikipedia.org/wiki/Fragile_X_syndrome ). > I am starting to feel that Linux is having a serious case of its digital > variant. Ha! Nice. Anselm Garbe wrote: > I'm back in the game ;) Welcome back! It's your move.
Re: [dev] I'm back
On Sun, Nov 18, 2012 at 11:10 AM, Felix Janda wrote: > On 11/18/12 at 07:00am, Jens Staal wrote: >> Each application gets its own directory under /opt and then installed files >> get symlinks in / (the file system hierarchy is stali-inspired with >> everything >> in root and usr just pointing back to root). >> >> [snip] > > djb had a similar idea with his slashpackage system. It doesn't seem to have > caught on much, tough. > GNU Stow also.
Re: [dev] I'm back
On 11/18/12 at 07:00am, Jens Staal wrote: > I agree with this. As an example distribution, Sabotage does things pretty > well. One detail that I like a lot (but it sort of depends on your stance on > symlinks) is the way applications usually are placed in it: > > Each application gets its own directory under /opt and then installed files > get symlinks in / (the file system hierarchy is stali-inspired with > everything > in root and usr just pointing back to root). > > For me, this is a nicer solution than for example pacman to keep track on > which files that belong to which package (no fragile databases needed). I am > also happy to report that dmenu/dwm works nicely on Sabotage (however, it > seems like some of the xlibs can not be linked statically). djb had a similar idea with his slashpackage system. It doesn't seem to have caught on much, tough. > What I have noticed lately is however how much of the broken stuff that are > expected to build also relatively fundamental technologies. For example, mesa > (which is needed if one ever wants to run wayland instead of X) expects > libudev to build, and if the version requirements will increase further that > will basically force systemd on peopole. There are at least two forks of udev making it again standalone. (They are very likely going to be merged.) https://bitbucket.org/braindamaged/udev https://github.com/gentoo/udev-ng If enough people have interested in having systemd free systems it will be possible. Altough it might get more and more difficult when more programs start using systemd's services.
Re: [dev] I'm back
On 18 November 2012 07:00, Jens Staal wrote: > lördagen den 17 november 2012 14.50.23 skrev Kurt H Maier: >> On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote: >> > sta.li >> > -- >> > To me archlinux was a good distro until a couple of years ago. >> > Nowadays it seems to be very en vogue and thus has degraded quite >> > significantly in terms of simplicity. I'm not aware of any distro that >> > would come close to the radical goals of stali, thus this is the real >> > effort suckless.org must work on. I believe that the Android core as >> > a base system is the best platform to base sta.li on. >> >> crux linux might have some useful approaches. I don't understand the >> decision to use android crap like bionic when musl has come so far so >> quickly. > > I agree with this. As an example distribution, Sabotage does things pretty > well. One detail that I like a lot (but it sort of depends on your stance on > symlinks) is the way applications usually are placed in it: I'm suggesting the Android core as this the environment I'm quite familiar with. I'll investigate if linux+musl would be a better fit, as I'm not totally tight to the Android core. But judging from the fact that Android is already on >500 million devices I would say that its core is quite well tested. And obviously it comes without the systemd dependency. > Each application gets its own directory under /opt and then installed files > get symlinks in / (the file system hierarchy is stali-inspired with everything > in root and usr just pointing back to root). I'll talk to Christian at the next Stammtisch to refresh my knowledge about sabotage ;) Best regards, Anselm
Re: [dev] I'm back
I do not want to get involved in one of the usual useless discussions about
how much something sucks. As for me, I have never been able to install
Archlinux without having to use a custom kernel, which is unacceptable for
a serious linux distro. The system is often unstable, the community is
rather idiotic, full of fanatic morons with dubious technical skills and
anyway Arch is probably the "minimalist" linux distribution with more bugs
ever. systemd, which of course sucks, is a blessing in comparison to
everything else. I think we could write a book about, but I'll stop here.
2012/11/17 Newton Smartt
> What's wrong with Arch?
>
>
> On Sat, Nov 17, 2012 at 1:11 PM, clamiax wrote:
>
>> 2012/11/17 Anselm R Garbe
>>
>>> Hi there,
>>>
>> Hi.
>>
>>
>>> I'm back in the game ;)
>>>
>> Welcome back!
>>
>>
>>> (i) First I plan a new dwm release with the introduction of draw{.h,c}
>>> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
>>> the dwm implementation and to define a clean draw.h interface to be
>>> used instead. This should also be incorporated into dmenu and st.
>>
>> This sound like a logical step we had to do first or later. At least,
>> until we have something to draw.
>>
>>
>>> a) requiring an additional library dependency at build time (I'm not
>>> the biggest proponent for this idea)
>>>
>> If we aspire the perfection this shouldn't even be considered.
>>
>>
>>> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
>>> implementation is the master
>>
>> Maybe. Does this also mean that we could end up to have some piece of
>> code used in some program but unused in other, for the sake of sharing the
>> same implementation?
>>
>>
>>> (ii) Another aspect on the dwm roadmap is a reimplementation of the
>>> current multi-screen handling. It still contains some weird bugs in
>>> special setups with same screen sizes. Those don't seem to be easily
>>> fixable with the current updategeom() handling.
>>>
>> I don't need multi-screen handling at all. No, I'm not proposing to
>> remove it. It would be too nice...
>>
>>
>>> (iii) A third idea is an old idea that 20h brought into the discussion
>>> when investigating 2wm. The man page of 2wm mentions sbar, which was
>>> abandoned a couple of years ago. My question here is:
>>
>>
>>> -> is there anyone who uses the mouse functionality of the dwm bar
>>> right now? Could you live without it?
>>>
>> No. Yes.
>>
>>
>>> I barely use the mouse for the dwm bar and would be in favour for
>>> removing the bar altogether from dwm. Instead I would output the
>>> current dwm state to stdout which could be used by a different program
>>> like sbar for input. But I wouldn't add an interface to dwm to change
>>> the tags through X props or some other command interface (like stdin
>>> processing) to allow other programs to amend the dwm tags. Good old
>>> key commands would be enough for me.
>>>
>> Agreed. Though someone doesn't. I hate when people which don't think like
>> me comes with good arguments. I can safely ignore them, though. So, +1 to
>> remove the bar from dwm.
>>
>>
>>> I know that some of you are inclined to use dwm on tablets. But I'm
>>> not convinced that tablets or touch interfaces in general are a nice
>>> fit with the terminal world we live in.
>>>
>> I'm pretty sure that even those who use dwm on tablets are doing it by
>> thinking that it is not a good idea.
>>
>>
>>> dmenu needs some fixes. The removal of config.h is the wrong way it
>>> took. If someone stays with hg of dmenu or uses the releases, he has
>>> to do conflict management now with dmenu.c changes.
>>>
>> I don't use dmenu. No, I'm not proposing to abandon the project. It's so
>> geek.
>>
>>
>>> To me archlinux was a good distro until a couple of years ago.
>>>
>> To me, you are wrong. Archlinux has never been a good distro.
>>
>> Nowadays it seems to be very en vogue and thus has degraded quite
>>> significantly in terms of simplicity. I'm not aware of any distro that
>>> would come close to the radical goals of stali, thus this is the real
>>> effort suckless.org must work on. I believe that the Android core as
>>> a base system is the best platform to base sta.li on.
>>>
>> I agree to use Android core as base system but only if we schedule to
>> slowly remove it from sta.li, one piece at a time, until will not
>> remaing nothing at all.
>>
>
>
Re: [dev] I'm back
lördagen den 17 november 2012 14.50.23 skrev Kurt H Maier: > On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote: > > sta.li > > -- > > To me archlinux was a good distro until a couple of years ago. > > Nowadays it seems to be very en vogue and thus has degraded quite > > significantly in terms of simplicity. I'm not aware of any distro that > > would come close to the radical goals of stali, thus this is the real > > effort suckless.org must work on. I believe that the Android core as > > a base system is the best platform to base sta.li on. > > crux linux might have some useful approaches. I don't understand the > decision to use android crap like bionic when musl has come so far so > quickly. I agree with this. As an example distribution, Sabotage does things pretty well. One detail that I like a lot (but it sort of depends on your stance on symlinks) is the way applications usually are placed in it: Each application gets its own directory under /opt and then installed files get symlinks in / (the file system hierarchy is stali-inspired with everything in root and usr just pointing back to root). For me, this is a nicer solution than for example pacman to keep track on which files that belong to which package (no fragile databases needed). I am also happy to report that dmenu/dwm works nicely on Sabotage (however, it seems like some of the xlibs can not be linked statically). What I have noticed lately is however how much of the broken stuff that are expected to build also relatively fundamental technologies. For example, mesa (which is needed if one ever wants to run wayland instead of X) expects libudev to build, and if the version requirements will increase further that will basically force systemd on peopole. I am starting to think of this as the Fragile X syndrome, which usually refers to a genetic disease causing mental retardation ( http://en.wikipedia.org/wiki/Fragile_X_syndrome ). I am starting to feel that Linux is having a serious case of its digital variant.
Re: [dev] I'm back
On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote:
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> used instead. This should also be incorporated into dmenu and st.
>
> For this there are two options:
>
> a) requiring an additional library dependency at build time (I'm not
> the biggest proponent for this idea)
> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
> implementation is the master
>
> (ii) Another aspect on the dwm roadmap is a reimplementation of the
> current multi-screen handling. It still contains some weird bugs in
> special setups with same screen sizes. Those don't seem to be easily
> fixable with the current updategeom() handling.
>
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
>
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like sbar for input. But I wouldn't add an interface to dwm to change
> the tags through X props or some other command interface (like stdin
> processing) to allow other programs to amend the dwm tags. Good old
> key commands would be enough for me.
>
> I know that some of you are inclined to use dwm on tablets. But I'm
> not convinced that tablets or touch interfaces in general are a nice
> fit with the terminal world we live in.
Though, I have not really yet had any contributions to this community,
I'd like to share my perspective.
In recent times I have become quite extreme deconstructionist and
following ideas stem from that. And have some ideas that I consider very
interesting, but due to me being quite lazy, and having slight RSI I
haven't put any work into them yet.
First I do not think window manager should do anything more than that -
manage windows.
First of I hold that its always most flexible to read stdin and write
stdout. That way you can put commands from whatever/wherever you like. I
think this would solve all touch related issues too, just add input
handler that suits your environment(key mapper, gesture mapper, whatever
else) and use it to pass commands to dwm. Needless to say I fully
support removing the bar from dwm, and have proposed it several times,
it would also remove any dependencies on fonts, or maybe even draw.c,
though maybe it will be needed for borders.
In my opinion working environment should be build from such pieces:
window manager, key bindings manager, bar application if needed.
However reading stdin means text parsing, and that is not the most fun
thing I suppose. Maybe it could be done using some lib that allows
simple mapping of "command_name param1 param2 ..." to function(arg1,
arg2, ...)
Well thats all, I remember now.
Re: [dev] I'm back
On 11/17/12, Anselm R Garbe wrote: > Ok, I've heard enough. > > The built-in bar stays as is, but I will organize its code in a way, > that dwm can be compiled without the bar. > > Best regards, > -Anselm > > sounds like a very useful thing, I can betatest if you like.
Re: [dev] I'm back
I use the mouse quite a bit to switch tags when working with virtual machines and RDP sessions that fill my screen, less the bar. Bringing mouse support in via patch wouldn't be a big deal.
Re: [dev] I'm back
> I know that some of you are inclined to use dwm on tablets. But I'm > not convinced that tablets or touch interfaces in general are a nice > fit with the terminal world we live in. tablets are used to read pdfs, and tablets do not have keyboards. however, while i didn't quite parse your whole proposal, if you simply let us tablet users manipulate dwm via xdotool, i can work around the elimination of the bar, e.g., mapping gestures to xdotool calls to dwm twitches. all the best welcome back, peter -- sic dicit magister P Université du Québec à Montréal / Loyola University Chicago http://individual.utoronto.ca/peterjh gpg 1024D/ED6EF59B (7D1A 522F D08E 30F6 FA42 B269 B860 352B ED6E F59B) gpg --keyserver pgp.mit.edu --recv-keys ED6EF59B
Re: [dev] I'm back
On Sat, Nov 17, 2012 at 06:20:03PM +0100, Anselm R Garbe wrote: > > sta.li > -- > To me archlinux was a good distro until a couple of years ago. > Nowadays it seems to be very en vogue and thus has degraded quite > significantly in terms of simplicity. I'm not aware of any distro that > would come close to the radical goals of stali, thus this is the real > effort suckless.org must work on. I believe that the Android core as > a base system is the best platform to base sta.li on. > crux linux might have some useful approaches. I don't understand the decision to use android crap like bionic when musl has come so far so quickly.
Re: [dev] I'm back
Greetings. On Sat, 17 Nov 2012 20:26:09 +0100 Manolo Martínez wrote: > On 11/17/12 at 01:15pm, Newton Smartt wrote: > > What's wrong with Arch? > > systemd is probably frowned upon around here. People proposing systemd are likely pedophiles or terrorists. The only difference to tor users is that systemd proposers hate disabled people. Sincerely, Christoph Lohmann
Re: [dev] I'm back
For whatever it's worth (which is not much since I don't contribute much of anything to this community anyway), I hardly touch the mouse and wouldn't even notice if mouse functionality was removed from the bar. I do like having the bar managed by DWM though. The fewer external programs I have to bring in to remain functional the better. On Sat, Nov 17, 2012 at 11:42 AM, Nick wrote: > Quoth Anselm R Garbe: > > -> is there anyone who uses the mouse functionality of the dwm bar > > right now? Could you live without it? > > I do use it sometimes, but could live without it. No strong > preferences. > > > I barely use the mouse for the dwm bar and would be in favour for > > removing the bar altogether from dwm. Instead I would output the > > current dwm state to stdout which could be used by a different program > > like sbar for input. > > Really? I like that the bar is managed by dwm, 'cos I trust dwm, and > it seems like a reasonably OK place to do such drawing. So long as > there was a widely used, reasonable way of doing things, which ends > up looking and working like dwm currently does, I don't really mind. > > > But I wouldn't add an interface to dwm to change > > the tags through X props or some other command interface (like stdin > > processing) to allow other programs to amend the dwm tags. Good old > > key commands would be enough for me. > > Yes, good; sensible chap. > > Good to hear from you again Anselm. > > Nick > >
Re: [dev] I'm back
On 11/17/12 at 01:15pm, Newton Smartt wrote: > What's wrong with Arch? systemd is probably frowned upon around here.
Re: [dev] I'm back
What's wrong with Arch?
On Sat, Nov 17, 2012 at 1:11 PM, clamiax wrote:
> 2012/11/17 Anselm R Garbe
>
>> Hi there,
>>
> Hi.
>
>
>> I'm back in the game ;)
>>
> Welcome back!
>
>
>> (i) First I plan a new dwm release with the introduction of draw{.h,c}
>> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
>> the dwm implementation and to define a clean draw.h interface to be
>> used instead. This should also be incorporated into dmenu and st.
>
> This sound like a logical step we had to do first or later. At least,
> until we have something to draw.
>
>
>> a) requiring an additional library dependency at build time (I'm not
>> the biggest proponent for this idea)
>>
> If we aspire the perfection this shouldn't even be considered.
>
>
>> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
>> implementation is the master
>
> Maybe. Does this also mean that we could end up to have some piece of code
> used in some program but unused in other, for the sake of sharing the same
> implementation?
>
>
>> (ii) Another aspect on the dwm roadmap is a reimplementation of the
>> current multi-screen handling. It still contains some weird bugs in
>> special setups with same screen sizes. Those don't seem to be easily
>> fixable with the current updategeom() handling.
>>
> I don't need multi-screen handling at all. No, I'm not proposing to remove
> it. It would be too nice...
>
>
>> (iii) A third idea is an old idea that 20h brought into the discussion
>> when investigating 2wm. The man page of 2wm mentions sbar, which was
>> abandoned a couple of years ago. My question here is:
>
>
>> -> is there anyone who uses the mouse functionality of the dwm bar
>> right now? Could you live without it?
>>
> No. Yes.
>
>
>> I barely use the mouse for the dwm bar and would be in favour for
>> removing the bar altogether from dwm. Instead I would output the
>> current dwm state to stdout which could be used by a different program
>> like sbar for input. But I wouldn't add an interface to dwm to change
>> the tags through X props or some other command interface (like stdin
>> processing) to allow other programs to amend the dwm tags. Good old
>> key commands would be enough for me.
>>
> Agreed. Though someone doesn't. I hate when people which don't think like
> me comes with good arguments. I can safely ignore them, though. So, +1 to
> remove the bar from dwm.
>
>
>> I know that some of you are inclined to use dwm on tablets. But I'm
>> not convinced that tablets or touch interfaces in general are a nice
>> fit with the terminal world we live in.
>>
> I'm pretty sure that even those who use dwm on tablets are doing it by
> thinking that it is not a good idea.
>
>
>> dmenu needs some fixes. The removal of config.h is the wrong way it
>> took. If someone stays with hg of dmenu or uses the releases, he has
>> to do conflict management now with dmenu.c changes.
>>
> I don't use dmenu. No, I'm not proposing to abandon the project. It's so
> geek.
>
>
>> To me archlinux was a good distro until a couple of years ago.
>>
> To me, you are wrong. Archlinux has never been a good distro.
>
> Nowadays it seems to be very en vogue and thus has degraded quite
>> significantly in terms of simplicity. I'm not aware of any distro that
>> would come close to the radical goals of stali, thus this is the real
>> effort suckless.org must work on. I believe that the Android core as
>> a base system is the best platform to base sta.li on.
>>
> I agree to use Android core as base system but only if we schedule to
> slowly remove it from sta.li, one piece at a time, until will not remaing
> nothing at all.
>
Re: [dev] I'm back
2012/11/17 Anselm R Garbe
> Hi there,
>
Hi.
> I'm back in the game ;)
>
Welcome back!
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> used instead. This should also be incorporated into dmenu and st.
This sound like a logical step we had to do first or later. At least, until
we have something to draw.
> a) requiring an additional library dependency at build time (I'm not
> the biggest proponent for this idea)
>
If we aspire the perfection this shouldn't even be considered.
> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
> implementation is the master
Maybe. Does this also mean that we could end up to have some piece of code
used in some program but unused in other, for the sake of sharing the same
implementation?
> (ii) Another aspect on the dwm roadmap is a reimplementation of the
> current multi-screen handling. It still contains some weird bugs in
> special setups with same screen sizes. Those don't seem to be easily
> fixable with the current updategeom() handling.
>
I don't need multi-screen handling at all. No, I'm not proposing to remove
it. It would be too nice...
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
>
No. Yes.
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like sbar for input. But I wouldn't add an interface to dwm to change
> the tags through X props or some other command interface (like stdin
> processing) to allow other programs to amend the dwm tags. Good old
> key commands would be enough for me.
>
Agreed. Though someone doesn't. I hate when people which don't think like
me comes with good arguments. I can safely ignore them, though. So, +1 to
remove the bar from dwm.
> I know that some of you are inclined to use dwm on tablets. But I'm
> not convinced that tablets or touch interfaces in general are a nice
> fit with the terminal world we live in.
>
I'm pretty sure that even those who use dwm on tablets are doing it by
thinking that it is not a good idea.
> dmenu needs some fixes. The removal of config.h is the wrong way it
> took. If someone stays with hg of dmenu or uses the releases, he has
> to do conflict management now with dmenu.c changes.
>
I don't use dmenu. No, I'm not proposing to abandon the project. It's so
geek.
> To me archlinux was a good distro until a couple of years ago.
>
To me, you are wrong. Archlinux has never been a good distro.
Nowadays it seems to be very en vogue and thus has degraded quite
> significantly in terms of simplicity. I'm not aware of any distro that
> would come close to the radical goals of stali, thus this is the real
> effort suckless.org must work on. I believe that the Android core as
> a base system is the best platform to base sta.li on.
>
I agree to use Android core as base system but only if we schedule to
slowly remove it from sta.li, one piece at a time, until will not remaing
nothing at all.
Re: [dev] I'm back
Ok, I've heard enough. The built-in bar stays as is, but I will organize its code in a way, that dwm can be compiled without the bar. Best regards, -Anselm
Re: [dev] I'm back
On Sat, Nov 17, 2012 at 1:29 PM, Manolo Martínez wrote: > If this is something like a poll, I concur: no mouse, yes bar. This is also my feeling. I never use the mouse on the bar, but unless sbar will be able to display those handy little boxes over the tags, I'd rather keep what dwm has currently. I can't wait for the libdraw addition, so that I can keep dwm at tip without using Xft, which causes me endless headaches. I also look forward to its use in st... --Andrew Hills
Re: [dev] I'm back
Anselm R Garbe wrote: > (iii) A third idea is an old idea that 20h brought into the discussion > when investigating 2wm. The man page of 2wm mentions sbar, which was > abandoned a couple of years ago. My question here is: > > -> is there anyone who uses the mouse functionality of the dwm bar > right now? Could you live without it? For what it's worth, I use it often (with a touchpad), and would need an equivalent replacement if you'll decide to remove it.
Re: [dev] I'm back
Hi,
On Sat, 17 Nov 2012, Anselm R Garbe wrote:
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
>
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like sbar for input. But I wouldn't add an interface to dwm to change
> the tags through X props or some other command interface (like stdin
> processing) to allow other programs to amend the dwm tags. Good old
> key commands would be enough for me.
I think removing the hardcoded bar from dwm is quite a good idea. I've
never found any real use of it.
However, why would dwm need draw{.h,c} if there were no bar? Window
borders? They're imo somewhat useless: a) If a window is a terminal
window, then you easily see from the cursor if it's active. b) Otherwise
you most likely need the mouse anyway, and focus follows mouse, so you
don't have to know wheter it's already active or not.
Ruben
Re: [dev] I'm back
you know what, i take beck what i said about a couple of things: 1) while separating out common drawing functionality in to a librady is appealing. i don't think all suckless apps should be depending on an external source. they're all independent right now. and i've only incrementally started using them. but i like that they're separate. 2) i like the bar for more than just the tags display i also like the status and window title sections in fact surf displays a lot more usefull info now with the webkit toggles in the title (i could tabbed surf though) i like the bar --Carlos On Sat, Nov 17, 2012 at 1:29 PM, Manolo Martínez wrote: > On 11/17/12 at 01:57pm, Jamie Bragg wrote: >> I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I >> would kind of miss the dwm bar if it went away, simply because I'd have to >> find another solution. >> > If this is something like a poll, I concur: no mouse, yes bar. > > M >
Re: [dev] I'm back
On 11/17/12 at 01:57pm, Jamie Bragg wrote: > I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I > would kind of miss the dwm bar if it went away, simply because I'd have to > find another solution. > If this is something like a poll, I concur: no mouse, yes bar. M
Re: [dev] I'm back
Hi, * Anselm R Garbe [2012-11-17 18:22]: > I'm back in the game ;) wb :) [...] > I barely use the mouse for the dwm bar and would be in favour for > removing the bar altogether from dwm. Instead I would output the > current dwm state to stdout which could be used by a different program > like sbar for input. But I wouldn't add an interface to dwm to change > the tags through X props or some other command interface (like stdin > processing) to allow other programs to amend the dwm tags. Good old > key commands would be enough for me. FWIW: don't need it either, I consider it rather useless. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0
Re: [dev] I'm back
On 17 November 2012 18:58, Christoph Lohmann <2...@r-36.net> wrote:
> On Sat, 17 Nov 2012 18:58:22 +0100 Anselm R Garbe wrote:
> I’m all for draw.{h,c}. Otherwise the complexity of dependency handling
> will need to be added to all of the packages using libdraw. There might
> be a tendency of differences in the implementation, but that’s easy to
> solve, if the draw.{h,c} stays simple. That’s simpler than having the
> hassle to download some more packages, install them at the right place
> and go on with building.
Yes, that's my preference as well.
>> (ii) Another aspect on the dwm roadmap is a reimplementation of the
>> current multi-screen handling. It still contains some weird bugs in
>> special setups with same screen sizes. Those don't seem to be easily
>> fixable with the current updategeom() handling.
>
> But please keep the same behaviour as dwm has now. Reducing this to this
> idea of only starting applications on one screen is not userfriendly and
> creates more hassle than the »weird bugs« create. Most of these bugs are
> just there because of weird applications using weird modes in weird cas‐
> es of weird bloated complexity. I’m rather for adapting the applications
> having the problems.
The changes I plan involves a different behaviour when screens are
added/removed/resized while dwm is running.
>> -> is there anyone who uses the mouse functionality of the dwm bar
>> right now? Could you live without it?
>
> No, I am the leader of the suckless touch project and removing this will
> require me to fork dwm, which only creates problems. The statusbar works
> as it is and we already discussed what bloat some interface for a sta‐
> tusbar would add.
What is the purpose of the suckless touch project? Who is using this?
Are you using onscreen keyboards to hack commands into your terminal?
> Some good nice touch features will be added here, when multitouch is
> common and usable in X11. Then the statusbar can serve as the path to
> suckless touching.
To me this touching stuff s not really the typical suckless focus group imho.
>> I barely use the mouse for the dwm bar and would be in favour for
>> removing the bar altogether from dwm. Instead I would output the
>> current dwm state to stdout which could be used by a different program
>> like sbar for input. But I wouldn't add an interface to dwm to change
>> the tags through X props or some other command interface (like stdin
>> processing) to allow other programs to amend the dwm tags. Good old
>> key commands would be enough for me.
>
> This is replacing a worker with a disabled person.
It would simplify dwm quite significantly.
> What’s »Android« in the »Android core«? The Linux kernel running some
That's just the kernel + bionic and some userland. No dalvik and the folks.
Best regards,
Anselm
Re: [dev] I'm back
Good to hear you're back
On Sat, Nov 17, 2012 at 12:20 PM, Anselm R Garbe wrote:
>
> Hi there,
>
> I'm back in the game ;)
>
> Here is my master plan:
>
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> used instead. This should also be incorporated into dmenu and st.
>
> For this there are two options:
>
> a) requiring an additional library dependency at build time (I'm not
> the biggest proponent for this idea)
> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
> implementation is the master
there is the Forrest and the Deps Extension, but i think i prefer the
library dep.
is libutf going to be part of this effor too?
>
> (ii) Another aspect on the dwm roadmap is a reimplementation of the
> current multi-screen handling. It still contains some weird bugs in
> special setups with same screen sizes. Those don't seem to be easily
> fixable with the current updategeom() handling.
>
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
I've been removing all mouse actions except the status click for a teminal
ever since i started using dwm, i found the mouse actions mostly fluff
>
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like sbar for input. But I wouldn't add an interface to dwm to change
> the tags through X props or some other command interface (like stdin
> processing) to allow other programs to amend the dwm tags. Good old
> key commands would be enough for me.
I do rely on the visibility of the tags, just to see what else i have
lingering
that i might need to manage, though replacing that with sbar is fine with me.
as long as i don't have to patch dwm to offset the geometry for sbar.
i.e. a config.h parameter for that offset would do.
or better yet sbar should be like dmenu and all would be neat :)
(note i don't know sbar)
>
> I know that some of you are inclined to use dwm on tablets. But I'm
> not convinced that tablets or touch interfaces in general are a nice
> fit with the terminal world we live in.
>
> dmenu
> -
> dmenu needs some fixes. The removal of config.h is the wrong way it
> took. If someone stays with hg of dmenu or uses the releases, he has
> to do conflict management now with dmenu.c changes.
xft in dmenu would be nice. when dwm switched to dmenu i stopped passing
all args to dmenu in dwms config. and started managing dmenu.c for
prefered values.
heck if dwm, st, dmenu, tabbed, etc start using ??libdraw?? then all pretty
color stuff has found a home
>
> sta.li
> --
> To me archlinux was a good distro until a couple of years ago.
> Nowadays it seems to be very en vogue and thus has degraded quite
> significantly in terms of simplicity. I'm not aware of any distro that
> would come close to the radical goals of stali, thus this is the real
> effort suckless.org must work on. I believe that the Android core as
> a base system is the best platform to base sta.li on.
>
> Best regards,
> Anselm
>
Re: [dev] I'm back
Hi,
The mouse functionnality in dwm bar could become a patch, no more
mainline. I don't use it often, but when I do it's to launch a 9menu.
I concur with Nick about the bar, I need it and I trust the dwm one.
It's good to hear from you
Xavier
Le 18:20:03 le 17 nov. 2012 , Anselm R Garbe a écrit :
> Hi there,
>
> I'm back in the game ;)
>
> Here is my master plan:
>
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> used instead. This should also be incorporated into dmenu and st.
>
> For this there are two options:
>
> a) requiring an additional library dependency at build time (I'm not
> the biggest proponent for this idea)
> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
> implementation is the master
>
> (ii) Another aspect on the dwm roadmap is a reimplementation of the
> current multi-screen handling. It still contains some weird bugs in
> special setups with same screen sizes. Those don't seem to be easily
> fixable with the current updategeom() handling.
>
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
>
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like sbar for input. But I wouldn't add an interface to dwm to change
> the tags through X props or some other command interface (like stdin
> processing) to allow other programs to amend the dwm tags. Good old
> key commands would be enough for me.
>
> I know that some of you are inclined to use dwm on tablets. But I'm
> not convinced that tablets or touch interfaces in general are a nice
> fit with the terminal world we live in.
>
> dmenu
> -
> dmenu needs some fixes. The removal of config.h is the wrong way it
> took. If someone stays with hg of dmenu or uses the releases, he has
> to do conflict management now with dmenu.c changes.
>
> sta.li
> --
> To me archlinux was a good distro until a couple of years ago.
> Nowadays it seems to be very en vogue and thus has degraded quite
> significantly in terms of simplicity. I'm not aware of any distro that
> would come close to the radical goals of stali, thus this is the real
> effort suckless.org must work on. I believe that the Android core as
> a base system is the best platform to base sta.li on.
>
> Best regards,
> Anselm
>
--
,--. Xavier Cartron , /(
: /` ) M2 MEFPCo **}=\\,\(,,
| `-' Debian user<0--(___(_\\
\_ jabber : thu...@jabber.fr / >,) ,/ ``==>
Re: [dev] I'm back
Greetings.
On Sat, 17 Nov 2012 18:58:22 +0100 Anselm R Garbe wrote:
> dwm
> ---
> (i) First I plan a new dwm release with the introduction of draw{.h,c}
> or libdraw. The idea is to abstract all the PCF/Xft cruft away from
> the dwm implementation and to define a clean draw.h interface to be
> used instead. This should also be incorporated into dmenu and st.
> For this there are two options:
>
> a) requiring an additional library dependency at build time (I'm not
> the biggest proponent for this idea)
> b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
> implementation is the master
I’m all for draw.{h,c}. Otherwise the complexity of dependency handling
will need to be added to all of the packages using libdraw. There might
be a tendency of differences in the implementation, but that’s easy to
solve, if the draw.{h,c} stays simple. That’s simpler than having the
hassle to download some more packages, install them at the right place
and go on with building.
Even when sta.li is releases should this be the right approach. With all
source included builds on cygwin or whatever will be next in the future
will be more easier than depending on some package manager.
> (ii) Another aspect on the dwm roadmap is a reimplementation of the
> current multi-screen handling. It still contains some weird bugs in
> special setups with same screen sizes. Those don't seem to be easily
> fixable with the current updategeom() handling.
But please keep the same behaviour as dwm has now. Reducing this to this
idea of only starting applications on one screen is not userfriendly and
creates more hassle than the »weird bugs« create. Most of these bugs are
just there because of weird applications using weird modes in weird cas‐
es of weird bloated complexity. I’m rather for adapting the applications
having the problems.
> (iii) A third idea is an old idea that 20h brought into the discussion
> when investigating 2wm. The man page of 2wm mentions sbar, which was
> abandoned a couple of years ago. My question here is:
>
> -> is there anyone who uses the mouse functionality of the dwm bar
> right now? Could you live without it?
No, I am the leader of the suckless touch project and removing this will
require me to fork dwm, which only creates problems. The statusbar works
as it is and we already discussed what bloat some interface for a sta‐
tusbar would add.
Some good nice touch features will be added here, when multitouch is
common and usable in X11. Then the statusbar can serve as the path to
suckless touching.
> I barely use the mouse for the dwm bar and would be in favour for
> removing the bar altogether from dwm. Instead I would output the
> current dwm state to stdout which could be used by a different program
> like sbar for input. But I wouldn't add an interface to dwm to change
> the tags through X props or some other command interface (like stdin
> processing) to allow other programs to amend the dwm tags. Good old
> key commands would be enough for me.
This is replacing a worker with a disabled person.
> I know that some of you are inclined to use dwm on tablets. But I'm
> not convinced that tablets or touch interfaces in general are a nice
> fit with the terminal world we live in.
It does, but you are proposing the Android core(wtf?) below.
> sta.li
> --
> To me archlinux was a good distro until a couple of years ago.
> Nowadays it seems to be very en vogue and thus has degraded quite
> significantly in terms of simplicity. I'm not aware of any distro that
> would come close to the radical goals of stali, thus this is the real
> effort suckless.org must work on. I believe that the Android core as
> a base system is the best platform to base sta.li on.
What’s »Android« in the »Android core«? The Linux kernel running some
kind of scripts and sometimes hardcoded scripts for specific mobile
phones. Android is now only usable with the dalvik complexity layer for
end user annoyance. No, this can be done more easier, by following the
path of most musl‐based static distributions around. A more complex
problem will be to find a sane compiler that isn’t using C++.
Sincerely,
Christoph Lohmann
Re: [dev] I'm back
On 17 November 2012 18:57, Jamie Bragg wrote: > I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I > would kind of miss the dwm bar if it went away, simply because I'd have to > find another solution. To be clear, of course I would implement sbar instead which could be used to visualize the dwm output in a similar way like what the build-in bar is doing right now, including support for status text. Best regards, Anselm
Re: [dev] I'm back
I rarely use the mouse functionality of the dwm bar and wouldn't miss it. I would kind of miss the dwm bar if it went away, simply because I'd have to find another solution. Jamie On 17 Nov 2012 13:42, "Nick" wrote: > Quoth Anselm R Garbe: > > -> is there anyone who uses the mouse functionality of the dwm bar > > right now? Could you live without it? > > I do use it sometimes, but could live without it. No strong > preferences. > > > I barely use the mouse for the dwm bar and would be in favour for > > removing the bar altogether from dwm. Instead I would output the > > current dwm state to stdout which could be used by a different program > > like sbar for input. > > Really? I like that the bar is managed by dwm, 'cos I trust dwm, and > it seems like a reasonably OK place to do such drawing. So long as > there was a widely used, reasonable way of doing things, which ends > up looking and working like dwm currently does, I don't really mind. > > > But I wouldn't add an interface to dwm to change > > the tags through X props or some other command interface (like stdin > > processing) to allow other programs to amend the dwm tags. Good old > > key commands would be enough for me. > > Yes, good; sensible chap. > > Good to hear from you again Anselm. > > Nick > >
Re: [dev] I'm back
Quoth Anselm R Garbe: > -> is there anyone who uses the mouse functionality of the dwm bar > right now? Could you live without it? I do use it sometimes, but could live without it. No strong preferences. > I barely use the mouse for the dwm bar and would be in favour for > removing the bar altogether from dwm. Instead I would output the > current dwm state to stdout which could be used by a different program > like sbar for input. Really? I like that the bar is managed by dwm, 'cos I trust dwm, and it seems like a reasonably OK place to do such drawing. So long as there was a widely used, reasonable way of doing things, which ends up looking and working like dwm currently does, I don't really mind. > But I wouldn't add an interface to dwm to change > the tags through X props or some other command interface (like stdin > processing) to allow other programs to amend the dwm tags. Good old > key commands would be enough for me. Yes, good; sensible chap. Good to hear from you again Anselm. Nick
[dev] I'm back
Hi there,
I'm back in the game ;)
Here is my master plan:
dwm
---
(i) First I plan a new dwm release with the introduction of draw{.h,c}
or libdraw. The idea is to abstract all the PCF/Xft cruft away from
the dwm implementation and to define a clean draw.h interface to be
used instead. This should also be incorporated into dmenu and st.
For this there are two options:
a) requiring an additional library dependency at build time (I'm not
the biggest proponent for this idea)
b) using cloned draw.{h,c}'s in st/dmenu/dwm, whereas the dwm
implementation is the master
(ii) Another aspect on the dwm roadmap is a reimplementation of the
current multi-screen handling. It still contains some weird bugs in
special setups with same screen sizes. Those don't seem to be easily
fixable with the current updategeom() handling.
(iii) A third idea is an old idea that 20h brought into the discussion
when investigating 2wm. The man page of 2wm mentions sbar, which was
abandoned a couple of years ago. My question here is:
-> is there anyone who uses the mouse functionality of the dwm bar
right now? Could you live without it?
I barely use the mouse for the dwm bar and would be in favour for
removing the bar altogether from dwm. Instead I would output the
current dwm state to stdout which could be used by a different program
like sbar for input. But I wouldn't add an interface to dwm to change
the tags through X props or some other command interface (like stdin
processing) to allow other programs to amend the dwm tags. Good old
key commands would be enough for me.
I know that some of you are inclined to use dwm on tablets. But I'm
not convinced that tablets or touch interfaces in general are a nice
fit with the terminal world we live in.
dmenu
-
dmenu needs some fixes. The removal of config.h is the wrong way it
took. If someone stays with hg of dmenu or uses the releases, he has
to do conflict management now with dmenu.c changes.
sta.li
--
To me archlinux was a good distro until a couple of years ago.
Nowadays it seems to be very en vogue and thus has degraded quite
significantly in terms of simplicity. I'm not aware of any distro that
would come close to the radical goals of stali, thus this is the real
effort suckless.org must work on. I believe that the Android core as
a base system is the best platform to base sta.li on.
Best regards,
Anselm
